標籤：

state machine replication vs primary backup system

01-28

最近在看zab, vr, raft, paxos 這些一致性協議的對比, 想找出共同點. 然後zab, vr 經常提到他們的一個primary backup system, 與replicate state machine 還是有不同的. 雖然他們都有state machine, consensus module, log.

這裡的對比主要來自 raft 作者的phd 論文裡面的觀點:

從這個圖可以看出primary backup system 的做法是, 當有client 請求到達的時候, primary 會立刻將這個請求apply 到自己的 state machine, 然後將這個結果發送給自己的backup, 而不是這個client 的請求(比如這裡就是將y=2 發送給backup, 而不是發送y++ 這個操作), 然後這裡發送給自己多個backups 的時候是通過一致性協議來進行發送.

然而這裡還是有幾個不同點

  1. 在primary backup system 裡面, primary 在接收到client 的請求以後, 會立刻apply 到自己的state machine, 然後計算出這個結果, 寫到自己的log, 以及發送給所有的backups. 而在state machine replication 系統裡面, 是直接將這個操作發送給各個replication的. 那麼帶來的兩個結果
  • 如果某一個操作最後並沒有提交, 那麼這個state machine 必須將這次的操作給回滾掉
  • 如果一個新的節點成為primary, 那麼舊的primary 的state machine 必須將最近的未提交的操作給回滾掉

可以看出zab 怎麼解決這個問題的呢? zab 的解決方法就是當recovery 的時候, 將leader 上面的所有日誌都拉去過來, 然後丟棄自己state machine 的內容, 直接使用新leader state machine 的內容

  1. primary backup system 裡面, log只需要保存對state machine 有修改的操作, 而state machine replication 需要記錄所有的操作. 比如如果某一次操作set y = 2, 而其實y 在DB 裡面就是2, 那麼在primary backup system 裡面, 就不會給replication 發送這個操作. 而在state machine replication 裡面則會發送這個操作, 這樣帶來的影響是可能state machine replication 會有較多的log, 但是通過log compaction 其實帶來的影響可以忽略
  2. state machine replication 需要保證每一個操作都是確定性的, 因為每一個server 都必須保證apply 這一系列的client 操作以後, 所有server 的結果必須是一樣的. 因此想比如跟時間, random 相關的這些不確定性操作在這裡就無法實現, 而在primary back system 裡面, 這些不確定性的操作會通過apply 到 state machine 轉化成確定性的操作, 所以不會有這個問題. 因此常見的state machine replication 會將這些不確定性的操作給拒絕來解決這個問題. 也就是client 請求的時候就必須保證這些操作是確定性的

在 "Vive La Diffe ?rence:Paxos vs. Viewstamped Replication vs. Zab" 這個論文裡面, state machine replication 也稱作active replication, 而primary-backup system 也稱作passive replication, 這樣更加的形象, 也就是 state machine replication 是主動去同步數據, 通過達成一致性協議來返回給client, 而primary-backup system 是primary 做了所有了事情, 只是通過一致性協議把數據保存在backups 裡面

在zookeeper 的wiki 上面同樣有state machine replication 和 primary backup system 的對比, 不過我感覺他主要想表達的是通過multi-paxos 實現的state machine replication 是無法滿足有序提交這個問題的, 但是其實在raft 實現的state machine replication 裡面是可以滿足這個條件的. 所以是否滿足有序提交這個問題更多的如上圖所示是支持不支持primary-order 的問題

cwiki.apache.org/conflu


推薦閱讀：

※一致性, 兩階段提交和事務提交的發展史(譯)
※關於一致性協議的一些對比和總結
※Atlas: Baidu分散式存儲系統
※CockroachDB和TiDB中的Multi Raft Group是如何實現的?
※raft協議疑問？

TAG:分布式一致性 |