為什么最終選擇了 Pulsar？下面列出了選擇 Pulsar 而不是 Kafka 的 7 大理由。

Pulsar 就像一個合二為一的產品，不僅可以像 Kafka 那樣處理高速率的實時場景，還支持標準的消息隊列模式，比如多消費者、失效備援訂閱和消息扇出等等。Pulsar 會自動跟蹤客戶端的讀取位置，并把這些信息保存在高性能的分布式 ledger（BookKeeper）當中。

與 Kafka 不同，Pulsar 具備傳統消息隊列（如 RabbitMQ）的功能，因此，只需要運行一個 Pulsar 系統就可以同時處理實時流和消息隊列。

如果你用過 Kafka，就一定知道分區是怎么回事。Kafka 中的所有主題都是分區的，這樣可以增加吞吐量。通過分區進而劃分到不同的 broker，單個主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率，又該怎么辦呢？對于這類情況，如果能不考慮分區，避免隨之而來的 API 和管理工作，不是更好嗎？

Pulsar 就可以做到。如果只需要一個主題，可以使用一個主題而無需使用分區。如果需要保持多個消費者實例的處理速率，也不需要使用分區，Pulsar 的共享訂閱可以達到這一目的。

如果確實需要分區來進一步提升性能，Pulsar 也可以支持分區的使用。

Kafka 開發團隊預見了日志對于一個實時數據交換系統的重要性。日志通過追加的方式寫入系統，寫入速度很快。日志中的數據是串行的，可以按照寫入的順序快速讀取數據。相比隨機讀取和寫入，串行讀取和寫入速度更快。對于任何一個提供數據保證的系統來說，持久化存儲方面的交互都是一個瓶頸，而日志抽象最大限度地提升了這方面的效率。

日志固然好，但當數據量過大時，也會給我們帶來一些麻煩，單臺服務器上保存所有日志已經成為一個挑戰。在日志占滿服務器存儲之后該怎么辦？如何進行擴容？或者保存日志的服務器宕機，需要重新從副本創建新的服務器時，該怎么辦？將日志從一臺服務器拷貝到另一臺服務器耗時很長，特別是想要同時保持系統實時數據時，完成這個操作就更難了。

Pulsar 對日志進行分段，從而避免了拷貝大塊的日志。通過 BookKeeper， Pulsar 將日志分段分散到多臺不同的服務器上。也就是說，日志不會保存在單臺服務器上，任何一臺服務器都不會成為整個系統的瓶頸。這使故障處理和擴容更加簡單，只需要加入新的服務器，而無需進行再均衡處理。

對于云原生應用程序開發人員來說，最喜歡的東西就是無狀態。無狀態組件啟動速度快、可替換，還可以實現無縫擴容。如果消息中間件也是無狀態的，那豈不是更好？

Kafka 不是無狀態的，每個 broker 都包含了分區的所有日志，如果一個 broker 宕機，不是所有 broker 都可以接替它的工作。如果工作負載太高，也不能隨意添加新的 broker 來分擔，而是必須與持有其分區副本的  broker 進行狀態同步。

在 Pulsar 架構中，broker 是無狀態的。但是完全無狀態的系統無法持久化消息，所以 Pulsar 不是依靠 broker 來實現消息持久化的。在 Pulsar 架構中，數據的分發和保存是相互獨立的。broker 從生產者接收數據，然后將數據發送給消費者，但數據保存在 BookKeeper 中。

Pulsar 的 broker 是無狀態的，所以如果工作負載很高，可以直接添加新的 broker，快速接管工作負載。

跨域復制是 Pulsar 的拿手好戲。Pulsar 在設計之初就考慮到了這個特性，配置也很容易。無論是全局分布式應用程序還是災備方案，都可以通過 Pulsar  搞定。

基準測試（http://openmessaging.cloud/docs/benchmarks/pulsar/）表明，Pulsar 可以在提供較高吞吐量的同時保持較低的延遲。

Pulsar 提供了很多與 Kafka 相似的特性，比如跨域復制、流式消息處理（Pulsar Functions）、連接器（Pulsar IO）、基于 SQL 的主題查詢（Pulsar SQL）、schema registry，還有一些 Kafka 沒有的特性，比如分層存儲和多租戶。更贊的是，這些功能特性都是開源的。