一文簡單理解pulsar和優(yōu)于kafka的兩個痛點(diǎn)

前段時間浪尖推薦過一套奈學(xué)的pulsar課程，很多粉絲問浪尖pulsar到底值不值得學(xué)習(xí)，會不會替代kafka。浪尖個人2018年的時候就接觸了pulsar，而且貢獻(xiàn)了一點(diǎn)點(diǎn)代碼到社區(qū)里，解決了一個和flink整合的bug。今天是整理一篇文章來簡單介紹下pulsar。

1. pulsar的架構(gòu)

首先，我們先看下pulsar官網(wǎng)給出的pulsar架構(gòu)，如下圖：

從架構(gòu)圖中，pulsar集群主要四大模塊：

1）一個或者多個broker節(jié)點(diǎn)。

• broker負(fù)責(zé)處理和負(fù)載均衡從producer接收到的消息。
• broker也負(fù)責(zé)分發(fā)消息給consumer。
• broker也負(fù)責(zé)和pulsar的配置存儲同步，以應(yīng)對多變的協(xié)調(diào)任務(wù)。
• broker負(fù)責(zé)將消息存儲到BookKeeper集群中。
• broker也依賴zookeeper集群，負(fù)責(zé)元數(shù)據(jù)存儲，集群配置，協(xié)調(diào)任務(wù)。
• broker是無狀態(tài)的，跟kafka的broker不同之處就是broker本書不會負(fù)責(zé)數(shù)據(jù)存儲，數(shù)據(jù)存儲是交給了BookKeeper。
  
• 等等

2）BookKeeper集群。

消息隊(duì)列本身理論上講不需要持久化消息，它只需要完成消息的接收和投遞，但是理想的消費(fèi)者機(jī)會可以認(rèn)為不存在。

pulsar支持臨時消息存儲的。

消息持久化投遞-衍生出來的目的就是為了保證那些未確認(rèn)送達(dá)的消息被再次消費(fèi)處理的需求。

Pulsar用BookKeeper來做持久化層，這種計(jì)算存儲-分離的系統(tǒng)還有很多，比如JanusGraph，nebula等。BookKeeper是一個分布式的預(yù)寫日志（wal）系統(tǒng)。

BookKeeper以下幾個特性，比較適合Pulsar的應(yīng)用場景：

• 能讓Pulsar創(chuàng)建多個獨(dú)立的日志，這種獨(dú)立的日志就是ledgers. 隨著時間的推移，Pulsar會為Topic創(chuàng)建多個ledgers。

• 為按條目復(fù)制的順序數(shù)據(jù)提供了非常高效的存儲。

• 保證了多系統(tǒng)掛掉時ledgers的讀取一致性。

• 提供不同的Bookies之間均勻的IO分布的特性。

• 容量和吞吐量都能水平擴(kuò)展。并且容量可以通過在集群內(nèi)添加更多的Bookies立刻提升。

• Bookies被設(shè)計(jì)成可以承載數(shù)千的并發(fā)讀寫的ledgers。使用多個磁盤設(shè)備，一個用于日志，另一個用于一般存儲，這樣Bookies可以將讀操作的影響和對于寫操作的延遲分隔開。

• 除了消息數(shù)據(jù)，cursors也會被持久化入BookKeeper。Cursors是消費(fèi)端訂閱消費(fèi)的位置。BookKeeper讓Pulsar可以用一種可擴(kuò)展的方式存儲消費(fèi)位置。

brokers和bookies是交互過程如下：

著重介紹下ledger

ledger是一個只追加的數(shù)據(jù)結(jié)構(gòu)，并且只有一個寫入器，這個寫入器負(fù)責(zé)多個BookKeeper存儲節(jié)點(diǎn)（就是Bookies）的寫入。ledger的條目會被復(fù)制到多個bookies。Ledgers本身有著非常簡單的語義：

• Pulsar Broker可以創(chuàng)建ledeger，添加內(nèi)容到ledger和關(guān)閉ledger。

• 當(dāng)一個ledger被關(guān)閉后，除非明確的要寫數(shù)據(jù)或者是因?yàn)閷懭肫鲯斓魧?dǎo)致ledger關(guān)閉，這個ledger只會以只讀模式打開。

• 最后，當(dāng)ledger中的條目不再有用的時候，整個legder可以被刪除（ledger分布是跨Bookies的）。

• 讀一致性。由于ledger只能被一個進(jìn)程（也就是寫入器進(jìn)程）寫入，這樣這個進(jìn)程就不會在寫入時不會有沖突，從而保證了寫入的高效。在一次故障之后，ledger會啟動一個恢復(fù)進(jìn)程來確定ledger的最終狀態(tài)并確認(rèn)提交到日志的是哪一個條。這就保證了所有l(wèi)edger讀進(jìn)程讀取到相同的內(nèi)容。

• Managed ledgers 。

  由于BookKeeper提供了單一的日志抽象，在ledger的基礎(chǔ)上pulsar提供了一個叫做managed ledger的庫，用于表示單個topic的存儲層。managed ledger即消息流的抽象，有一個寫入器進(jìn)程不斷在流結(jié)尾添加消息，并且有多個cursors消費(fèi)這個流，每個cursor有自己的消費(fèi)位置。

  一個managed ledger在內(nèi)部用多個BookKeeper ledgers保存數(shù)據(jù)，這么做有兩個原因：

• 在故障之后，原有的某個ledger不難再寫了，需要創(chuàng)建一個新的。

