如果大家了解分布式事務的2pc和3pc協議的話（不了解也沒關系，我們后面會講），消息廣播的過程實際上是一個簡化版本的二階段提交過程

1. leader接收到消息請求后，將消息賦予一個全局唯一的64位自增id，叫：zxid，通過zxid的大小比較既可以實現因果有序這個特征

2. leader為每個follower準備了一個FIFO隊列（通過TCP協議來實現，以實現了全局有序這一個特點）將帶有zxid的消息作為一個提案（proposal）分發給所有的follower

3. 當follower接收到proposal，先把proposal寫到磁盤，寫入成功以后再向leader回復一個ack?

4. 當leader接收到合法數量（超過半數節點）的ACK后，leader就會向這些follower發送commit命令，同時會在本地執行該消息

5. 當follower收到消息的commit命令以后，會提交該消息

ps:?和完整的2pc事務不一樣的地方在于，zab協議不能終止事務，follower節點要么ACK給leader，要么拋棄leader，只需要保證過半數的節點響應這個消息并提交了即可，雖然在某一個時刻follower節點和leader節點的狀態會不一致，但是也是這個特性提升了集群的整體性能。?當然這種數據不一致的問題，zab協議提供了一種恢復模式來進行數據恢復，后續講解

這里需要注意的是：

leader的投票過程，不需要Observer的ack，也就是Observer不需要參與投票過程，但是Observer必須要同步Leader的數據從而在處理請求的時候保證數據的一致性

?

總結

以上是生活随笔為你收集整理的消息广播的实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。