技術的抉擇

　　幾個月前我們決定從.NET轉向Java的時候，我心裡多少還是有些忐忑的，畢竟我已經好幾年沒碰過Java了。做了幾年的C#開發，轉到Java意味著工具集的整體替換。拿資料庫訪問來說，在C#裡，我們用過EF和ADO.NET，追求開發效率用前者，追求執行效率用後者。到Java這，我的天，琳琅滿目。一開始打算用Hibernate，畢竟大家都說這貨就是Java裡的EF，但擔心有效能問題，所以只用它來生成表。EF裡有個好東西叫資料庫遷移，Code First，到Hibernate這就完蛋了，修改了實體欄位，居然不能同步到表中。這對資料庫的持續整合是致命的，搜尋到了flyway，一用，什麼玩意兒，棄之。後來同事寫了一個工具類，從此再也不怕資料庫的頻繁修改了。至於資料庫操作，搜尋發現Mybatis呼聲很高，好，那就它吧。技術團隊就這麼按部就班開幹了。有一天我開啟他們的程式碼一看，那叫一個頭大。這麼難用的玩意兒，同事們真是太實在了，居然沒一個人抱怨。也難怪，壓根沒見過光明哪知道什麼黑暗。後來我也加入到他們的開發，我們一起對JdbcTemplate做了一個封裝，用的那叫一個溜，我甚至感覺似乎又回到了ADO.NET的快樂時光。類似的例子還有lombok，當我在那用快捷鍵生成getter和setter時，感覺跟吃蒼蠅似的，就沒什麼工具麼，一搜，果然，Google永遠是人類的好朋友。

　　無論在哪個行業，不跟風實在太難了，尤其像我這種Java半吊子，面臨一些選擇時更容易隨波逐流，萬能的安慰劑是：畢竟那麼多人用，肯定有它的道理。但我覺得比追隨主流更重要的是自己的感受，如果你自己都覺得噁心了，是不是該停一停，思考一下更優秀的替代方案，要知道世上那麼多同行，都是人，有追求的人總是想用更優良的方式來解決問題，原創出最優解可能比較難，但搜尋引擎至少可以幫我們找到它。關鍵就在於：不要摒棄自己的真實感受。難用就是難用，我在實踐中確實沒發現Mybatis比JdbcTemplate好在哪兒。另一個例子就是redis和訊息佇列。至今我仍然記得之前跟著一個所謂的大牛，眼見他興致盎然地在專案中引入redis，沒有IDE的前提下寫著Lua指令碼，美其名曰：可以利用redis單執行緒特性。這場redis災難我記憶猶新，redis不僅沒能幫我們解決效能問題，還引入了不必要的複雜性。當然，這不能完全怪redis，更主要的原因在於我們沒有結合自身業務特點去正確使用，就一頭扎入了redis大軍中。不過，我至今都不覺得除了純粹做為快取以外redis還有什麼其他更擅長的場景。還有訊息佇列，我覺得在一些非實時性專案中，用用mq還是可以的，可以達到所謂的削峰填谷的效果，不過就算不用mq，你用語言內建的本地Queue也能做到這一點，而且選擇更多，比如ArrayBlockingQueue、Disruptor，還可以避免網路開銷，更適用於實時性應用，部署時也不用再另外安裝一個mq節點。

　　話說回來，工具的出現都是為了解決痛點，所以如果時間允許的話，還是多嘗試一下比較好，看看它是如何解決的、解決的質量如何，然後再綜合考慮一下當前專案的實際情況，多做一些場景測試，再做決定。更何況有些工具的作者是有私心的，營銷大於質量，弄不好解決的痛點遠少於引入的痛點。

　　最後說一下儲存過程。我至今都反對使用這玩意兒，給運維部署帶來麻煩不說，開發成本也高，而且帶來的改善太少。資料庫的本質工作還是應該在於儲存資料，資料庫的效能確實有限，拼了老命也只能榨出來一點，尤其是併發更新的時候，更要命，事務的隔離級別、行級鎖這些控制好也只是解決了更新異常，效能問題依然還得想其他辦法解決。所以如果實時和併發要求不高的話，沒必要搞儲存過程，要求高的話，儲存過程也不能從根本上解決問題。資料庫調優只能解決一些併發中等的需求。當然，這裡所說的”不高“、”高“、”中等“，並沒有確切的衡量指標，一切都得根據實際情況來。

　　說到高併發的處理，之前我經常聽到一個聲音是：先寫記憶體，然後非同步寫資料庫，通過這樣的方式來規避資料庫瓶頸。但這裡有個嚴重的問題：如果發生當機，有些資料又沒來得及持久化，那麼這些資料就永遠的丟失了，對於交易相關的業務來說，這是不能接受的。想象一下：客戶已經得到了充值成功的提示，結果伺服器掛了，重啟後，客戶再一看頁面上，錢沒了。結合最近的學習研究，對於高併發處理，我傾向的觀點是：

• 將持久化的代價降到最低（比如實時的持久化不用資料庫，而是使用RandomAccessFile，這貨的效能真是超乎想象），中心伺服器完全執行在記憶體中，所有的業務邏輯都沒有資料庫操作、遠端呼叫。
• 避免多執行緒競爭和偽共享問題，單執行緒的處理能力其實是非常高效的，這方面的一個典型例子就是LMAX公司，有興趣的可以搜尋一下，他們在多年前就達到了600萬TPS的驚人處理速度。

　　當然，以上都是學習研究，至於具體如何，還有待我們在新的專案中去實踐出來。不管怎樣，取捨的關鍵永遠在於：用最低的成本來解決實際問題，這個成本包括時間、精力、金錢等等，這是宇宙第一原則。