如何評價一致性演算法 PacificA ？

01-24

今天看了一下小米在 ArchSummit 北京 2016 做的分享《從Pegasus看分散式系統設計》，裡面提到 Pegasus 採用了 PacificA 演算法保證一致性，但是沒有說明與 Paxos 和 Raft 相比這個演算法有什麼優越性，這個演算法的使用似乎也遠不如 Paxos 和 Raft 廣泛。那 PacificA 與 Paxos 和 Raft 比較有什麼優劣之處？
PacificA 論文：https://www.microsoft.com/en-us/research/wp-content/uploads/2008/02/tr-2008-25.pdf

PacificA主要特點:

1. separation of configuration manager(Paxos) from data replication(primary-backup replication)

2. decentralized monitoring dectecting failures and triggering reconfiguation.

3. general and abstract model that clarifies correctness and allows different pracitical

PacificA和Paxos, Raft的區別

PacificA是主從複製協議, 順序提交. Raft和Paxos是Quorum協議, Raft順序提交, Paxos亂序提交.

PacificA更簡單, 更容易理解, 優化比較方便(我們內部的分散式存儲引擎使用PacificA). Raft實現很複雜, 優化起來很難(做MIT 6.824的感受) , Paxos實現更難.

PacificA需要外圍config manager來管理複製組配置的變更, 而Raft不需要, 自身就可以選主. Paxos的實現, 沒有看過, 但應該是可以自身選主的.

PacificA自身的一些機制

通過lease機制解決節點fail的問題

只要有存活的節點, 就可以追加日誌.

暫時性故障的容錯恢複比較簡單: leader做完failover之後, 有一個reconcile過程.

永久性故障的容錯恢復, 因為有config manager的參與, 實現也比較簡單.

大致瀏覽了下論文，感覺更像藉助Paxos和主從複製做的一個日誌複製系統實現，而不算一個新的一致性演算法，跟下面這幾個開源系統的高可用方案的實現或者提供的日誌複製feature比較類似:

(1) hdfs qjm

HDFS High Availability Using the Quorum Journal Manager

(2) mesos replicated log

Apache Mesos

(3) bookeeper以及基於此的distributedlog

Apache BookKeeper - BookKeeper overview

Apache DistributedLog (incubating)

----

另外可以參考Lamport的Vertical Paxos論文:

http://research.microsoft.com/en-us/um/people/lamport/pubs/vertical-paxos.pdf

btw，相對quorum系統有個顯著有點就是容錯性比較高(k faults in k+1 nodes)

藉助外部高可用系統如zk/etcd等來選主、管理membership以及存儲last write log entry(比如bookeeper)等選主恢復需要的信息，leader和follower自身維護一個主的版本號termid，並使用續約。

(當然，那篇論文應該在上述幾個系統的高可用方案之前...)

任何一致性演算法都是paxos的一種工程實現

個人覺得PacificA沒有Paxos，Raft流行，可能跟msra沒有強力推廣也有關，另外，感覺PacificA有不少viewstamped replication的影子，沒有很有新意的地方，應用案例似乎也不多。rDSN項目介紹提到是為bing開發，作為rDSN的一致性協議，PacificA協議是否也用到了bing中？