[[173625]]

我們?cè)?016年五月開源了DistributedLog項(xiàng)目，引起了社區(qū)的廣泛關(guān)注。大家常常問起的問題之一就是DistributedLog與Apache Kafka相對(duì)比，各有什么優(yōu)劣。

從技術(shù)上來講DistributedLog并不是一個(gè)象Apache Kafka那么成熟的、有分區(qū)機(jī)制的廣播/訂閱系統(tǒng)。DistributedLog是一個(gè)復(fù)制日志流倉庫，它用Apache BookKeeper來做日志分區(qū)倉庫。它關(guān)注的是構(gòu)建可靠的實(shí)時(shí)系統(tǒng)所需要的持久性、副本和強(qiáng)一致性?？梢园袲istributedLog用于構(gòu)建或嘗試各種不同的消息通信模型，比如隊(duì)列、廣播/訂閱等。

因?yàn)閮烧叨际翘幚砣罩?，?shù)據(jù)模型也類似，所以這篇文章主要從技術(shù)角度討論Apache Kafka與DistributedLog的不同點(diǎn)。我們會(huì)盡量做到客觀，但由于我們不是Apache Kafka的專家，因此我們可能會(huì)對(duì)Apache Kafka存在誤解。如果發(fā)現(xiàn)有錯(cuò)，也請(qǐng)大家直接指出。

首先，讓我們簡(jiǎn)單地介紹一下Kafka和DistributedLog的概況。

Kafka是什么?

Kafka是最初由Linkedin開源出來的一套分布式消息系統(tǒng)，現(xiàn)在由Apache軟件基金會(huì)管理。這是一套基于分區(qū)的發(fā)布/訂閱系統(tǒng)。Kafka中的關(guān)鍵概念就是Topic。一個(gè)Topic下面會(huì)有多個(gè)分區(qū)，每個(gè)分區(qū)都有備份，分布在不同的代理服務(wù)器上。生產(chǎn)者會(huì)把數(shù)據(jù)記錄發(fā)布到一個(gè)Topic下面的分區(qū)中，具體方式是輪詢或者基于主鍵做分區(qū)，而消費(fèi)者會(huì)處理Topic中發(fā)布出來的數(shù)據(jù)記錄。

所有數(shù)據(jù)都是發(fā)布給相應(yīng)分區(qū)的主代理進(jìn)程，再復(fù)制到從代理進(jìn)程，所有的讀數(shù)據(jù)請(qǐng)求也都是依次由主代理處理的。從代理僅僅用于數(shù)據(jù)的冗余備份，并在主代理無法繼續(xù)提供服務(wù)時(shí)頂上。圖一的左邊部分顯示了Kafka中的數(shù)據(jù)流。

DistributedLog是什么?

與Kafka不同，DistributedLog并不是一個(gè)基于分區(qū)的發(fā)布/訂閱系統(tǒng)，它是一個(gè)復(fù)制日志流倉庫。DistributedLog中的關(guān)鍵概念是持續(xù)的復(fù)制日志流。一個(gè)日志流會(huì)被分段成多個(gè)日志片段。每個(gè)日志片段都在Apache BookKeeper中存儲(chǔ)成Apache BooKeeper中的一個(gè)賬目，其中的數(shù)據(jù)會(huì)在多個(gè)Bookie(Bookie就是Apache BookKeeper的存儲(chǔ)節(jié)點(diǎn))之間復(fù)制和均衡分布。一個(gè)日志流的所有數(shù)據(jù)記錄都由日志流的屬主排序，由許多個(gè)寫入代理來管理日志流的屬主關(guān)系。

應(yīng)用程序也可以使用核心庫來直接追加日志記錄。這對(duì)于復(fù)制狀態(tài)機(jī)一類對(duì)于順序和排他寫有著非常高要求的場(chǎng)景非常有用。每個(gè)追加到日志流末尾的日志記錄都會(huì)被賦予一個(gè)序列號(hào)。讀者可以從任何指定的序列號(hào)開始讀日志流的數(shù)據(jù)。讀請(qǐng)求也會(huì)在那個(gè)流的所有存儲(chǔ)副本上做負(fù)載均衡。圖一的右半部分顯示了DistributedLog中的數(shù)據(jù)流。

Kafka與DistributedLog有什么不同?

因?yàn)橥愂挛锊庞锌杀容^的基礎(chǔ)，所以我們只在本文中把Kafka分區(qū)和DistributedLog流相對(duì)比。下表列出了兩套系統(tǒng)之間最顯著的不同點(diǎn)。

