與 Kafka 相比，Pulsar 的架構使它在跨地域複製、擴充套件、多租戶和佇列等方面具有重要的優勢。
1 月 27 日，DataStax 宣佈收購Kesque（Pulsar 即服務），加入到了 Pulsar 社群，並開源了 Kesque 團隊在Luna Streaming中構建的管理和監控工具。
多年來，DataStax 一直專注於訊息傳遞。一個非常重要的原因是基於微服務的架構日益普及。簡單來說，微服務架構使用訊息匯流排來解耦服務之間的通訊，並簡化重放、錯誤處理和負載峰值。
有了 Cassandra 和 Astra，開發者和架構師就有了這樣一個資料庫生態系統：
-
以開源為基礎
-
非常適合混合雲和多雲部署
-
雲原生，按消費計價
目前還沒有滿足這些需求的訊息傳遞解決方案，因此，我們正在構建一個。
我們從評估最流行的 Apache Kafka 開始。我們發現它在四個方面存在不足：
-
跨地域複製
-
擴充套件
-
多租戶
-
佇列
我們解決了所有這些問題。讓我們逐項看下。
01 跨地域複製
Cassandra 支援資料中心內或跨資料中心的同步和非同步複製。（通常，Cassandra 被配置為區域內的同步複製，以及跨區域的非同步複製。）這使得像Netflix這樣的Cassandra使用者可以為各地的客戶提供低延遲的服務，遵守資料主權規定，並且可以經受住基礎設施故障。（ 當 AWS 需要重啟 218 個 Cassandra 節點修補一個安全漏洞時，“Netflix經歷了0當機”。）
Kafka 被設計為在單個區域內執行，不支援跨資料中心的複製。Kafka 部署區域之外的客戶端只能忍受延遲增加。有幾個專案試圖在客戶端層面向 Kafka 新增跨資料中心的複製，但操作都很困難，而且容易失敗。
和 Cassandra 一樣，Pulsar 在核心伺服器上構建了跨地域複製功能。（也像 Cassandra 一樣，你可以在部署時選擇同步或非同步配置，並且可以按主題配置複製機制。）生產者可以從任何地區寫入共享主題，Pulsar 負責確保這些資訊對各地的消費者均可見。
02 擴充套件
在 Kafka 中，儲存單元是一個段檔案，但是複製單元是一個分割槽中的所有段檔案。每個分割槽都歸一個 leader 代理所有，它會複製給多個 follower。所以，當你需要給 Kafka 叢集增加容量時，在新節點分擔現有節點的負載之前，有些分割槽需要複製到新節點上。
這意味著，增加 Kafka 叢集的容量會使其變慢，而不是變快。如果你的容量規劃恰到好處，這很好，但如果業務需求的變化比你預期的要快，那麼這可能會是一個嚴重的問題。
Pulsar 增加了一個間接層。（Pulsar 也將計算和儲存分開，分別由 broker 和 bookie 管理，但這裡，最重要的部分是 Pulsar 如何通過 Bookkeeper 增加複製的粒度。）在 Pulsar 中，分割槽被分割成 ledger，但和 Kafka 段不同，ledger 可以單獨複製，互不影響。Pulsar 在 Zookeeper 中維護著一個 ledger 到分割槽的對映。因此，當我們向叢集新增一個新的儲存節點時，我們所要做的就是在該節點上啟動一個新的 ledger。現有的資料可以保留在原來的位置，不需要叢集做額外的工作。
要深入瞭解 Pulsar 的架構和儲存模型，請閱讀Jack Vanlightly的博文。
03 多租戶
多租戶基礎設施可以跨多個使用者和組織共享，同時保證它們彼此隔離。一個租戶的活動不應該影響其他租戶的安全或 SLA。
從根本上說，多租戶可以從兩個方面降低成本。首先，簡單地共享單個租戶沒有充分利用的基礎設施——將元件的成本分攤到所有使用者。第二，通過簡化管理——當有幾十、幾百或幾千個租戶時，管理一個例項明顯簡單許多。即使在一個容器化的世界裡，“在這樣一個共享系統上給我分配一個帳戶”也比“為我提供這個服務的一個新例項”容易實現得多。全球性的問題可能由於分散在許多例項中而被掩蓋。
與跨地域複製一樣，多租戶很難移植到沒有這項設計的系統上。Kafka 是單租戶設計，但 Pulsar 從核心上就支援多租戶。
Pulsar 允許我們通過一個介面管理跨多個區域的多個租戶，該介面包括身份驗證和授權、隔離策略（Pulsar 可以選擇在叢集中劃分出專供單個租戶使用的硬體）和儲存配額。CapitalOne 在這裡對 Pulsar 的多租戶做了很好的概述。
DataStax 提供的新 Pulsar 控制檯進一步簡化了這項工作。
04 佇列（也即流）
Kafka 提供了一個經典的釋出/訂閱（publish/subscribe）訊息模型——釋出者傳送訊息給 Kafka，後者在主題中按分割槽排序，並給每個訂閱者（或”消費者“）傳送一份副本。
Kafka 用日誌中的偏移量記錄消費者已經看到了哪條訊息。這意味著訊息不能亂序確認，同時也意味著不能跨多個消費者共享訂閱。（在其消費者分組設計中，Kafka 允許將多個分割槽對映到一個消費者，但不能反過來。）
這對於釋出/訂閱用例（有時稱為流）來說很好。對於流，重要的是要以與訊息釋出時相同的順序消費訊息。
Pulsar 支援釋出/訂閱模式，但也支援排隊模式，在後一種情況下，處理順序並不重要，我們只想在任意數量的消費者之間平衡一個主題的訊息：
這（以及面向佇列的特性，如“死信佇列”和支援重新傳送的否定確認）意味著 Pulsar 經常可以取代 AMQP 和 JMS 以及 Kafka 風格的釋出/訂閱，採用 Pulsar 的企業有機會進一步降低成本。
05 小結
與 Kafka 相比，Pulsar 的架構使它在跨地域複製、擴充套件、多租戶和佇列等方面具有重要的優勢。1 月 27 日，DataStax 宣佈收購Kesque（Pulsar 即服務），加入到了 Pulsar 社群，並開源了 Kesque 團隊在Luna Streaming中構建的管理和監控工具。
本文由DataStax CTO Jonathan Ellis原創 最初發布在DataStax部落格中