怎么實現(xiàn)Kafka和Twitter新開源的DistributedLog技術對比

本篇文章給大家分享的是有關怎么實現(xiàn)Kafka和Twitter新開源的DistributedLog技術對比，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

我們簡單地介紹一下Kafka和DistributedLog的概況。

Kafka是什么?

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

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

DistributedLog是什么?

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

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

Kafka與DistributedLog有什么不同?

因為同類事物才有可比較的基礎，所以我們只在本文中把Kafka分區(qū)和DistributedLog流相對比。下表列出了兩套系統(tǒng)之間最顯著的不同點。

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

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

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

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

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

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

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

與Kafka相似，DistributedLog也可以為每個流配置有效期，并在超時之后將相應的日志分片失效或刪除。除此之外，DistributedLog還提供了顯示的截斷機制。應用程序可以顯式地將一個日志流截斷到流的某個指定位置。這對于構建可復制的狀態(tài)機非常有用，因為可復制的狀態(tài)機需要在刪除日志記錄之前先將狀態(tài)持久化。Manhattan就是一個用到了這個功能的典型系統(tǒng)。

操作

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

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

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

寫與生產(chǎn)者

如圖一所示，Kafka生產(chǎn)者把數(shù)據(jù)一批批地寫到Kafka分區(qū)的主代理服務器上。而ISR(同步復制)集合中的從代理服務器會從主代理上把記錄復制走。只有在主代理從所有的ISR集合中的副本上都收到了成功的響應之后，一條記錄才會被認為是成功寫入的。可以配置讓生產(chǎn)者只等待主代理的響應，還是等待ISR集合中的所有代理的響應。

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

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

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

讀與消費者

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

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

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

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

復制

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

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

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

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

存儲

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

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

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

以上就是怎么實現(xiàn)Kafka和Twitter新開源的DistributedLog技術對比，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。