數(shù)據(jù)模型

Kafka分區(qū)是存儲(chǔ)在代理服務(wù)器磁盤上的以若干個(gè)文件形式存在的日志。每條記錄都是一個(gè)鍵-值對(duì)，但對(duì)于輪詢式的數(shù)據(jù)發(fā)布可以省略數(shù)據(jù)的主鍵。主鍵用于決定該條記錄會(huì)被存儲(chǔ)到哪個(gè)分區(qū)上以及用于日志壓縮功能。一個(gè)分區(qū)的所有數(shù)據(jù)只存儲(chǔ)在若干個(gè)代理服務(wù)器上，并從主代理服務(wù)器復(fù)制到從代理服務(wù)器。

DistributedLog流是以一系列日志分片的形式存在的虛擬流。每個(gè)日志分片都以一條BookKeeper賬目的形式存在，并被復(fù)制到多個(gè)Bookie上。在任意時(shí)刻都只有一個(gè)活躍的日志分片接受寫入請(qǐng)求。在特定的時(shí)間段過后，或者舊日志分片達(dá)到配置大小(由配置的日志分片策略決定)之后，或者日志的屬主出故障之后，舊的日志分片會(huì)被封存，一個(gè)新的日志分片會(huì)被開啟。

Kafka分區(qū)和DistributedLog流在數(shù)據(jù)分片和分布的不同點(diǎn)決定了它們?cè)跀?shù)據(jù)持久化策略和集群操作(比如集群擴(kuò)展)上的不同。

圖二顯示了DistributedLog和Kafka數(shù)據(jù)模型的不同點(diǎn)

數(shù)據(jù)持久化

一個(gè)Kafka分區(qū)中的所有數(shù)據(jù)都保存在一個(gè)代理服務(wù)器上(并被復(fù)制到別的代理服務(wù)器上)。在配置的有效期過后數(shù)據(jù)會(huì)失效并被刪除。另外，也可以配置策略讓Kafka的分區(qū)保留每個(gè)主鍵的***值。

與Kafka相似，DistributedLog也可以為每個(gè)流配置有效期，并在超時(shí)之后將相應(yīng)的日志分片失效或刪除。除此之外，DistributedLog還提供了顯示的截?cái)鄼C(jī)制。應(yīng)用程序可以顯式地將一個(gè)日志流截?cái)嗟搅鞯哪硞€(gè)指定位置。這對(duì)于構(gòu)建可復(fù)制的狀態(tài)機(jī)非常有用，因?yàn)榭蓮?fù)制的狀態(tài)機(jī)需要在刪除日志記錄之前先將狀態(tài)持久化。Manhattan就是一個(gè)用到了這個(gè)功能的典型系統(tǒng)。

操作

數(shù)據(jù)分片和分布機(jī)制的不同也導(dǎo)致了維護(hù)集群操作上的不同，擴(kuò)展集群操作就是一個(gè)例子。

擴(kuò)展Kafka集群時(shí)，通?，F(xiàn)有分區(qū)都要做重新分布。重新分布操作會(huì)將Kafka分區(qū)挪動(dòng)到不同的副本上，以此達(dá)到均衡分布。這就要把整個(gè)流的數(shù)據(jù)從一個(gè)副本拷到另一個(gè)副本上。我們也說過很多次了，執(zhí)行重新分布操作時(shí)必須非常小心，避免耗盡磁盤和網(wǎng)絡(luò)資源。

而擴(kuò)展DistributedLog集群的工作方式則截然不同。DistributedLog包含兩層：存儲(chǔ)層(Apache BooKeeper)和服務(wù)層(寫入和讀出代理)。在擴(kuò)展存儲(chǔ)層時(shí)，我們只需要添加更多的Bookie就好了。新的Bookie馬上會(huì)被寫入代理發(fā)現(xiàn)，并立刻用于寫入新的日志分片。在擴(kuò)展數(shù)據(jù)存儲(chǔ)層時(shí)不會(huì)有任何的重新分布操作。只在增加服務(wù)層時(shí)會(huì)有重新分布操作，但這個(gè)重新分布也只是移動(dòng)日志流的屬主權(quán)，以使網(wǎng)絡(luò)代寬可以在各個(gè)代理之間均衡分布。這個(gè)重新分布的過程只與屬主權(quán)相關(guān)，沒有數(shù)據(jù)遷移操作。這種存儲(chǔ)層和服務(wù)層的隔離不僅僅是讓系統(tǒng)具備了自動(dòng)擴(kuò)展的機(jī)制，更讓各種不同類型的資源可以獨(dú)立擴(kuò)展。

