1. 分布式系統(tǒng)CAP原理

CAP原理：指在一個分布式系統(tǒng)中，Consistency（一致性）、Availability（可用性）、Partitontolerance（分區(qū)容忍性），三者不可得兼。
一致性（C）：在分布式系統(tǒng)中的所有數據備份，在同一時刻是否同樣的值。簡單說就是所有節(jié)點在同一時刻的數據完全一致，這就意味著節(jié)點越多數據同步的時候消耗時間越多。
可用性（A）：負載過大后，集群整體是否還能響應用戶正常的讀寫請求。簡單說就是項目系統(tǒng)對于用戶請求的響應時間一定在能接受的范圍內，需要照顧用戶體驗。
分區(qū)容忍性（P）：分區(qū)容忍性，就是高可用性，一個節(jié)點崩了不會影響其他節(jié)點。簡單說就是服務器節(jié)點崩了幾個沒事，只要有正常的服務器就可以，意思是節(jié)點越多就越好了。

2. 一致性

? 強一致性：數據庫一致性，犧牲了性能
? 弱一致性：數據庫和緩存，延遲雙刪、重試
? 單調讀一致性：緩存一致性，ID或者IP哈希
? 最終一致性：邊緣業(yè)務，消息隊列

業(yè)內常用解決方案：
XA方案：
2PC協(xié)議：兩階段提交協(xié)議，P是指準備階段，C是指提交階段
? 準備階段：詢問是否可以開始，寫Undo、Redo日志，收到響應
? 提交階段：執(zhí)行Redo日志進行Commit，執(zhí)行Undo日志進行Rollback
3PC協(xié)議：將提交階段分為CanCommit、PreCommit、DoCommit三個階段
CanCommit：發(fā)送canCommit請求，并開始等待
PreCommit：收到全部Yes，寫Undo、Redo日志。超時或者No，則中斷
DoCommit：執(zhí)行Redo日志進行Commit，執(zhí)行Undo日志進行Rollback
區(qū)別是第二步，參與者自身增加了超時，如果失敗可以及時釋放資源

3.Paxos算法

4.ZAB算法

Raft 是一種為了管理復制日志的一致性算法
Raft使用心跳機制來觸發(fā)選舉。當server啟動時，初始狀態(tài)都是follower。每一個server都有一個定時器，超時時間為election timeout（一般為150-300ms），如果某server沒有超時的情況下收到來自領導者或者候選者的任何消息，定時器重啟，如果超時，它就開始一次選舉。
Leader異常：異常期間Follower會超時選舉，完成后Leader比較彼此步長
Follower異常：恢復后直接同步至Leader當前狀態(tài)
多個Candidate：選舉時失敗，失敗后超時繼續(xù)選舉

5.分布式事務

XA方案
兩階段提交 | 三階段提交
? 準備階段的資源鎖定，存在性能問題，嚴重時會造成死鎖問題
? 提交事務請求后，出現網絡異常，部分數據收到并執(zhí)行，會造成一致性問
TCC方案
Try Confirm Cancel / 短事務
? Try 階段：這個階段說的是對各個服務的資源做檢測以及對資源進行鎖定或者預留
? Confirm 階段：這個階段說的是在各個服務中執(zhí)行實際的操作
? Cancel 階段：如果任何一個服務的業(yè)務方法執(zhí)行出錯，那么就需要進行補償/回滾
MQ最終一致性

比如阿里的 RocketMQ 就支持消息事務（核心：雙端確認，重試冪等）

1. A(訂單) 系統(tǒng)先發(fā)送一個 prepared 消息到 mq，prepared 消息發(fā)送失敗則取消操作不執(zhí)行了
2. 發(fā)送成功后，那么執(zhí)行本地事務，執(zhí)行成功和和失敗發(fā)送確認和回滾消息到mq
3. 如果發(fā)送了確認消息，那么此時 B(倉儲) 系統(tǒng)會接收到確認消息，然后執(zhí)行本地的事務
4. mq 會自動定時輪詢所有 prepared 消息回調的接口，確認事務執(zhí)行狀態(tài)
5. B 的事務失敗后自動不斷重試直到成功，達到一定次數后發(fā)送報警由人工來手工回滾和補償

最大努力通知方案（訂單 -> 積分）

1. 系統(tǒng) A 本地事務執(zhí)行完之后，發(fā)送個消息到 MQ；
2. 這里會有個專門消費 MQ 的最大努力通知服務，接著調用系統(tǒng) B 的接口；
3. 要是系統(tǒng) B 執(zhí)行失敗了，就定時嘗試重新調用系統(tǒng) B，反復 N 次，最后還是不行就放棄