在阿里巴巴，有大量的業務技術研發人員，在業務線的研發人員每天都要遇到各類技術問題，業務線問題往往隱藏在業務和技術結合系統抽象和系統流程中，比如鎖的問題，事務問題，快取問題。通常排查比較麻煩，從瀏覽器到網路，到web伺服器，到服務化應用，到快取，到儲存。希望排查思路和解決方案能夠對讀者帶來啟發。

1、冪等控制，分散式鎖超時情況和業務重發的併發

背景

對賬出現1分錢的差錯，那麼多出來的1分錢從哪裡來的呢？

資料庫分析記錄

發現使用者收益結賬在同一天內有兩筆交易記錄建立時間分別為8:00:23，8:00:29，而修改時間均為8:00:29，正常情況下只有一次的，為什麼出現兩次呢？分散式鎖的超時時間為5s，第一筆記錄從建立到修改6s，由此可以分析是分散式鎖超時失效後，獲得資料庫連線，進行提交成功。

過程逆推

• 由於資料庫連線數被佔滿，流水1建立事務處於等待提交狀態
• 系統A發現交易失敗，重試次數不滿8次的，立即發起重試，觸發生成流水2的請求
• 5s內資料軍被分散式鎖攔截，無法提交
• 經過5s後，系統B的分散式鎖失效，此時事務仍在等待未提交
• 6s時，流水2成功越過資料庫查詢冪等校驗發起事務，此時流水1拿到資料庫連線，流水1和流水2兩個事務同時提交。
• 由於資料庫未做唯一索引，且支付受理模組打穿下層冪等原則，生成兩個TXID，導致兩個事務同時提交成功
• 收益結算重複記賬，使用者多了一筆收入。

開發人員得出結論：分散式鎖在以下條件同時滿足的情況下，併發控制會被打穿。
* 上層業務系統層面有重試機制
* 業務請求存在一定時間之後提交成功的情況，例如本例中第一次請求在事務等待6s後獲得資料庫連線，提交資料成功
* 下游系統缺乏其他有效的冪等控制手段

結論

建議將第三方唯一性的冪等控制方案作為冪等控制的兜底方案，控制好這道冪等防線，這樣不論業務如何設計，就萬變不離其宗了。

另類解法：分散式一致性

在阿里巴巴的紅包系統中，紅包的發放操作會涉及兩個資料庫的事務操作，一個數據庫進行預算的扣減，另一個進行紅包資料的寫入，那麼如何保證這兩個事務操作的一致性呢？

傳統思路

兩階段資訊：由事務協調者來保證所有的事務參與者都完成第一階段的準備工作，如果參與者都準備好了，那麼進入第二階段進行提交，MySQL資料庫扮演參與者的角色，協調者由另外的應用擔當。

問題

導致資料庫壓力增大，存在資料庫熱點問題

解決方案

開發人員設計一個輕量級的一致性訊息服務，吧預算扣減成功等諸多業務操作寫入資料庫中，該訊息元件保證事件與業務操作處於同一資料庫中，所以僅僅是一次簡單的本地事務操作。
在一個成功的紅包發放操作中，對於預算端來說，進行了一次預算的扣減，一次事件寫入，可能會進行一次事件讀取，一次事件更行，對於使用者紅包資料端，僅需要進行一次紅包資料的寫入。對於預算扣減的熱點資料操作，新的方案並沒有放大它。