摘要：Pulsar作為一個雲原生的分布式消息流平台，越來越頻繁地出現在人們的視野中，大有替代Kafka江湖地位的趨勢。
本文分享自華為雲社群《MRS Pulsar：下一代分布式消息流平台全新釋出！》，作者： Lothar。
Apache Pulsar是一個釋出-訂閱消息系統，使用計算與存儲分離的雲原生架構。Pulsar 2018年9月成為ASF頂級項目，近兩年，随着社群不斷發展和諸多企業的應用和貢獻，Pulsar作為一個雲原生的分布式消息流平台，越來越頻繁地出現在人們的視野中，大有替代Kafka江湖地位的趨勢。
Pulsar和Kafka架構上最大的不同是，Kafka由Broker進行消息的收發和持久化，資料存儲在本地檔案系統，由Broker統一管理。這也意味着資料和消息處理是耦合的。
Kafka官網描述道：Kafka重度依賴檔案系統，用于存儲或緩存消息。當Broker接收到消息時，會将消息追加寫到本地磁盤上。這一架構決定了Partition和Broker的對應關系是相對固定的，隻有在partition reassign時才會發生資料遷移。Partition的Leader在資料副本分布節點上産生，用于處理生産消費請求。
而Pulsar采用了計算存儲分離架構，這也是Pulsar被稱作雲原生平台的主要原因。Pulsar依賴Apache BookKeeper管理持久化資料，Apache BookKeeper是可擴充、可容錯、低延遲的日志存儲服務，能夠保證在強持久性下的低延遲讀寫。
*引自Pulsar官網介紹：https://pulsar.apache.org/docs/en/concepts-architecture-overview/
Broker接收請求後，資料實際分布式存儲在BookKeeper服務中。在資料的實體存儲模型中某個Topic或Partition的資料并不固定存儲在某個Bookie執行個體上。
Pulsar将分布式日志劃分為多個Segment，每個Segment對應BookKeeper中的一個Ledger。與Kafka将某一Partition的資料日志儲存在某一固定目錄下不同，Pulsar通過劃分Segment的方式，可以将同一topic或partition分布到不同的Bookie上。
相信很多使用Kafka的客戶都有類似的經曆：
磁盤空間不足，隻能調整資料TTL，或擴容機器後向新的Broker中遷移Partition
Topic或Partition間資料配置設定不均勻，節點之間或磁盤之間使用不均衡，有的磁盤已經滿了，而有的磁盤還有很多空間
Broker機器故障，需要将資料遷移到其他節點後下電維修
Pulsar的存算分離架構天然地避免了這些問題。Pulsar Broker本身是無狀态的，當某個Broker故障時，另一個Broker可以立即接管對應的Topic而不需要遷移資料。BookKeeper分布式日志保證了存儲節點間的資料均衡，不會因某一個Partitoin或Topic資料過多而導緻IO集中在某一節點上。
當叢集需要擴容時，Broker可以立即感覺到新加入叢集的Bookie，并将新寫入的資料存儲到新添加的Bookie中。
Kafka社群在KIP-37正在讨論加入NameSpace以實作多租戶特性，而Pulsar已實作這一功能。在企業中，消息隊列服務通常會被多個團隊使用，在使用Kafka時，有時需要為每個團隊維護一個Kafka叢集。Pulsar可以配置多個租戶，每個租戶可以有多個NameSpace，管理者可以對NameSpace進行通路控制、配額管理。
Kafka對消息的劃分分為兩層：對于屬于同一個Group的KafkaConsumer，其擷取到的消息是互斥的，即某一條消息隻能被Group中的一個Consumer處理；對于不同的Group，某一條消息将同時被兩個Group處理，消息是共享的。
而Pulsar提供了更靈活的訂閱模式：
獨占式：
在任意時間，Topic中的資料隻能被Group中的一個Consumer消費，不允許其他Consumer擷取消息
主備式：
多個Consumer同時消費同一個Topic時，隻有一個Consumer被選為主Consumer，其他Consumer則成為備Consumer。當主Consumer故障時，發生主備倒換，備Consumer中的一個将升主，并繼續消息的消費。
共享式：
與Kafka類似，使用共享模式，消息将循環分發給不同的Consumer，當某個Consumer故障時，消息将被重新配置設定給其他Consumer。
Pulsar另一個很有吸引裡的特性是，流式資料可以轉冷并存儲在更廉價的存儲媒體上。通常為了保證性能，流式處理系統配備高性能的SSD。對于Kafka來說，所有需要保留的消息都必須駐留在昂貴的SSD上。有些時候，資料寫入一段時間後已不在會被使用，但仍需保留一段時間存檔。Pulsar支援将這種冷資料轉儲到離線存儲系統中，BookKeeper隻需要保留一部分熱資料，可以節省很多存儲成本。該特性無疑是很有價值的，Kafka社群同樣在進行設計（KIP-405），但目前還沒有實作。
Kafka和Pulsar社群都針對性能進行了對比測試。綜合來看，由于Pulsar資料落盤時，會進行同步fsync，持久性要比Kafka更高，Pulsar社群對此作出修改後進行對比測試，部分測試結果如下：
*引自Pulsar社群性能測試報告
在100 Partition時，預設配置下pulsar的吞吐量距離Kafka差距明顯，但當本地持久化等級設定為與Kafka相同時，吞吐量與Kafka基本持平。
當Partition數增加到2000個時，Pulsar預設本地持久度的吞吐量基本與Kafka持平。
更多細節請移步SreamNative的benckmarking測試報告：benchmarking pulsar kafka a more accurate perspective on pulsar performance.pdf
MRS已釋出Pulsar的POC版本，客戶可以一鍵式部署Pulsar服務，包括Broker和Bookie角色。支援在Web UI上修改Pulsar配置、啟停、監控。
此外MRS還預設內建了KoP。KoP是Pulsar社群開源的一個插件，運作在Pulsar上，用以相容Kafka協定。使用時，Kafka用戶端可以修改連接配接位址後直接切換到Pulsar叢集上，而不需要修改業務對Kafka用戶端的依賴。
在MRS Pulsar的商用版本正在規劃中，我們将探索Pulsar在雲上使用的更多可能，進一步發揮Pulsar存算分離的優勢，降低成本，提升資源使用率，為客戶創造更多價值，敬請期待。
點選關注，第一時間了解華為雲新鮮技術~