• ledger在所有cursors消費(fèi)完它所保存的消息之后就可以被刪除了，這樣可以實(shí)現(xiàn)ledgers的定期翻滾從頭寫。
  

3）zookeeper集群

pulsar主要依賴zookeeper做它擅長的，元數(shù)據(jù)存儲，集群配置和一些協(xié)調(diào)任務(wù)。由于BookKeeper也需要zookeeper，所以企業(yè)中這兩個zookeeper在負(fù)載不是很大的情況下，也可以共享的。

嘮嘮Zookeeper的觀察者

對于pulsar實(shí)例：

• 配置和仲裁存儲：

  存儲租戶，命名域和其他需要全局一致的配置項(xiàng)。

  
  

• 每個集群有自己獨(dú)立的zookeeper保存集群內(nèi)部的配置和協(xié)調(diào)信息，例如歸屬信息，broker負(fù)載報(bào)告，BookKeeper ledger信息（這個是BookKeeper自身的依賴）等等。

4）client模塊

Pulsar 通過“訂閱”，抽象出了統(tǒng)一的: producer-topic-subscription-consumer 消費(fèi)模型。Pulsar 的消息模型既支持隊(duì)列模型，也支持流模型。

生產(chǎn)者沒啥好介紹的，重點(diǎn)介紹一下，消費(fèi)者的訂閱模式。pulsar也有topic的概念，每個topic對應(yīng)著BookKeeper中的一個分布式日志。生產(chǎn)者發(fā)送消息到指定topic，然后bookKeeper會講消息存儲到多個節(jié)點(diǎn)上。topic的消息可以被反復(fù)訂閱。

跟kafka一樣，一個topic可以被多個消費(fèi)者組消費(fèi)，不同的是pulsar的每個消費(fèi)者組可以擁有自己不同的消費(fèi)方式：獨(dú)占（Exclusive），故障切換（Failover）或共享（Share）。

• 獨(dú)占訂閱（Stream 流模型）

  一個消費(fèi)者組

• 有且僅有一個消費(fèi)者消費(fèi)topic的消息。任何新加消費(fèi)者都不被允許。獨(dú)占模式消費(fèi)者體現(xiàn)互斥性。
  

  

• 故障切換（Stream 流模型）

  
  

  多個消費(fèi)者可以添加到同一個消費(fèi)者組訂閱中，但是一個訂閱中的所有消費(fèi)者，只能有一個活躍的消費(fèi)者作為主消費(fèi)者。其他消費(fèi)者是備胎型消費(fèi)者。

  順序性和安全性有點(diǎn)保證。
  

  

• 共享訂閱（Queue 隊(duì)列模型）

  
  

  該模式同一個訂閱組可以按照需要掛在多個消費(fèi)者。topic中的所有消息以循環(huán)分發(fā)的形式發(fā)送給訂閱組內(nèi)的多個消費(fèi)者，一個消息僅傳遞給一個消費(fèi)者。

  當(dāng)消費(fèi)者斷開連接時，所有傳遞給它但是未被確認(rèn)（ack）的消息將被重新分配和組織，以便發(fā)送給該訂閱上剩余的剩余消費(fèi)者。

  

  無順序性。

2. pulsar vs kafka

對于很多粉絲關(guān)心的pulsar使用的優(yōu)點(diǎn)，浪尖也不準(zhǔn)備特別細(xì)致的介紹，這里主要從故障轉(zhuǎn)移和擴(kuò)容兩個生產(chǎn)痛點(diǎn)介紹下。

a）broker故障

broker故障導(dǎo)致該節(jié)點(diǎn)所存儲的分區(qū)不可用，這個在生產(chǎn)中常見的問題對于kafka來說是相當(dāng)棘手。在isr列表不為空的情況下，還是能完成分區(qū)leader的切換的。但是還要完成副本增加的數(shù)據(jù)同步的過程，同時邀請ack大于1，才能保證數(shù)據(jù)不丟失。

pulsar的broker故障，由于broker無狀態(tài)的（broker只是個代理，存儲由BookKeeper負(fù)責(zé)），所以只牽涉到所有權(quán)被其他broker接管的問題。因?yàn)樗恍枰匦聫?fù)制數(shù)據(jù)，所以所有權(quán)轉(zhuǎn)移立即發(fā)生而不會犧牲主題分區(qū)的可用性。

b）擴(kuò)容

kafka集群容量受限于做弱的機(jī)器最小的磁盤，當(dāng)然這種不均衡很少發(fā)生，企業(yè)中kafka的機(jī)器配置往往最硬的。

kafka擴(kuò)容感覺管理過kafka的朋友都應(yīng)該體會過其復(fù)雜，擴(kuò)容難點(diǎn)：

1）主要在于增加機(jī)器之后，數(shù)據(jù)需要rebalance到新增的空閑節(jié)點(diǎn)，即把partitions遷移到空閑機(jī)器上。kafka提供了bin/kafka-reassign-partitions.sh工具，完成parttition的遷移。

2）kafka的集群的數(shù)據(jù)量加大，數(shù)據(jù)rebalance的時間較長。

成長型的企業(yè)，這點(diǎn)確實(shí)會讓kafka集群運(yùn)維管理大佬深惡痛絕。

但是pulsar擴(kuò)容就相當(dāng)簡單了，broker可以根據(jù)需要無影響擴(kuò)容，存儲只需要對BookKeeper集群擴(kuò)容即可，無需人工去遷移數(shù)據(jù)，不干擾線上應(yīng)用。

單就擴(kuò)容這點(diǎn)，pulsar完虐kafka，pulsar甚至可以存儲全量數(shù)據(jù)。