阿里PolarDB中的ParallelRaft中的亂序應答、亂序提交如何保證Raft協議的安全性？

01-29

阿里PolarDB中的ParallelRaft中的亂序應答、亂序提交如何保證Raft協議的安全性？

根據自己的經驗猜的:raft日誌還是有序的，只是狀態機做一些東西，讓狀態機在資料庫的角度看起來針對資料庫的命令可以亂序,亂序提交(這裡的提交可能是資料庫的事務提交，而不是指raft的日誌提交)，亂序應答。

所以這裡說的raft的安全性，我是這樣理解的:每一個副本已經commit的raft log，不同副本的同一個log index的log內容是一樣的。

所以我覺得這裡的技術更多的是在針對已經提交的raft日誌如何回放上做文章，不是說raft log本身可以亂序提交了。

我又來了。

一般閱讀量充足，就知道這個來自哪裡，大體實現原理了。這裡不討論那種實現的優劣勢，只討論原理本身。

首先，paxos和raft是同一個consensus演算法族，raft是paxos的變體，只是演算法本身的優化。後面為了簡化打字都用paxos指代。

當然，歷史上consensus協議還有一個族類，viewstamp，芭芭拉阿姨的傑作。

第二，paxos本質上就是一個分散式，高容錯，高可用，魯棒的日誌系統。

第三，paxos五大組件，API，consensus演算法，選主，持久化，網路消息傳輸。paxos的優化和變種版本歷史上都說圍繞這五點，尤其是2.4.5這三個來設計的。

第四，paxos有一個特殊變種，disk paxos，也是lamport搞得。原理是，CPU很貴啊，能省還得省不是？能不能在follower參與consensus時不使用cpu，只用磁碟？leader以將proposal寫入多數磁碟為標準提交成功。著名的corfu是這個演算法的實現之一，題主提到的parallelraft也是，因為io在存儲伺服器端都kernel bypass了。當然實現上還日誌條目的原子性寫、排他性（write once語義）寫，不知道我理解對不，請阿里雲同學幫忙指正。

第五，亂序一類的特性，估計是演算法上的優化了，不過rdma網路丟包，亂序的可能性很低，對比過去的演算法的悲觀網路假設，做成客觀式的是正確思路，他們具體的優化點我也不知道，但我能想到幾點，就不說了。

第六，為何叫xx-raft？不就是個名字嘛，什麼響亮叫什麼⊙▽⊙ 。

再一個，題主肯定是阿里雲的兄弟。

推測是主備間複製也可以多線程亂序，最多在備庫上有log空洞，這個通過備庫回放去處理，加強資料庫本身的一些語義做限制。工程上行得通，雖然有難度。麻煩就是crash recovery，不過mysql 5.6都有多庫mts的恢復，無非是協調多個節點的raft log

光看ppt簡直是顛覆了分散式一致性協議領域。