譯者 | 布加迪

審校 | 重樓

共識是一致性分布式系統的基礎。為了在不可避免的崩潰事件中保證系統可用性，系統需要一種方法來確保集群中的每個節點保持一致，以便在發生故障的情況下，工作可以在節點之間無縫切換。Paxos、Raft和View Stamped Replication（VSR）等共識協議通過為領導者選舉（leader election）、原子配置更改和同步等流程提供邏輯，幫助提高分布式系統的彈性。

與所有設計要素一樣，不同的分布式共識方法具有不同的利弊。Paxos是最古老的共識協議，被用于許多系統，比如Google Cloud Spanner、Apache Cassandra、Amazon DynamoDB和Neo4j。Paxos通過三個階段、無領導者、多數獲勝的協議達成共識。雖然Paxos在力求正確性方面很有效，但理解、實施和推理起來困難重重。這一方面是由于它掩蓋了達成共識方面的許多挑戰（比如領導者選舉和重新配置），使其難以分解成子問題。

Raft（面向可靠、復制、冗余和容錯）可以被認為是Paxos的一種進化版，專注于可理解性。Raft可以實現與Paxos相同的正確性，但在現實世界中更容易理解和實施，因此常常可以提供更好的可靠性保證。比如說，Raft使用一種穩定的領導機制，簡化了復制日志管理，其領導者選舉過程更高效。

圖1

又由于Raft分解了共識問題的不同邏輯組件，比如通過使領導者選舉成為復制之前的一個不同步驟，因此它是一種靈活的協議，可以適應復雜的現代分布式系統，這類系統需要在擴展到PB級吞吐量的同時保持正確性和性能，對于處理代碼庫的新工程師來說又更容易理解。

由于這些原因，Raft已被迅速采用于今天的分布式云原生系統，比如MongoDB、CockroachDB、TiDB和Redpanda，以實現更高的性能和事務效率。

Redpanda是如何實施Raft的？

當Redpanda的創始人Alex Gallego認為世界需要一種新的流數據平臺來支持導致Apache Kafka崩潰的GBps+工作負載時，他決定從頭開始重寫Kafka。

Redpanda的需求是1）需要簡單、輕量級，以減少大規模可靠運行Kafka集群的復雜性和低效率；2）需要最大限度地提高現代硬件的性能，以便為大型工作負載提供低延遲；3）即使對于非常大的吞吐量，也需要保證數據安全性。

實施Raft為這三個需求提供了堅實的基礎：

1. 簡單性。每個Redpanda分區都是一個Raft組，所以平臺上的所有東西都圍繞Raft進行推理，包括元數據管理和分區復制。這與Kafka的復雜性形成對比：在Kafka中，數據復制由ISR（同步副本）處理，元數據管理由ZooKeeper（或Kraft）處理，您有兩個必須相互推理的系統。

2. 性能。Redpanda Raft實現可以容忍對少數副本的干擾，只要領導者和大多數副本是穩定的。在少數副本出現延遲響應的情況下，領導者不必等待它們響應即可進行下一步，從而減輕了對延遲的影響。因此，Redpanda具有更高的容錯性，可以在大規模環境下提供可預測的性能。

3. 可靠性。當Redpanda攝取事件時，它們被寫入到主題分區，并附加到磁盤上的日志文件中。然后，每個主題分區形成一個Raft共識組，由領導者和許多追隨者組成，由主題的復制因子指定。如果有2f +1個節點，Redpanda Raft組可以容忍f次故障；比如在有五個節點的集群和復制因子為5的主題中，兩個節點可能失效，而主題將保持運行。Redpanda利用Raft聯合共識協議，即使在重新配置期間也能提供一致性。

Redpanda還在一些關鍵方面擴展了Raft的核心功能，以實現現代云原生解決方案所需的可擴展性、可靠性和速度。基于Raft的創新包括對選舉過程所做的更改、心跳生成以及對Apache Kafka ACKS的重要支持。這些創新確保了在所有場景下有最佳性能，這使得Redpanda在保證數據安全的同時能夠比Kafka快得多。實際上，Jepsen測試已經證實Redpanda是一個安全的系統，沒有已知的一致性問題，是可靠的基于Raft的共識層。

但是Kraft又如何呢？

雖然Redpanda采用了Raft原生方法，但傳統的流媒體數據平臺在采用現代共識方法方面一直落后。Kafka本身是一個復制的分布式日志，但它過去依賴另一個復制的分布式日志：Apache Zookeeper進行元數據管理和控制器選舉。這是有問題的，原因如下：

1. 管理多個系統帶來了管理負擔；

2. 由于低效率的元數據處理和雙重緩存，可擴展性受到限制；

3. 集群可能變得非常臃腫和資源密集；實際上，ZooKeeper和Kafka節點數量相等的集群并不罕見。

這些限制并沒有被Apache Kafka的提交者和維護者所忽視，他們正在用一種自我管理的元數據仲裁：Kafka Raft（KRaft）來取代ZooKeeper。這種基于事件的Raft減少了Kafka元數據管理的管理挑戰，有望表明Kafka生態系統正朝著現代共識和可靠性方法的方向發展。

遺憾的是，Kraft并沒有解決Kafka集群中有兩個不同的共識系統這一問題。在新的KRaft范例中，KRaft分區處理元數據和集群管理，但復制由代理處理，因此您仍然有這兩個不同的平臺以及固有的復雜性引起的低效率。

圖2

結合Raft與性能工程

正如CockroachDB、MongoDB、Neo4j和TiDB等數據行業領導者所展示的那樣，基于Raft的系統提供了一種更簡單、更快速和更可靠的分布式數據環境。Raft正成為當今分布式數據系統的標準共識協議，因為它與性能工程結合得特別好，可以進一步提高數據處理的吞吐量。

比如說，Redpanda將Raft與快速架構要素結合在一起，在處理1GBps的工作負載時，在尾部延遲（p99.99）上比Kafka快至少10倍，僅需三分之一的硬件，而不影響數據安全性。傳統上，GBps+的工作負載對Apache Kafka來說歷來是一大負擔，但Redpanda可以以兩位數的毫秒延遲支持它們，同時保留Jepsen驗證的可靠性。

這是如何實現的呢？Redpanda是用C++編寫的，使用每核心線程架構來最大限度地發揮現代芯片和網卡的性能。這些要素共同提升了Raft對于分布式流數據平臺的價值。

圖3

比如說，由于Redpanda繞過了Kafka的頁面緩存和Java虛擬機（JVM）依賴，它可以將硬件級知識嵌入到Raft實現中。每次您在Raft中寫入數據時，通常都必須刷新，以保證磁盤上寫入內容的持久性。在Redpanda樂觀的Raft方法中，較小的間歇刷新被丟棄，改為調用結束時進行較大的刷新。雖然這在每次調用時引入了一些額外的延遲，但減少了總體系統延遲，并增加了總體吞吐量，因為它減少了刷新操作總數。

雖然有許多有效的方法來確保分布式系統的一致性和安全性（區塊鏈用工作量證明和權益證明協議做得很好），但Raft是一種經過驗證的方法，足夠靈活，可以像Redpanda一樣進行改進，以適應新挑戰。隨著我們進入到一個數據驅動的新世界——這一方面受人工智能和機器學習用例的驅動，未來掌握在能夠利用實時數據流的開發人員手中。

基于Raft的系統以及C++和每核心線程架構之類的性能工程要素，正在推動數據流在未來的關鍵任務應用程序中派上大用場。

原文標題：Why Raft-native systems are the future of streaming data，作者：Doug Flora