譯者 | 布加迪

審校 | 重樓

共識(shí)是一致性分布式系統(tǒng)的基礎(chǔ)。為了在不可避免的崩潰事件中保證系統(tǒng)可用性，系統(tǒng)需要一種方法來(lái)確保集群中的每個(gè)節(jié)點(diǎn)保持一致，以便在發(fā)生故障的情況下，工作可以在節(jié)點(diǎn)之間無(wú)縫切換。Paxos、Raft和View Stamped Replication（VSR）等共識(shí)協(xié)議通過(guò)為領(lǐng)導(dǎo)者選舉（leader election）、原子配置更改和同步等流程提供邏輯，幫助提高分布式系統(tǒng)的彈性。

與所有設(shè)計(jì)要素一樣，不同的分布式共識(shí)方法具有不同的利弊。Paxos是最古老的共識(shí)協(xié)議，被用于許多系統(tǒng)，比如Google Cloud Spanner、Apache Cassandra、Amazon DynamoDB和Neo4j。Paxos通過(guò)三個(gè)階段、無(wú)領(lǐng)導(dǎo)者、多數(shù)獲勝的協(xié)議達(dá)成共識(shí)。雖然Paxos在力求正確性方面很有效，但理解、實(shí)施和推理起來(lái)困難重重。這一方面是由于它掩蓋了達(dá)成共識(shí)方面的許多挑戰(zhàn)（比如領(lǐng)導(dǎo)者選舉和重新配置），使其難以分解成子問(wèn)題。

Raft（面向可靠、復(fù)制、冗余和容錯(cuò)）可以被認(rèn)為是Paxos的一種進(jìn)化版，專注于可理解性。Raft可以實(shí)現(xiàn)與Paxos相同的正確性，但在現(xiàn)實(shí)世界中更容易理解和實(shí)施，因此常常可以提供更好的可靠性保證。比如說(shuō)，Raft使用一種穩(wěn)定的領(lǐng)導(dǎo)機(jī)制，簡(jiǎn)化了復(fù)制日志管理，其領(lǐng)導(dǎo)者選舉過(guò)程更高效。

圖1

又由于Raft分解了共識(shí)問(wèn)題的不同邏輯組件，比如通過(guò)使領(lǐng)導(dǎo)者選舉成為復(fù)制之前的一個(gè)不同步驟，因此它是一種靈活的協(xié)議，可以適應(yīng)復(fù)雜的現(xiàn)代分布式系統(tǒng)，這類系統(tǒng)需要在擴(kuò)展到PB級(jí)吞吐量的同時(shí)保持正確性和性能，對(duì)于處理代碼庫(kù)的新工程師來(lái)說(shuō)又更容易理解。

由于這些原因，Raft已被迅速采用于今天的分布式云原生系統(tǒng)，比如MongoDB、CockroachDB、TiDB和Redpanda，以實(shí)現(xiàn)更高的性能和事務(wù)效率。

Redpanda是如何實(shí)施Raft的？

當(dāng)Redpanda的創(chuàng)始人Alex Gallego認(rèn)為世界需要一種新的流數(shù)據(jù)平臺(tái)來(lái)支持導(dǎo)致Apache Kafka崩潰的GBps+工作負(fù)載時(shí)，他決定從頭開始重寫Kafka。

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

實(shí)施Raft為這三個(gè)需求提供了堅(jiān)實(shí)的基礎(chǔ)：

1. 簡(jiǎn)單性。每個(gè)Redpanda分區(qū)都是一個(gè)Raft組，所以平臺(tái)上的所有東西都圍繞Raft進(jìn)行推理，包括元數(shù)據(jù)管理和分區(qū)復(fù)制。這與Kafka的復(fù)雜性形成對(duì)比：在Kafka中，數(shù)據(jù)復(fù)制由ISR（同步副本）處理，元數(shù)據(jù)管理由ZooKeeper（或Kraft）處理，您有兩個(gè)必須相互推理的系統(tǒng)。

2. 性能。Redpanda Raft實(shí)現(xiàn)可以容忍對(duì)少數(shù)副本的干擾，只要領(lǐng)導(dǎo)者和大多數(shù)副本是穩(wěn)定的。在少數(shù)副本出現(xiàn)延遲響應(yīng)的情況下，領(lǐng)導(dǎo)者不必等待它們響應(yīng)即可進(jìn)行下一步，從而減輕了對(duì)延遲的影響。因此，Redpanda具有更高的容錯(cuò)性，可以在大規(guī)模環(huán)境下提供可預(yù)測(cè)的性能。

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

Redpanda還在一些關(guān)鍵方面擴(kuò)展了Raft的核心功能，以實(shí)現(xiàn)現(xiàn)代云原生解決方案所需的可擴(kuò)展性、可靠性和速度。基于Raft的創(chuàng)新包括對(duì)選舉過(guò)程所做的更改、心跳生成以及對(duì)Apache Kafka ACKS的重要支持。這些創(chuàng)新確保了在所有場(chǎng)景下有最佳性能，這使得Redpanda在保證數(shù)據(jù)安全的同時(shí)能夠比Kafka快得多。實(shí)際上，Jepsen測(cè)試已經(jīng)證實(shí)Redpanda是一個(gè)安全的系統(tǒng)，沒(méi)有已知的一致性問(wèn)題，是可靠的基于Raft的共識(shí)層。