寫與生產(chǎn)者

如圖一所示，Kafka生產(chǎn)者把數(shù)據(jù)一批批地寫到Kafka分區(qū)的主代理服務(wù)器上。而ISR(同步復(fù)制)集合中的從代理服務(wù)器會(huì)從主代理上把記錄復(fù)制走。只有在主代理從所有的ISR集合中的副本上都收到了成功的響應(yīng)之后，一條記錄才會(huì)被認(rèn)為是成功寫入的?？梢耘渲米屔a(chǎn)者只等待主代理的響應(yīng)，還是等待ISR集合中的所有代理的響應(yīng)。

DistributedLog中則有兩種方式把數(shù)據(jù)寫入DistributedLog流，一是用一個(gè)Thrift的瘦客戶端通過寫代理(眾所周知的多寫入)寫入，二是通過DistributedLog的核心庫來直接與存儲(chǔ)節(jié)點(diǎn)交互(眾所周知的單獨(dú)寫入)。***種方式很適合于構(gòu)建消息系統(tǒng)，第二種則適用于構(gòu)建復(fù)制狀態(tài)機(jī)。你可以查閱DistributedLog文檔的相關(guān)章節(jié)來獲取更多的信息和參考，以找到你需要的方式。

日志流的屬主會(huì)并發(fā)地以BookKeeper條目的形式向Bookie中寫入一批記錄，并等待多個(gè)Bookie的Quorum結(jié)果。Quorum的大小取決于BookKeeper賬目的ack_quorum_size參數(shù)，并且可以配置到DistributedLog流的級(jí)別。它提供了和Kafka生產(chǎn)者相似的在持久性上的靈活性。在接下來的“復(fù)制”一節(jié)我們會(huì)對(duì)比兩者在復(fù)制算法上的更多不同之處。

Kafka和DistributedLog都支持端到端的批量操作和壓縮機(jī)制。但兩者之間的一點(diǎn)微妙區(qū)別是對(duì)DistributedLog的寫入操作都是在收到響應(yīng)之前都先通過fsync刷到硬盤上的，而我們并沒發(fā)現(xiàn)Kafka也提供了類似的可靠性保證。

讀與消費(fèi)者

Kafka消費(fèi)者從主代理服務(wù)器上讀出數(shù)據(jù)記錄。這個(gè)設(shè)計(jì)的前提就是主代理上在大多數(shù)情況下***的數(shù)據(jù)都還在文件系統(tǒng)頁緩存中。從充分利用文件系統(tǒng)頁緩存和獲得高性能的角度來說這是一個(gè)好辦法。

DistributedLog則采用了完全不同的方法。因?yàn)楦鱾€(gè)存儲(chǔ)節(jié)點(diǎn)之間沒有明確的主從關(guān)系，DistributedLog可以從任意存儲(chǔ)著相關(guān)數(shù)據(jù)的存儲(chǔ)節(jié)點(diǎn)上讀出數(shù)據(jù)。為了獲得可預(yù)期的低延遲，DistributedLog引入了一個(gè)推理式讀機(jī)制，即在超出了配置的讀操作時(shí)限之后，它會(huì)在不同的副本上再次嘗試獲取數(shù)據(jù)。

這就可能會(huì)對(duì)存儲(chǔ)節(jié)點(diǎn)導(dǎo)致比Kafka更高的讀壓力。不過，如果將讀超時(shí)時(shí)間配成可以讓99%的存儲(chǔ)節(jié)點(diǎn)的讀操作都不會(huì)超時(shí)，那就可以極大程度地解決延遲問題，只帶來1%的額外讀壓力。

對(duì)于讀的考慮和機(jī)制上的不同主要源于復(fù)制機(jī)制和存儲(chǔ)節(jié)點(diǎn)的I/O系統(tǒng)的不同，在下文會(huì)繼續(xù)討論。

復(fù)制

Kafka用的是ISR復(fù)制算法：將一個(gè)代理服務(wù)器選為主。所有寫操作都被發(fā)送到主代理上，所有處于ISR集合中的從代理都從主代理上讀取和復(fù)制數(shù)據(jù)。主代理會(huì)維護(hù)一個(gè)高水位線(HW，High Watermark)，即每個(gè)分區(qū)***提交的數(shù)據(jù)記錄的偏移量。高水位線會(huì)不斷同步到從代理上，并周期性地在所有代理上記錄檢查點(diǎn)，以備恢復(fù)之用。在所有ISR集合中的副本都把數(shù)據(jù)寫入了文件系統(tǒng)(并不必須是磁盤)并向主代理發(fā)回了響應(yīng)之后，主代理才會(huì)更新高水位線。

