為什麼Nutanix Beam繼續使用Apache Pulsar而不是Apache Kafka？
在Nutanix Beam（Saas產品）中，我們處理大量數據以查找有關雲支出，以及雲安全性的見解。 Nutanix Beam建立在我們的微服務和服務網格架構上，使用Consul，Nomad，Vault，Envoy和Docker進行同步RPC請求。 儘管我們不會在這裡討論我們的微服務架構（這是在不同的日子和不同的帖子：），但是我們將重點關注支持該架構的關鍵技術-團隊和微服務之間的異步通信。
我們使用Disque＆Conductor進行批處理。 這兩個系統都是基於隊列的系統。 我們希望將發佈/訂閱功能添加到我們的平臺中，這導致我們尋找一種流媒體平臺，在該平臺中我們可以可靠地存儲事件並在需要時重新發送它們。 由於我們的某些團隊成員以前有過Kafka的經驗，並且以中等規模運行Kafka，因此選擇Kafka對我們來說很容易。 但是，在部署技術之前，我們強烈認為，重要的是要了解當前的形勢並驗證我們的技術選擇，以免我們屈服於可能對項目不利的，熟悉的技術。 同樣，務必謹慎地做出此決定，因為流媒體平臺將成為此SaaS產品的關鍵組件。
當我們在Github問題中提到Apache Pulsar時，我們首先了解到它，並決定開始針對我們的流媒體平臺用例對其進行評估。 考慮到Pulsar處於Apache旗下，並且已經從Apache的孵化過程中畢業，成為一個頂級項目，我們可以確信它是一項成熟的技術。 Apache pulsar在Yahoo中已投入生產多年，並採用了此處提到的許多公司。 我們收集了需要流平臺的用例列表，並且開始深入分析Apache Pulsar的體系結構以及Pulsar的協調性，持久性，可靠性，高可用性，容錯性和客戶端生態系統。
Apache Pulsar簡介
Apache Pulsar是最初在Yahoo創建的開源分佈式pub-sub消息傳遞系統，現已成為Apache Software Foundation的一部分。
Apache Pulsar使用一種將消息處理，服務和存儲分離的架構。 存儲層嵌入了Apache BookKeeper，以實現數據持久性，複製和高可用性。 消息服務由構成服務層的一組無狀態代理處理，消息處理由該體系結構自己的層中的Pulsar Functions處理。 此體系結構的每一層都可以獨立擴展-我們可以獨立擴展BookKeeper（存儲層）以提高存儲容量和吞吐量，Pulsar代理（服務層）以提高消息服務吞吐量，而功能層（處理層）則可以處理更多數據處理 。
要了解有關Apache Pulsar的更多信息，請參閱Apache Pulsar網站和文檔。
發展的好處：
收集用例時發現的一件有趣的事情是，我們經常想同時使用消息隊列和pub-sub模型來使用消息。 但是，我們不能將Kafka用作排隊系統，因為您可以擁有的最大工作人員數量受到分區數量的限制，並且由於無法在單個消息級別上確認消息。 您將需要通過在自己的數據存儲中維護單個消息確認的記錄來手動在Kafka中提交偏移量，這會增加很多額外的開銷—我認為這是太多的開銷。
使用Pulsar，您無需擔心要使用哪種模型來使用數據。 在Pulsar中，您可以在偏移級別使用和提交，也可以在消息級別使用和確認。 有關其工作原理的更多詳細信息，Streamlio團隊在此處寫了一個不錯的博客。 同樣值得注意的是，如果使用者崩潰，Apache Pulsar將如何處理消息傳遞：在訂閱級別定義的延遲之後，Pulsar將再次將消息發佈給另一個使用者。
運營收益：
這就是事情變得有趣的地方。 由於我們以中等規模運營Kafka，我們已經瞭解了它的幾個侷限性。 我們看到Pulsar可以解決這些限制並更好地滿足我們的需求。
事件重播和落後的消費者：
在Apache Kafka中，當消費者落後時，由於落後的消費者引入了隨機讀取，因此生產者的吞吐量下降了。 Kafka的架構的設計方式是，高吞吐量取決於僅以追加方式順序訪問數據。
Apache Pulsar通過結合使用基於段的架構和讀寫之間的隔離來解決此問題。 您可以在此博客中瞭解更多信息。 簡而言之，熱讀取由代理的內存中緩存處理，熱寫入由日誌處理。 事件重播/滯後使用者從分類帳讀取訪問數據，分類帳與日誌位於不同的磁盤上。
例如，假設有一個主題，我們有5個消費者，他們所有人閱讀愉快，沒有任何滯後。 在這種情況下，讀取由代理緩存提供。 週期性地，後臺進程將數據從BookKeeper日記帳移到分類帳。 現在想象一下，我們的機器學習工程師突然決定從本主題的開始就決定使用它來訓練/重新訓練他的模型，因為他調整了模型的sigma＆mu :)。 由於滯後的消費/事件重播是由位於不同磁盤中的分類帳提供的，因此事件重播不會影響消費者讀取主題中最新數據的性能。
保留數據而不會爆炸我們的雲賬單
Apache Pulsar通過其存儲分層功能解決了此問題，該功能可以將較舊的數據卸載到可擴展的存儲系統中，例如Amazon s3，Google Cloud Storage，Minio等。我們可以根據時間和大小配置卸載策略。 一旦主題中的數據達到指定的時間或大小閾值，較舊的數據段將移至對象存儲。 最好的部分是，當使用者請求已被卸載到對象存儲的數據時，Pulsar會從對象存儲透明地將該數據提供給使用者。 使用者不知道數據是來自磁盤還是對象存儲。 這樣，您的主題分區大小不僅限於單個代理上的存儲大小。
在線擴展：
將節點添加到Apache Kafka群集不一定能解決與過載節點有關的性能問題。 為什麼不？ 添加到Kafka群集中的新節點將用於添加後創建的新主題，但不會自動減輕過載節點的一些負擔。 要使用它們來分散負載，您需要進行手動的，成本高昂的數據重新平衡，以將某些主題從舊節點遷移到新節點。
在Pulsar中，存儲由Apache BookKeeper提供的存儲層處理。 Pulsar使用基於段的體系結構，其中主題分區中的消息被收集為段，然後將其持久化。 結果，在主題分區和節點之間不存在與Kafka中一樣的一對一映射。 添加新的存儲節點後，某些新段將存儲在新節點上，從而立即減少了先前存在的節點上的負載。
Jack Vanlightly在此博客中有一個很好的圖表，說明了其工作原理。
數百萬個主題：
我們的用例的另一個重要要求是能夠支持數百萬個主題。 例如，假設我們要重播一位客戶的數據。 只要我們為每個客戶創建一個主題，就可以輕鬆地為特定客戶的主題創建訂閱，然後使用該客戶的數據。 就像刪除主題一樣，刪除客戶數據變得非常簡單。
但是，在Apache Kafka中，擴展多個主題是一個實際的體系結構問題。 Kafka為每個主題創建多個文件（資源）。 因此，我們可以創建的主題數量將受到限制。 但是，如果我們要將來自許多甚至所有客戶的數據放在一個主題中，那麼當我們要重放單個客戶的數據時，我們將被迫重放整個主題並丟棄所有消息，但與消息關聯的消息除外。 我們感興趣的單個客戶。即使我們要使用帶有客戶ID的分區主題作為分區鍵，以便我們僅選擇存儲單個客戶數據的分區，也會浪費大量資源。 經紀人和消費者方面。
Pulsar不會按主題創建文件。 由於它使用Apache BookKeeper的細分存儲架構，因此創建的細分數量不受主題數量決定。 我們非常喜歡此功能，因為有了它，我們可以繼續為每個客戶創建一個主題，這是一種更簡單，更有效的設計。
生產部署
Pulsar在生產中運行了最近6個月，並支持用例，例如發佈/訂閱，排隊和架構註冊表。
結論
總的來說，我們對Pulsar的看法是，它極大地簡化了Nutanix Beam中的異步通信設計。 憑藉其可伸縮性和設計，我們可以根據業務用例來決定如何在消費者端使用數據，而不是強迫我們在數據提取期間做出這些決定。 這種靈活性可以幫助我們更好地支持不斷變化的業務需求。
Apache Pulsar is Next Generation Persisted Streaming Pub/Sub & Queuing Platform.
要了解有關apache pulsar的工作方式的更多信息，請閱讀Jack Vanightly撰寫的這篇很棒的文章。 另外，streamlio團隊有不錯的博客文章，深入討論了每個脈衝星建築細節。 Apache Pulsar擁有一個很棒的社區，在幫助我們正確處理併合併合並請求請求時非常受歡迎。
PS：撰寫本文時要記住，每種技術在這個世界上都有其地位。 為了突出某些架構差異，我們將其與kafka進行了比較。 我們過去曾經使用過kafka，也非常感謝kafka＆kafka社區。
在評論部分讓我知道您的想法。 您可以在Twitter上關注我@SkyRocknRoll
(本文翻譯自Yuvaraj Loganathan的文章《Why Nutanix Beam went ahead with Apache Pulsar instead of Apache Kafka?》，參考：https://medium.com/@yuvarajl/why-nutanix-beam-went-ahead-with-apache-pulsar-instead-of-apache-kafka-1415f592dbbb)
閱讀更多 聞數起舞 的文章
