本文作者：劉德志
騰訊專家工程師、TEG 技術工程事業群和計費系統開發者
背景
Apache Pulsar 是下一代分散式訊息流平臺，採用計算儲存分層架構，具備多租戶、高一致、高效能、百萬 topic、資料平滑遷移等諸多優勢。越來越多的企業正在使用 Pulsar 或者嘗試將 Pulsar 應用到生產環境中。
騰訊把 Pulsar 作為計費系統的訊息匯流排來支撐千億級線上交易。騰訊計費體量龐大，要解決的核心問題就是必須確保錢貨一致。首先，保證每一筆支付交易不出現錯賬，做到高一致、高可靠。其次，保證計費承載的所有業務 7*24 可用，做到高可用、高效能。計費訊息匯流排必須具備這些能力。
Pulsar 架構解析
在一致性方面，Pulsar 採用 Quorum 演算法，通過 write quorum 和 ack quorum 來保證分散式訊息佇列的副本數和強一致寫入的應答數(A>W/2)。在效能方面，Pulsar 採用 Pipeline 方式生產訊息，通過順序寫和條帶化寫入降低磁碟 IO 壓力，多種快取減少網路請求加快消費效率。
Pulsar 效能高主要體現在網路模型、通訊協議、佇列模型、磁碟 IO 和條帶化寫入。下面我會一一詳細講解。
網路模型
Pulsar Broker 是一個典型的 Reactor 模型，主要包含一個網路執行緒池，負責處理網路請求，進行網路的收發以及編解碼，接著把請求通過請求佇列推送給核心執行緒池進行處理。首先，Pulsar 採用多執行緒方式，充分利用現代系統的多核優勢，把同一任務請求分配給同一個執行緒處理，儘量避免執行緒之間切換帶來的開銷。其次，Pulsar 採用佇列方式實現了網路處理模組及核心處理模組的非同步解耦，實現了網路處理和檔案 I/O 並行處理，極大地提高了整個系統的效率。
通訊協議
資訊（message）採用二進位制編碼，格式簡單；客戶端生成二進位制資料直接傳送給 Pulsar 後端 broker，broker 端不解碼直接傳送給 bookie 儲存，儲存格式也是二進位制，所以訊息生產消費過程沒有任何編解碼操作。訊息的壓縮以及批量傳送都是在客戶端完成，這能進一步提升 broker 處理訊息的能力。
佇列模型
Pulsar 對主題（topic）進行分割槽（partition），並儘量將不同的分割槽分配到不同的 Broker，實現水平擴充套件。Pulsar 支援線上調整分割槽數量，理論上支援無限吞吐量。雖然 ZooKeeper 的容量和效能會影響 broker 個數和分割槽數量，但該限制上限非常大，可以認為沒有上限。
磁碟 IO
訊息佇列屬於磁碟 IO 密集型系統，所以優化磁碟 IO 至關重要。Pulsar 中的磁碟相關操作主要分為操作日誌和資料日誌兩類。操作日誌用於資料恢復，採用完全順序寫的模式，寫入成功即可認為生產成功，因此 Pulsar 可以支援百萬主題，不會因為隨機寫而導致效能急劇下降。
操作日誌也可以是亂序的，這樣可以讓操作日誌寫入保持最佳寫入速率，資料日誌會進行排序和去重，雖然出現寫放大的情況，但是這種收益是值得的：通過將操作日誌和資料日誌掛在到不同的磁碟上，將讀寫 IO 分離，進一步提升整個系統 IO 相關的處理能力。
條帶化寫入
條帶化寫入能夠利用更多的 bookie 節點來進行 IO 分擔；Bookie 設定了寫快取和讀快取。最新的訊息放在寫快取，其他訊息會批量從檔案讀取加入到讀快取中，提升讀取效率。
從架構來看，Pulsar 在處理訊息的各個流程中沒有明顯的卡點。操作日誌持久化只有一個執行緒來負責刷盤，可能會造成卡頓。根據磁碟特性，可以設定多塊盤，多個目錄，提升磁碟讀寫效能，這完全能夠滿足我們的需求。
測試
在騰訊計費場景中，我們設定相同的場景，分別對 Pulsar 和 Kafka 進行了壓測對比，具體的測試場景如下。
壓測資料如下:
以上資料可以看到，網路 IO 方面，3 個副本多分割槽的情況下，Pulsar 幾乎要把 broker 網路卡出流量跑滿，因為一份資料需要在 broker 端分發 3 次，這是計算儲存分離的代價。
Kafka 的效能資料有點讓人失望，整體效能沒有上去，這應該和 Kafka 本身的副本同步機制有關：Kafka 採用的是 follow 同步拉取的策略，導致整體效率並不高。
延遲方面，Pulsar 在生產端表現更優越些，當資源沒有到達瓶頸時，整個時耗 99% 在 10 毫秒以內，在垃圾回收（Garbage Collection，GC）和建立操作日誌檔案時會出現波動。
從壓測的結果來看，在高一致的場景下，Pulsar 效能優於 Kafka。如果設定 log.flush.interval.messages=1 的情況，Kafka 效能表現更差，kafka 在設計之初就是為高吞吐，並沒有類似直接同步刷盤這些引數。
此外，我們還測試了其他場景，比如百萬 Topic 和跨地域複製等。在百萬 Topic 場景的生產和消費場景測試中，Pulsar 沒有因為 Topic 數量增長而出現效能急劇下降的情況，而 Kafka 因為大量的隨機寫導致系統快速變慢。
Pulsar 原生支援跨地域複製，並支援同步和非同步兩種方式。Kafka 在同城跨地域複製中，吞吐量不高，複製速度很慢，所以在跨地域複製場景中，我們測試了 Pulsar 同步複製方式，儲存叢集採用跨城部署，等待 ACK 時必須包含多地應答，測試使用的相關引數和同城一致。測試結果證明，在跨城情況下，Pulsar 吞吐量可以達到 28萬QPS。當然，跨城跨地域複製的效能很大程度依賴於當前的網路質量。
可用性分析
作為新型分散式訊息流平臺，Pulsar 有很多優勢。得益於 bookie 的分片處理以及 ledger 選擇儲存節點的策略，運維 Pulsar 非常簡單，可以擺脫類似 Kafka 手動平衡資料煩擾。但 Pulsar 也不是十全十美，本身也存在一些問題，社群仍在改進中。
Pulsar 對 ZooKeeper 的強依賴
Pulsar 對 ZooKeeper 有很強的依賴。在極限情況下，ZooKeeper 叢集出現當機或者阻塞，會導致整個服務當機。ZooKeeper 叢集奔潰的概率相對小，畢竟 ZooKeeper 經過了大量線上系統的考驗，使用還是相對廣泛的。但 ZooKeeper 堵塞的概率相對較高，比如在百萬 Topic 場景下，會產生百萬級的 ledger 後設資料資訊，這些資料都需要與 ZooKeeper 進行互動。
例如，建立一次主題（topic），需要建立主題分割槽後設資料、Topic 名、Topic 儲存 ledger 節點；而建立一次 ledger 又需要建立和刪除唯一的 ledgerid 和 ledger 後設資料資訊節點，一共需要 5 次 ZooKeeper 寫入操作，一次訂閱也需要類似的 4 次 ZooKeeper 寫入操作，所以總共需要 9 次寫入操作。如果同時集中建立百萬級的主題，勢必會對 ZooKeeper 造成很大的壓力。
Pulsar 具有分散 ZooKeeper 部署的能力，能夠在一定程度上緩解 ZooKeeper 的壓力，依賴最大的是 zookeeperServer 這個 ZooKeeper 叢集。從之前的分析來看，寫操作相對可控，可以通過控制檯建立 Topic。bookie 依賴的 ZooKeeper 操作頻率最高，如果該 ZooKeeper 出現阻塞，當前寫入並不會造成影響。
可以按照同樣的思路優化對 zookeeperServerzk 的依賴。至少對於當前的服務可以持續一段時間，給 ZooKeeper 足夠的時間進行恢復；其次減少 ZooKeeper 的寫入次數，只用於必要的操作，比如 broker 選舉等。像 broker 的負載資訊，可以尋求其他儲存介質，尤其是當一個 broker 服務大量主題時，這個資訊會達到兆（M）級別。我們正在和 Pulsar 社群攜手優化 broker 負載功能。
Pulsar 記憶體管理稍複雜
Pulsar 的記憶體由 JVM 的堆記憶體和堆外存構成，訊息的傳送和快取通過堆外記憶體來儲存，減少 IO 造成的垃圾回收（GC）；堆記憶體主要快取 ZooKeeper 相關資料，比如 ledger 的後設資料資訊和訂閱者重推的訊息 ID 快取資訊，通過 dump 記憶體分析發現，一個 ledger 後設資料資訊需要佔用約 10K，一個訂閱者者重推訊息 ID 快取初始為 16K，且會持續增長。當 broker 的記憶體持續增長時，最終頻繁進行整體垃圾回收（full GC），直到最終退出。
要解決這個問題，首先要找到可以減少記憶體佔用的欄位，比如 ledger 後設資料資訊裡面的 bookie 地址資訊。每個 ledger 都會建立物件，而 bookie 節點非常有限，可以通過全域性變數來減少建立不必要的物件；訂閱者重推訊息 ID 快取可以把初始化控制在 1K 內，定期進行縮容等。這些操作可以大大提升 Broker 的可用性。
和 Kafka 相比，Pulsar broker 的優點比較多，Pulsar 能夠自動進行負載均衡，不會因為某個 broker 負載過高導致服務不穩定，可以快速擴容，降低整個叢集的負載。
總結
總體來說，Pulsar 在高一致場景中，效能表現優異，目前已在騰訊內部廣泛使用，比如騰訊金融和大資料場景。大資料場景主要基於 KOP 模式，目前其效能已經非常接近 Kafka，某些場景甚至已經超越 Kafka。我們深信，在社群和廣大開發愛好者的共同努力下，Pulsar 會越來越好，開啟下一代雲原生訊息流的新篇章。
