行業動態 | Apache Pulsar 對現代數據堆棧至關重要的四個原因
與 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博客中
