Pulsar是一款分佈式發佈/訂閱消息平臺，近兩年很是火，被稱爲下一代的消息流平臺，大有取代Kafka的勢頭。今天咱們就來比較一下Pulsar跟Kafka。
歷史背景
Pulsar源自Yahoo，於2016年開源並捐獻給Apache基金會，並在2018年9月升級成爲Apache頂級項目。
Kafka最初由Linkedin開發，並於2010年貢獻給了Apache基金會，以後成爲Apache頂級項目。
架構
Kafka
Kafka架構由broker和zookeeper組成，以下圖：
注意：Kafka2.8版本能夠不依賴Zookeeper獨立運行了
Pulsar
Pulsar的架構以下：
Pulsar Broker會在本地緩存消息，而且支持TTL，
從上面的2個架構咱們看到，Kafka和Pulsar有3點不一樣：
Pulsar採用分層架構，將計算和存儲相分離，存儲使用BookKeeper集羣，計算使用Broker集羣，Broker須要內置BookKeeper客戶端。
Pulsar的部署和架構更加複雜，可是也更具備伸縮性。
Pulsar在最新版本中依然不能脫離Zookeeper獨立運行。
消息存儲模型
Kafka
Kafka採用分區(Partition)的方式來保存topic，模型圖以下：
每一個topic都會在不一樣的broker保存多個分區副本，其中只有一個副本的分區是leader分區，供消費者使用。若是某個broker宕機了，這個broker上的leader分區失效，須要在其餘broker上從新進行選舉。
Pulsar
跟Kafka不一樣的是，Pulsar的消息存儲模型採用了分層的方式，以下圖：
第一層是Topic，用來存儲Producer追加的messages，Topic下面是ledger層，保存了分片(Segment)，分片裏面保存更小粒度的ertries，entries存儲一條條的Message。
Bookkeeper中，數據的最小操做單位是Segment。
Ledger中的最後一個分片是最新寫入的分片，如上圖Segment-2。Segment-2以前的全部分片已完成封裝，這些分片的數據是不會再發生變化的。這樣增長或刪除一個BookKeeper節點，或者遷移長期存儲節點，都不會發生一致性問題。
消息消費模型
Kafka
Kafka的消費模型是採用消費者組的模式，每個分區只能給消費者組中的一個消費者消費。以下圖：
Pulsar
Pulsar的消費模型以下圖：
Pulsar的topic是一種partitioned topic，能夠被保存到多個broker，提升了topic的吞吐量。
Consumer經過Subscription獲取消息，同一Topic的Subscription能夠獲取到Topic數據的完整拷貝，這樣Subscription爲每個Consumer分配一個Cursor，Consumer之間互不影響。以下圖：
數組
Pulsar的消費模型有4種：
獨佔模式(Exclusive):同一個topic只能有一個消費者訂閱，若是多個消費者訂閱，就會出錯。
災備模式(Failover)：同一個topic能夠有多個消費者訂閱，可是隻能有一個消費者消費，其餘訂閱的消費者做爲故障轉移的消費者，只有當前消費者出了故障才能夠進行消費當前的topic。以下圖：
共享訂閱(Shared):同一個topic能夠由多個消費者訂閱和消費。消息經過round robin輪詢機制分發給不一樣的消費者，而且每一個消息僅會被分發給一個消費者。當消費者斷開，發送給它的沒有被消費的消息還會被從新分發給其它存活的消費者。以下圖：
Key_Shared：消息和消費者都會綁定一個key，消息只會發送給綁定同一個key的消費者。若是有新消費者創建鏈接或者有消費者斷開鏈接，就須要更新一些消息的key。以下圖：
多租戶
Pulsar
Pulsar是一個多租戶系統，租戶能夠跨集羣分佈，每一個租戶均可以有單獨的認證和受權機制。租戶也是存儲配額、消息 TTL 和隔離策略的管理單元。
Pulsar中topic的URL以下，能夠看到租戶是最基本的管理單位：
persistent://tenant/namespace/topic
上面的URL能夠看到，Pulsar經過tenant和namespace來支持多租戶。
namespace是一個術語，指租戶的管理單元。同一個namespace上設置的配置策略適用於在namespace中建立的全部 topic。
Pulsar爲實例中的每一個租戶分配：
受權機制
適用於租戶配置的集羣配置
Kafka
Kafka爲了控制客戶端對broker資源的限制，從0.9版本引入了配額(quotas)管理，強制客戶端請求使用配額。目前Kafka支持兩種類型的配額：
網絡帶寬配額，用來定義byte-rate閾值(從0.9版本開始)
請求速率配額，將CPU利用率閾值定義爲網絡和I/O線程的百分比(從0.11開始)
生產者和消費者有可能以很高的速率生產和消費大量的請求，從而壟斷broker資源，致使網絡飽和，最終影響到其餘客戶端和broker自己。使用配額能夠防止這些問題，讓集羣體驗更好。
運維
集羣部署
Kafka去除Zookeeper之後，部署是很是簡單的。而Pulsar目前尚未去除Zookeeper的詳細計劃，並且須要使用到BookKeeper集羣，部署複雜很多。
擴容
Pulsar支持自動負載均衡，這對於增長broker節點和增長存儲節點都很是方便。
雲原生支持
Pulsar 計算和存儲節點分離，對雲原生支持很好。
Kafka 多數組件也支持雲原生。
替換broker
Pulsar的broker節點是無狀態的，替換時不用考慮數據丟失。
社區
Pulsar社區發展很是迅速，StreamNative 還推出了StreamNative Hub來支持Pulsar社區建設。[4]
但Pulsar畢竟是一個新型的消息中間件，文檔和社區都不太完善。在過去的一年多時間裏，Pulsar在這方面作了不少的努力，包括舉辦全球峯會，創做視頻和培訓教程，邀請專業講師進行培訓。
使用Pulsar時，遇到的一些問題可能在網上找不到答案，須要查找源代碼來解決。這對於中小公司來講，無疑增長了使用成本。
而Kafka做爲很是成熟中間件，用戶遇到的問題也很是多，新用戶能夠很方便地從網上找到答案。
總結
Pulsar做爲新型的雲原生分佈式消息流平臺，確實有不少優秀的設計理念。
在Yahoo內部支持應用服務平臺中 140 萬個topic，日處理消息超過 1000 億條。騰訊的分佈式交易引擎 TDXA也使用了Pulsar，應用於騰訊的計費平臺。[5]
kafka目前的使用場景最多的仍是日誌大數據處理，對金融場景的應用比較少。
但這並不能說明Pulsar能夠取代Kafka，Kafka用戶羣體龐大，社區和資源完善，並且在2.8版本中去除了Zookeeper，部署很是容易。畢竟不是每家公司都須要Yahoo和騰訊這樣的集羣體量。
緩存