ISR機(jī)制讓我們可以增加或減少副本的數(shù)量，在可用性和性能之間做出權(quán)衡?？墒菙U(kuò)大或縮小副本的集合的副作用是增大了丟失數(shù)據(jù)的可能性。

DistributedLog使用的是Quorum投票復(fù)制算法，這在Zab、Raft以及Viewstamped Replication等一致性算法中都很常見。日志流的屬主會(huì)并發(fā)地把數(shù)據(jù)記錄寫入所有存儲(chǔ)節(jié)點(diǎn)，并在得到超過配置數(shù)量的存儲(chǔ)節(jié)點(diǎn)投票確認(rèn)之后，才認(rèn)為數(shù)據(jù)已成功提交。存儲(chǔ)節(jié)點(diǎn)也只在數(shù)據(jù)被顯式地調(diào)用flush操作刷入磁盤之后才會(huì)響應(yīng)寫入請(qǐng)求。

日志流的屬主也會(huì)維護(hù)一個(gè)日志流的***提交的數(shù)據(jù)記錄的偏移量，就是大家知道的Apache BookKeeper中的LAC(LastAddConfirmed)。LAC也會(huì)保存在數(shù)據(jù)記錄中(來節(jié)省額外的RPC調(diào)用開銷)，并不斷復(fù)制到別的存儲(chǔ)節(jié)點(diǎn)上。DistributedLog中復(fù)本集合的大小是在每個(gè)流的每個(gè)日志分片級(jí)別可配置的。改變復(fù)制參數(shù)只會(huì)影響新的日志分片，不會(huì)影響已有的。

存儲(chǔ)

每個(gè)Kafka分區(qū)都以若干個(gè)文件的形式保存在代理的磁盤上。它利用文件系統(tǒng)的頁緩存和I/O調(diào)度機(jī)制來得到高性能。Kafka也是因此利用Java的sendfile API來高效地從代理中寫入讀出數(shù)據(jù)的。不過，在某些情況下(比如消費(fèi)者處理不及時(shí)、隨機(jī)讀寫等)，頁緩存中的數(shù)據(jù)淘汰很頻繁，它的性能也有很大的不確性性。

DistributedLog用的則是不同的I/O模型。圖三表示了Bookie(BookKeeper的存儲(chǔ)節(jié)點(diǎn))的I/O機(jī)制。寫入(藍(lán)線)、末尾讀(紅線)和中間讀(紫線)這三種常見的I/O操作都被隔離到了三種物理上不同的I/O子系統(tǒng)中。所有寫入都被順序地追加到磁盤上的日志文件，再批量提交到硬盤上。在寫操作持久化到磁盤上之后，它們就會(huì)放到一個(gè)Memtable中，再向客戶端發(fā)回響應(yīng)。

Memtable中的數(shù)據(jù)會(huì)被異步刷新到交叉存取的索引數(shù)據(jù)結(jié)構(gòu)中：記錄被追加到日志文件中，偏移量則在分類賬目的索引文件中根據(jù)記錄ID索引起來。***的數(shù)據(jù)肯定在Memtable中，供末尾讀操作使用。中間讀會(huì)從記錄日志文件中獲取數(shù)據(jù)。由于物理隔離的存在，Bookie節(jié)點(diǎn)可以充分利用網(wǎng)絡(luò)流入帶寬和磁盤的順序?qū)懭胩匦詠頋M足寫請(qǐng)求，以及利用網(wǎng)絡(luò)流出代寬和多個(gè)磁盤共同提供的IOPS處理能力來滿足讀請(qǐng)求，彼此之間不會(huì)相互干擾。

小結(jié)

Kafka和DistributedLog都是設(shè)計(jì)來處理日志流相關(guān)問題的。它們有相似性，但在存儲(chǔ)和復(fù)制機(jī)制上有著不同的設(shè)計(jì)理念，因此有了不同的實(shí)現(xiàn)方式。希望這篇文章能從技術(shù)角度解釋清楚它們的區(qū)別，回答一些問題。我們接下來也會(huì)再多寫一些文章來講講DistributedLog的性能指標(biāo)。