日誌複製模式: 大多數投票(Quorums)，同步複製佇列(ISRs)和狀態機模式

kafka高可用的核心思想是建立在日誌同步的機制上. 日誌同步在分散式資料系統中是最常見同時極為重要環節之一，市面上有許多已實現的演算法供參考. 其中狀態機模型常被分散式系統用於實現日誌複製來達到分散式系統的狀態一致性

日誌同步機制既要保證在分散式系統中資料的一致性，也要保證資料輸入的順序性. 當然有許多方法能實現這些功能，其中最為簡單高效的處理方式是叢集中選出一名leader來處理資料寫入的順序性，只要leader狀態是存活的，follower副本只需按leader的寫入順序複製這些資料以達到叢集內資料的一致性.

通常情況，只要leader不宕機我們是不用關心follower同步的問題，寫入只發生在leader節點，副本節點只需按序複製leader日誌即可. 當leader服務宕機，此時叢集需要從follower節點群中選擇新的leader節點， 此時這些follower節點可能存在未能同步到leader最新日誌或者服務同時宕機的情形，但系統必須保證能選出具有最新日誌資料的follower節點作為leader.事務日誌複製演算法最基本保證要做到：當客戶端提交事務返回成功ack時，此時若leader宕機不可用，新選舉的leader事務日誌裡必須包含客戶端提交過的事務日誌. 這裡有個折中的情況：leader需要等待大多數follower返回日誌複製ack資訊,才能對外發布該事務訊息，一定程度上增大了事務延遲，但有利的方面是當leader不可用時，更多的follower節點可以被選作leader，能加快選舉的過程降低系統不可用時間.

大多數投票機制(majority vote):需要同時滿足事務提交確認的數量以及日誌副本數量能夠進行leader選舉比較的數目關係.
一個常見的解決方案是使用大多數投票(majority vote)選舉來滿足提交決策及leader選舉. 這不是kafka內部採用的機制，但是值得一起探索和深度理解下這種權衡的藝術. 首先假設我們有2f+1個副本數, leader在釋出事務訊息之前必須接收到f+1個副本同步ack的資訊，同時如果發生新的leader選舉至少保證有f+1個副本節點完成日誌同步並從同步完成的副本中選出新的leader節點，在不超過f個副本節點失敗的情況下，新的leader能保證不會丟失提交的訊息. 這是因為在f+1的副本中,理論上確保至少有一個副本包含全部提交的訊息，這個副本的日誌擁有最完全的訊息日誌因此會被選作新的leader對外提供服務. 詳細的細節可以從每個具體演算法實現上得到佐證(如如何精準定義在leader失敗或者叢集數目變化時怎麼保證日誌的完整複製，確保日誌的一致性)，本文不作贅述.

大多數投票方案(majority vote)具有以下優勢：事務延遲取決於最快的多數(f+1)裝置. 例如，如果副本數量(複製因子)設定為3，延遲時間取決於最快的那臺slaver節點而不是效能差的slaver節點.

使用Quorums模型的一致性演算法家族中包括zookeeper的zab協議, raft協議以及viewstamped replication協議. 在眾多解決日誌複製協議問題的學術論文中,發現kafka的實現更像微軟的PacificA主從同步協議.

大多數選舉機制(majority vote)也存在自身的弊端：當大多數副本節點不可用或宕機情況下會造成選主失敗引起系統不可用. 要容忍1個節點失效或宕機必須滿足資料有三個以上的副本數，若要容忍2個節點失效，需要有5個以上的副本數量. 按過往經驗，只配置基本的副本數以滿足單節點失效對實際系統來講是遠遠不夠的, 為滿足實際需求至少需要5倍的副本數量,由此帶來的5x的磁碟開銷和1/5th的吞吐量，對大規模資料儲存服務將是個嚴重的問題.這也是quorums常被用於共享叢集配置場景(shared cluster configuration)的主要原因 比如zookeeper,但是很少使用在主流的資料儲存系統中. 例如HDFS的namenode元資料日誌儲存的高可用採用大多數選舉策略(majority vote)，但是hdfs資料分片同步卻沒有采用如此昂貴的複製機制.

相比大多數投票機制(majority vote), Kafka採取略微不同的選舉quorum集的方法. Kafka動態維護著被稱為同步佇列（ISR）的集合，處於ISR集合內的節點保持著和leader相同水位(hw),只有位列其中的副本節點才有資格被選為新的leader. 寫請求只有等到所有ISRs中的副本(partition)節點返回ack才能被認為訊息已提交, 當ISR中副本節點數量變化會及時持久化到zookeeper進行儲存.

位於ISR中的任何副本節點都有資格成為leader，選舉過程簡單,邏輯清晰並且開銷極低,這也是kafka選用此模型的重要因素;kafka擁有眾多的partition數量，而主從同步複製又發生在partition這層邏輯之上，每個partition可能擁有不同副本數(不同topic的partition副本數目由建立時複製因子決定)，同時kafka需保證所有partitions的leader節點在叢集中的平衡性，此因素極大影響著kafka的效能指標(因為讀寫資料都發生在leader節點).

在採用ISR模型和f+1個副本數配置下，一個kafka的topic能夠容忍最大f個節點失效但是不丟失提交的所有訊息, 相比大多數選舉(majority vote)方式所需的節點數大幅度減小.

