關于2PC提交

（Two Phase Commitment Protocol）當一個事務操作需要跨越多個分布式節(jié)點的時候，為了保持事務處理的ACID特性，就需要引入一個“協(xié)調(diào)者”（TM）來統(tǒng)一調(diào)度所有分布式節(jié)點的執(zhí)行邏輯，這些被調(diào)度的分布式節(jié)點被稱為AP。 TM負責調(diào)度AP的行為，并最終決定這些AP是否要把事務真正進行提交；因為整個事務是分為兩個階段提交，所以叫2pc。

階段一：提交事務請求（投票）

1. 事務詢問

協(xié)調(diào)者向所有的參與者發(fā)送事務內(nèi)容，詢問是否可以執(zhí)行事務提交操作，并開始等待各參與者的響應。?

2. 執(zhí)行事務?

各個參與者節(jié)點執(zhí)行事務操作，并將Undo和Redo信息記錄到事務日志中，盡量把提交過程中所有消耗時間的操作和準備都提前完成確保后面100%成功提交事務。?

3. 各個參與者向協(xié)調(diào)者反饋事務詢問的響應?

如果各個參與者成功執(zhí)行了事務操作，那么就反饋給參與者 yes的響應，表示事務可以執(zhí)行；如果參與者沒有成功執(zhí)行事務，就反饋給協(xié)調(diào)者no的響應，表示事務不可以執(zhí)行， 上面這個階段有點類似協(xié)調(diào)者組織各個參與者對一次事務 操作的投票表態(tài)過程，因此 2pc 協(xié)議的第一個階段稱為“投票階段”，即各參與者投票表名是否需要繼續(xù)執(zhí)行接下去的事務提交操作。

階段二：執(zhí)行事務提交

在這個階段，協(xié)調(diào)者會根據(jù)各參與者的反饋情況來決定最終是否可以進行事務提交操作，正常情況下包含兩種可能：執(zhí)行事務、中斷事務。

關于ZAB協(xié)議

ZAB（Zookeeper Atomic Broadcast）協(xié)議是為分布式協(xié)調(diào)服務 ZooKeeper專門設計的一種支持崩潰恢復的原子廣播協(xié)議。在ZooKeeper中，主要依賴ZAB協(xié)議來實現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper實現(xiàn)了一種主備模式的系統(tǒng)架構來保持集群中各個副本之間的數(shù)據(jù)一致性。

消息廣播

改進版本的2PC

1.對每個消息生成一個zxid(64自增id)

2.帶有zxid的消息作為一個propose分發(fā)給集群中的每一個follower節(jié)點

3.把proposal這個事務寫入到磁盤，返回一個ack

4.leader收到合法數(shù)量的請求ack以后，再發(fā)起commit請求

投票不需要observer的參與，但是必須要和leader節(jié)點保持同步

崩潰恢復

1.當leader失去了過半的follower節(jié)點的聯(lián)系

2.當leader服務掛了

集群就會進入崩潰恢復階段

對于數(shù)據(jù)恢復來說

1.已經(jīng)被處理的消失不能丟失

當leader收到合法數(shù)量的follower的acks以后，就會向各個follower廣播消息（commit命令)，同時也會在本地執(zhí)行COMMIT并向連接的客戶端返回「成功」。如果follower節(jié)點收到commit命令之前l(fā)eader就掛了，會導致部分節(jié)點收到commit，部分節(jié)點沒有收到，而實際上客戶端已經(jīng)收到該事務消息處理成功的回執(zhí)了。所以在zab協(xié)議下需要保證所有機器都要執(zhí)行這個事務消息。

2.被丟棄的消息不能再次出現(xiàn)

當leader接收到消息請求生成proposal后就掛了，其他follower并沒有收到此proposal，因此經(jīng)過恢復模式重新選了leader后，這條消息是被跳過的。此時，之前掛了的leader重新啟動并注冊成follower，他保留了被跳過消息的proposal狀態(tài)，與整個系統(tǒng)的狀態(tài)是不一致的，需要將其刪除。