一、背景
程序的定義：程序=數據+算法+接口
二、常用技巧
技巧1 - 按目標設計接口做冪等設計
- 場景
背景：做任務賺積分。前端發出增加積分請求，如果收不到響應會重試。
后台開發人員：怎么判斷是重試還是另一次請求？
解決方案：接口定義中需要傳入原來積分是多少，增加到多少。開發人員直接將目標結果入庫。
疑問：那實際生產環境發現了原來積分一樣，增加到多少不一樣的結果怎么辦？
答疑：這說明上線的產品中肯定有漏洞或bug。怎么辦？改bug唄！
- 解析
冪等性設計的定義：一次和多次請求某一個資源應該具有相同的副作用。直白點講就是多次重試可以多次查詢，但是修改更新應該只進行一次。
作為開發正確的觀念應該是外部調用失敗是常態，並且失敗之后必然有重試。
不要靠巧合編程 --《程序員修煉之道》
技巧2 - 多版本並發控制解決並發問題
- 場景
背景：上文中的做任務賺積分，后台收到了增加積分請求。
開發人員：為了避免重試，我該怎么寫代碼呢？
解決方案：update XXX set score=XX where score=X
- 解析
多版本並發控制MVCC(MultiVersion Concurrency Control)的定義：該策略主要使用update with condition（更新帶條件來防止）來保證多次外部請求調用對系統的影響是一致的。這也是「樂觀鎖」的主要思想。
樂觀鎖的定義：假設最好的情況，數據在變更的時候不會被別人更新，如果更新了，某個值就會改變。所以就用這個值來作為判斷條件，只有條件為真才更新成功。
總是為並發進行設計 --《程序員修煉之道》
技巧3 - 預判斷准入控制避免「箭頭型」代碼
- 場景
背景：上文中后台收到了增加積分請求，傳入了一個負數的積分。
開發人員：我就if 正數 才往下執行就好了呀？
結果：一層層的判斷下來，代碼變成這個樣子。
疑問：怎么解決這種復雜的「箭頭型」代碼問題呢？
答疑：「衛語句」在預判斷時做准入控制。
- 解析
衛語句(guard clause)的定義：先對異常情況做檢查，異常則直接返回。
最終一個請求被完美的分成預判斷檢查和正式執行兩個部分，邏輯清晰，簡單明了。
早重構，常重構 --《程序員修煉之道》
技巧4 - 異步設計分離響應和執行
- 場景
背景：上文的增加積分，並發量太大，因此采用了隊列設計，大量請求排隊等待數據庫變更。
開發人員：這樣后台接口部分很容易都在等着響應，服務被拖死。
解決方案：准入校驗做充分，請求放到隊列里后直接給用戶返回操作成功。
疑問：萬一最后失敗了呢？
答疑：知道失敗了還不修數據嗎？數據補償保證最終與對用戶承諾一致撒。
- 解析
1/3/5秒原則：在1s以內得到響應，用戶會覺得系統響應很快，體驗非常好；1-3秒得到響應，用戶可以接受，體驗還不錯；3-5秒才響應，用戶就感覺慢了，體驗有點糟糕；一旦響應超過5秒，用戶就會認為是個失敗的體驗，選擇離開或重新發起請求。
三、總結
思考！你的工作！ --《程序員修煉之道》
相關閱讀：
相關閱讀：