理論
- CAP 定律，最終一致性
- Base 理論
- 基於XA協議的兩階段提交
- FLP（FLP Impossibility Result 不可能性） ：在異步通信場景，即使只有一個進程失敗，也沒有任何算法能保證非失敗進程達到一致性！
- 共識算法
- 事務傳播機制
- 事務隔離性
解決方案
- XA重量級
- 基於可靠消息的最終一致性方案
- TCC
- Saga
注意事項
基本上，每個人剛開始建立一個分佈式系統時，都做了以下 8 條假定。隨着時間的推移，每一條都會被證明是錯誤的，也都會導致嚴重的問題，以及痛苦的學習體驗。
- 網絡是穩定的。
- 網絡傳輸的延遲是零。
- 網絡的帶寬是無窮大。
- 網絡是安全的。
- 網絡的拓撲不會改變。
- 只有一個系統管理員。
- 傳輸數據的成本爲零。
- 整個網絡是同構的。
相關技術
接口冪等性
參考實現方案：
- 前置條件：數據變更操作都有唯一業務流水號
- 判斷redis中是否有業務流水號
- 如果有則拒絕，請求結束；如果沒有，則插入流水號，執行業務
- 如數據量過大，可考慮定期清理過期數據
- 補充：業務流水號也可以設計成有序的，便於在大數據中使用二分查找、跳查表
分佈式系統時鐘
分佈式系統中如何設置系統時鐘，以及進程間的通訊機制，在沒有任何共享時鐘的情況下，如何確定一個事件發生在另一個事件之前
- Lamport 時鐘：居然還和相對論有關；阻塞算法
- Vector 時鐘
實現最終一致性有三種模式
- 可靠事件模式
- 業務補償模式
- TCC模式
執行順序
如果我們先後收到兩條事件，（1）賬戶餘額更新爲100，（2）賬戶餘額更新爲120。
如果事件不是在同一個服務器上發出的，那麼服務器之間的時間同步是個難題，更穩妥的做法是使用一個全局遞增序列號替換時間戳。
框架
- 阿里GTS
- 阿里分佈式事務框架GTS開源啦！
- GTS開源版：Fescar；2019年4月已更名爲seata
- TX-LCN分佈式事務框架
框架對比
框架總結
從開發團隊背景上看seata勝出，但是seata需要使用dubbo，並且現在處於開發完善階段（頻繁的修復bug提交記錄），不建議用於生產環境。
參考資料
- “分佈式事務一致性” 看這一篇就夠了
- 保證分佈式系統數據一致性的6種方案
- ACK機制
- 爲什麼說分佈式事務不再適用於微服務架構
- 左耳朵耗子推薦：分佈式系統架構經典資料
- 《分佈式系統原理與範型（第2版）》（世界著名計算機教材精選）
- 可擴展的Web架構和分佈式系統
- Raft 一致性算法論文譯文
- Raft算法動態演示 The Secret Lives of Data
- Raft算法動態演示 Raft Distributed Consensus Algorithm Visualization
- Raft算法動態演示 The Raft Consensus Algorithm
- Gossip動畫演示 gossip-visualization
- Spanner 是 Google 的全球分佈式數據庫 Globally-Distributed Database
- 基於Spanner論文的開源實現 ：出自Google公司自己的人CockroachDB；國人作品TiDB