但是Kraft又如何呢？

雖然Redpanda采用了Raft原生方法，但傳統(tǒng)的流媒體數(shù)據(jù)平臺(tái)在采用現(xiàn)代共識(shí)方法方面一直落后。Kafka本身是一個(gè)復(fù)制的分布式日志，但它過(guò)去依賴另一個(gè)復(fù)制的分布式日志：Apache Zookeeper進(jìn)行元數(shù)據(jù)管理和控制器選舉。這是有問(wèn)題的，原因如下：

1. 管理多個(gè)系統(tǒng)帶來(lái)了管理負(fù)擔(dān)；

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

3. 集群可能變得非常臃腫和資源密集；實(shí)際上，ZooKeeper和Kafka節(jié)點(diǎn)數(shù)量相等的集群并不罕見。

這些限制并沒(méi)有被Apache Kafka的提交者和維護(hù)者所忽視，他們正在用一種自我管理的元數(shù)據(jù)仲裁：Kafka Raft（KRaft）來(lái)取代ZooKeeper。這種基于事件的Raft減少了Kafka元數(shù)據(jù)管理的管理挑戰(zhàn)，有望表明Kafka生態(tài)系統(tǒng)正朝著現(xiàn)代共識(shí)和可靠性方法的方向發(fā)展。

遺憾的是，Kraft并沒(méi)有解決Kafka集群中有兩個(gè)不同的共識(shí)系統(tǒng)這一問(wèn)題。在新的KRaft范例中，KRaft分區(qū)處理元數(shù)據(jù)和集群管理，但復(fù)制由代理處理，因此您仍然有這兩個(gè)不同的平臺(tái)以及固有的復(fù)雜性引起的低效率。

圖2

結(jié)合Raft與性能工程

正如CockroachDB、MongoDB、Neo4j和TiDB等數(shù)據(jù)行業(yè)領(lǐng)導(dǎo)者所展示的那樣，基于Raft的系統(tǒng)提供了一種更簡(jiǎn)單、更快速和更可靠的分布式數(shù)據(jù)環(huán)境。Raft正成為當(dāng)今分布式數(shù)據(jù)系統(tǒng)的標(biāo)準(zhǔn)共識(shí)協(xié)議，因?yàn)樗c性能工程結(jié)合得特別好，可以進(jìn)一步提高數(shù)據(jù)處理的吞吐量。

比如說(shuō)，Redpanda將Raft與快速架構(gòu)要素結(jié)合在一起，在處理1GBps的工作負(fù)載時(shí)，在尾部延遲（p99.99）上比Kafka快至少10倍，僅需三分之一的硬件，而不影響數(shù)據(jù)安全性。傳統(tǒng)上，GBps+的工作負(fù)載對(duì)Apache Kafka來(lái)說(shuō)歷來(lái)是一大負(fù)擔(dān)，但Redpanda可以以兩位數(shù)的毫秒延遲支持它們，同時(shí)保留Jepsen驗(yàn)證的可靠性。

這是如何實(shí)現(xiàn)的呢？Redpanda是用C++編寫的，使用每核心線程架構(gòu)來(lái)最大限度地發(fā)揮現(xiàn)代芯片和網(wǎng)卡的性能。這些要素共同提升了Raft對(duì)于分布式流數(shù)據(jù)平臺(tái)的價(jià)值。

圖3

比如說(shuō)，由于Redpanda繞過(guò)了Kafka的頁(yè)面緩存和Java虛擬機(jī)（JVM）依賴，它可以將硬件級(jí)知識(shí)嵌入到Raft實(shí)現(xiàn)中。每次您在Raft中寫入數(shù)據(jù)時(shí)，通常都必須刷新，以保證磁盤上寫入內(nèi)容的持久性。在Redpanda樂(lè)觀的Raft方法中，較小的間歇刷新被丟棄，改為調(diào)用結(jié)束時(shí)進(jìn)行較大的刷新。雖然這在每次調(diào)用時(shí)引入了一些額外的延遲，但減少了總體系統(tǒng)延遲，并增加了總體吞吐量，因?yàn)樗鼫p少了刷新操作總數(shù)。

雖然有許多有效的方法來(lái)確保分布式系統(tǒng)的一致性和安全性（區(qū)塊鏈用工作量證明和權(quán)益證明協(xié)議做得很好），但Raft是一種經(jīng)過(guò)驗(yàn)證的方法，足夠靈活，可以像Redpanda一樣進(jìn)行改進(jìn)，以適應(yīng)新挑戰(zhàn)。隨著我們進(jìn)入到一個(gè)數(shù)據(jù)驅(qū)動(dòng)的新世界——這一方面受人工智能和機(jī)器學(xué)習(xí)用例的驅(qū)動(dòng)，未來(lái)掌握在能夠利用實(shí)時(shí)數(shù)據(jù)流的開發(fā)人員手中。

基于Raft的系統(tǒng)以及C++和每核心線程架構(gòu)之類的性能工程要素，正在推動(dòng)數(shù)據(jù)流在未來(lái)的關(guān)鍵任務(wù)應(yīng)用程序中派上大用場(chǎng)。

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