一：更早的起源時間

kafka是2011 年被捐獻給 Apache 基金會，而raft論文是2013年由斯坦福大學發表的《In Search of an Understandable Consensus Algorithm》，kafka在raft之前誕生

二：更少的可容錯副本數量。raft當有1/3個節點數目不可用時，服務不可用，kafka中維護的ISR（in-sync-replica），即便副本均不可用，只剩下Leader，也可以對外提供服務

三：更大的資料吞吐量。raft適合強一致性

首先我們要知道raft協議是什麼，raft分散式共識協議是由 Stanford University 的 Diego Ongaro 博士以及 John Ousterhout 教授提出的，因其易於理解，便於工程化實現等特點，在金融、雲服務、工業等領域得到了廣 泛應用，且其穩定性與高效也已得到業界的認可。

任何分散式共識協議都要滿足CAP理論，即，一個分散式系統最多同時滿足 CAP 理論三條特點中的兩條，而另一 條無法完全滿足。

三條特點為：

可用性（Availability） & 分割槽容錯性（Partition tolerance）： 若只滿足可用性與分割槽容錯性，會犧牲一致性特點。因為若有網路分割槽存在，部分分 區中的節點會導致客戶端獲取的資料不一致。

一致性（Consistency） & 分割槽容錯性（Partition tolerance）： 若只滿足一致性與分割槽容錯性，則會犧牲可用性特點，因為要保證分割槽中的部分節點 與其他節點一致，則部分客戶端不能得到叢集的響應。

一致性（Consistency） &可用性（ Availability）： 滿足一致性與可用性特點的系統往往執行在可靠性與準確性要求較高的場景下。例如 金融環境下使用者財產儲存系統。在此情況下，需要對分割槽容錯性（Partition tolerance）進行 處理，Raft 一致性協議則是針對這種場景設計的。

在Kafka使用場景下，會有日誌亂序抵達的問題，raft協議無法解決，或者高效解決日誌亂序的問題，這也就是為什麼阿里巴巴自研資料庫oceanbase使用的是paxos而不是raft協議了

參考文獻：

[1] 曾詩欽. 北京郵電大學網路與交換國家重點實驗室, 區塊鏈技術研究綜述：原理、進展與應用[J],2020.

[2] 王海勇; 郭凱璇; 潘啟青. 南京郵電大學計算機學院, 基於投票機制的拜占庭容錯共識演算法[J], 2019.

[3] 陽振坤. 螞蟻金融服務集團, 分散式關係資料庫 OceanBase 的高可靠性[J], 2016.

[4] 苗凡；閻志遠. 中國鐵道科學研究院集團有限公司，基於 Zookeeper 的配置管理中心設計與實現[J], 2018.

[5] 張仕將;柴晶. 太原理工大學，中國科學與計算機網路資訊中心，基於 Gossip 協議的拜占庭共識演算法 [J],2018.

[6] 郭奕庭. 東南大學, 基於 Node.js 與 Etcd 的輕量級微服務開發平臺的設計與實現[D], 2018.

[7] Alibaba Ant Finanical Services Group. SOFAJRaft GitHub[CP]. https://github.com/sofastack/sofa-jraft 2019.

[8] LESLIE LAMPORT, Microsoft, Paxos Made Simple[J], 2001. [9] Diego Ongaro and John Ousterhout. Stanford University. In Search of an Understandable Consensus Algorithm[D], 2013.

kafka用高水位機制來實現同步以及訊息的可見性。之所以不用raft，個人認為是出於可用性的考慮，而且kafka也不是專門用來提供一致性相關儲存服務的系統，所以不用也在情理之中。但將來新版本的kafka確實打算使用raft演算法來去除叢集需要強依賴zookeeper的問題。譬如controller選舉在後期版本會用raft協商來完成

和raft這類少數服從多數的一致性協議相比較，kafka動態維護ISR集合的方式，在能容忍相同節點數失敗的情況下，需要的節點數量更少。所以在類似Kafka這樣的資料儲存應用中不太合適用raft，因為raft需要更多的節點。raft/zab，更適合用在etcd/zookeeper中。