為滿足絕大多數使用場景，我們選擇了類似PacificA的日誌複製方式. 實際上，為容忍f個節點失效，大多數選舉(majority vote)策略和ISR方式都需要相同數量的副本節點ack資訊才能提交訊息（e.g. 為容忍一個節點失敗，大多數選舉策略需要3個副本和一個slaver的ack資訊，ISR方法則需要2個副本節點和一個slaver的ack資訊），==對比需要相同ack數量下，採用ISR方式需要的副本總數更少，複製帶來的叢集開銷更低==. 大多數選舉方法(majority vote)優勢在於可以繞開最慢裝置的ack資訊達到事務提交的能力,降低事務提交的延時. 然而，我們認為這種改善的能力可交由客戶端使用者自己去選擇是否堵塞在訊息提交過程還是佔用更大頻寬和磁碟用量(通過降低複製因子來達到目的)是更為值得采用的方案.

另外一個設計上的重要區別:kafka並不需要宕機節點必須從本地資料日誌進行恢復. 不同於常見的複製演算法，一般複製演算法在資料恢復階段依賴於穩定的儲存系統即系統恢復時日誌檔案不可丟失同時不能有資料上的一致性衝突，出現以上原因主要基於以下的假設，第一，磁碟錯誤通常在實際操作中會發現儲存系統在持久化過程中並不能完全保證資料的完整性，第二，即使不存在硬體級別故障，我們也不希望在每次寫請求時執行fsync系統呼叫來保證資料的一致性，這樣會極大降低效能吞吐.kafka同步協議上允許宕機副本重新加入到ISR佇列，但進入ISR之前必須重新完整的同步leader資料(re-sync),即使在宕機時意外丟失了未刷盤的日誌.

以上是kafka官方文件關於副本複製協議的相關描述. 結合對上文的理解及自己在使用kafka過程中的總結，對於Kafka選擇Raft協議可能存在的一些優缺點做些論述:

1. kafka副本複製是建立在partition級別，如果選raft協議來取代ISR模式，意味著需要在每個partition上建立一個raft叢集來管理副本狀態，此叢集(Raft)只能管理當前partition；當partition數量眾多時需要對應規模的raft叢集進行管理，讓kafka系統維護數量眾多的raft叢集還是相對困難的. 而Kafka實現的ISR中leader選舉由同一個controller來完成，所有涉及partition副本狀態的監聽也是由controller來處理和進行leader選舉，其處理邏輯相比Raft簡單許多；大量partition存在的情況下若換成raft協議進行副本複製，對raft叢集set的管理將成為kafka的一個瓶頸.
   

2. Raft選舉leader發生條件是由raft協議來保證與節點Term時間選擇有很大關係，可能時間閾值設定不當造成經常的leader切換；一段時間後leader的分佈會出現嚴重傾斜情況，叢集的吞吐也因此急劇下降；與kafka的ISR實現不同的是，raft要動態調整leader到指定副本節點協議上並沒有很好的支援，而在kafka的實現中通過讀取metadata，controller很容易調整leader節點到合適的裝置上, 通過運維命令或配置非同步掃描執行緒定時檢查來進行leader的rebalance.

3. 副本數量選擇上，Raft協議需要遵從2f+1的配置方案，kafka使用上會存在一定的不便性；另外發生f+1個節點不可用時，也不能動態調參的方式讓raft叢集恢復到可用狀態；ISR這塊相對比較靈活可以通過topic級別的引數(min.insync.replicas)動態調節恢復正常; 按照官方文件描述來看，如果要達到實際生產上HA級別來使用，raft副本數也會大大超過ISR的數量，額外帶來的磁碟開銷和網路吞吐開銷很遠遠超過ISR的方式.

4. 針對客戶端不同的需求(acks=1,0,-1)的情況，Raft原始協議不好解決針對同一個topic不同業務有不同可靠級別的需求場景；kafka的設計很好的支援了此類混合使用的方式；

5. 網路分割槽出現時(腦裂發生)，raft協議帶來的partitions不可用程度相比ISR方式會更明顯和嚴重性更高,恢復服務的難度也相對較高.

6. Raft協議更適合在例項級別的事務日誌同步場景，比如mysql的主從同步，其中涉及的是單例項的事務日誌進行主從拷貝，簡單理解是裝置級別的主從關係；而kafka建立在partition之上的主從分佈，顆粒度很細；從裝置層面來看，存在多重raft叢集重疊在裝置主機之中，是多讀多寫的場景，也會極大的影響到效能；然而rocketmq的設計相比kafka在這個層面上更適合raft協議，其使用的是單一事務日誌來記錄所有訊息，保證很好的順序寫的效能.

7. Raft協議能很好的解決讀的負載平衡的問題，避免全部通過leader進行讀取，kafka是通過定時掃描重建leader在叢集中的平衡關係達到但這個是在叢集級別上來做的平衡策略；Raft針對讀操作可以在partition級別上進行處理.

8. Raft協議的ack機制是由叢集中最快的f+1個裝置確認完成即能提交事務，而kafka本身的配置很難篩選出快速裝置配置到ISR佇列中達到低延遲的目的，但可通過監控逐漸優化至最佳配置的方案,而Raft協議本身保證了此機制的便捷性.

9. Raft協議提供了選主功能(leader選舉)，kafka目前內部眾多模組還是依賴zookeeper的leader選舉機制，如果選用raft協議可以移除zookeeper依賴.

10. 市面上選擇Raft協議的開源專案大多應用在分散式共享配置的場景中，如etcd,Consul等一般用於註冊發現/配置共享等應用型別,應用在大量資料同步場景的例子比較少見.