選擇Apache Pulsar而不是Kafka的理由 - Kafkaesque

1.流和排隊在一起
Apache Pulsar就像兩個產品合而為一。它不僅可以處理像Kafka這樣的高速率，實時的用例，而且還支援標準的訊息佇列模式，例如競爭的使用者，故障轉移訂閱和簡單的訊息散出。Apache Pulsar自動跟蹤主題中客戶端的讀取位置，並將該資訊儲存在其高效能分散式分類帳Apache BookKeeper中。
與Kafka不同，Apache Pulsar可以處理許多像RabbitMQ傳統排隊系統的用例。因此，您無需執行兩個系統：一個實時流傳輸，一個系統進行排隊，而使用Pulsar來執行一個系統來執行。

2. 分割槽，但不是必須分割槽
如果您使用Kafka，則會了解分割槽。所有主題都在Kafka中劃分。分割槽很重要，因為它可以增加吞吐量。透過將工作分散在各個分割槽之間，從而在多個代理之間進行分散，單個主題topic可以處理的比率提高了。但是，如果您有一些不需要很高吞吐量的主題topic該怎麼辦。在這些簡單的情況下，不必擔心分割槽以及隨之而來的API和管理複雜性。
好吧，使用Apache Pulsar可以這麼簡單。如果您只需要一個主題，請使用topic。您不必指定分割槽的數量，也不必考慮該主題可能有多少個使用者。透過Pulsar 訂閱，您可以在一個主題上隨心所欲地新增任意數量的消費者。如果您的消耗性應用程式無法跟上進度，則只需使用共享訂閱即可在多個使用方之間分配負載。
而且，如果您確實需要分割槽主題的效能，也可以這樣做。如果您需要，Pulsar會對主題進行分割槽，但前提是您需要它們。

3.日誌很好，分散式分類帳更好
Kafka團隊因日誌是實時資料交換系統的出色抽象這一見解而值得讚揚。由於日誌僅是追加的，因此可以快速將資料寫入日誌，並且由於日誌中的資料是順序的，因此可以按寫入順序快速提取資料。順序讀寫速度很快，隨機不是。永續性儲存互動是任何提供資料保證的系統中的瓶頸，而日誌抽象使這種方式儘可能高效。
簡單的日誌很好，但是一旦日誌變大，它們就會給您帶來麻煩。在單個伺服器上安裝日誌成為一個挑戰。如果裝滿了您需要橫向擴充套件怎麼辦？如果儲存日誌的伺服器發生故障並且需要從副本中重新建立，會發生什麼？將大型日誌從一臺伺服器複製到另一臺伺服器雖然高效，但仍需要花費很長時間。如果您的系統嘗試在保持實時資料同步的同時執行此操作，那麼這將是一個很大的挑戰。在部落格文章《從前邊的故事：支援Apache Kafka的支援中學到的教訓》中檢視部落格文章“新增新的經紀人可帶來糟糕的業績” 。
Apache Pulsar透過將日誌分成多個段來避免複製大型日誌的問題。當使用Apache BookKeeper作為儲存層寫入資料時，它將這些段分佈在多個伺服器上。這意味著日誌永遠不會儲存在單個伺服器上，因此單個伺服器永遠不會成為瓶頸。失敗場景更易於處理，向外擴充套件很容易。只需新增另一臺伺服器。無需重新平衡。

4.無狀態訊息代理（計算與儲存分離）
無狀態是任何構建雲原生應用程式的人都喜歡的音樂。無狀態元件可以快速啟動，可互換並且可以無縫擴充套件。如果訊息代理是無狀態的，那不是很好嗎？
Kafak訊息代理並非沒有狀態。每個代理均包含其每個分割槽的完整日誌。如果一個代理伺服器失敗了，則不是任何一個其他訊息代理伺服器都可以接管它的。如果負載太高，則不能簡單地新增另一個代理。代理必須同步其他包含其分割槽副本的代理的狀態。
在Apache Pulsar架構中，代理是無狀態的。是的，你聽到的是對的。完全無狀態的系統將無法持久儲存訊息，因此Apache Pulsar確實維護了狀態，只是不在代理中。在Pulsar體系結構中，資料代理與資料儲存是分開的。代理從生產者那裡接收資料並將資料傳送給消費者，但是資料儲存在Apache BookKeeper中。
由於Pulsar代理是無狀態的，因此如果負載很高，則只需新增另一個代理。代理伺服器迅速啟動並立即開始工作。

5.簡單的地理複製
地理複製是Pulsar的一流功能。它不是螺栓連線或專有附件。Pulsar在設計時考慮了地理複製。配置它很容易，並且可以正常工作。因此，無論是全球分散式應用程式還是災難恢復方案，都可以使用Pulsar進行設定。無需博士學位。

6.始終更快

基準測試表明，Pulsar提供了更高的吞吐量以及更低和更一致的延遲。越快越一致越好。還有什麼要說的？

7.都是APACHE開源的
Pulsar具有許多與Kafka相同的功能，例如地理複製，流內訊息處理（Pulsar函式），輸入和輸出聯結器（Pulsar IO），基於SQL的主題查詢（Pulsar SQL），架構登錄檔等作為功​​能，Kafka不具備分層儲存和多租戶的功能。所有這些功能都是Apache開源專案的一部分。

在KAFKA上選擇APACHE PULSAR的5個更多理由：

1.與多租戶相處
即使您不打算構建託管的Pulsar服務（以及既然我們已經為您構建了一個服務，您為什麼還要這麼做？），除非您是一個隱士，否則會有多個團隊使用您的訊息傳遞來從事多個專案基礎設施。必須為每個團隊或專案建立叢集是一件很痛苦的事情。
使用Pulsar，您可以有多個租戶，而這些租戶可以具有多個名稱空間，以保持一切井井有條。再加上每個名稱空間的訪問控制，配額和速率限制，您可以想象一個未來，我們將僅使用一個叢集就能相處融洽。我們不僅可以想象這個未來，而且卡夫卡也可以想象。您可以在“ Kafka改進建議（KIP）KIP-37”中閱讀有關內容。現在已經討論了一段時間。

2.複製有法定人數嗎？
您想確保訊息不會丟失，因此您將訊息傳遞系統配置為為每條訊息製作2或3個副本，以防出現問題。Kafka使用領導者模型來做到這一點。領導者儲存訊息，而跟隨者複製它。一旦有足夠的追隨者承認他們已經掌握了，卡夫卡就會很高興。Pulsar使用法定人數模型。它將訊息傳送到一堆節點，一旦它們中的足夠多的人確認已收到訊息，Pulsar就會感到高興。
沒有這個領導者跟隨者的層次結構，仲裁複製更加民主。多數總是贏，所有選票均等。但這與技術無關。重要的是仲裁複製會隨著時間的流逝而給出更一致的行為。這可能可以解釋為什麼Pulsar可以提供更一致的延遲效能。如果您想了解有關Kafka和Pulsar延遲的詳細資訊，請檢視我撰寫的這篇部落格文章。（很長。不要說我沒有警告過您。）哦，Kafka也一直在考慮使用仲裁複製來提高延遲一致性。檢視KIP-250進行討論。

3.分層儲存，實現事件溯源
像Kafka這樣的流媒體系統的一大優點是它具有重放已消耗的訊息的能力。如果您是第一次喜歡這些訊息，則可以重播它們以更正某些內容或圍繞它們構建新的應用程式。如果您非常喜歡這些訊息，而又想一直保留下去，該怎麼辦？舉例來說，假設您正在進行事件來源。這聽起來像是個好主意，但永遠是一個漫長的時光，永遠儲存訊息會變得昂貴，尤其是如果將訊息儲存在那些使訊息系統嗡嗡作響的高效能固態硬碟上。
如果您可以將這些舊訊息（因為有一天可能會需要保留）而轉移到便宜的儲存解決方案中，這是否有意義？而且，如果您可以使用像Amazon S3儲存桶這樣廉價的雲端儲存，那不是很好嗎？您可能會猜到我要去哪裡。藉助Pulsar 分層儲存，您可以將那些塵土飛揚的舊訊息自動推送到幾乎無限的廉價雲端儲存中，並像處理這些新的，即時的訊息一樣檢索它們。我敢打賭，Kafka希望擁有該功能。你猜對了，他們會的。它在KIP-405中進行了描述。

4.端到端加密和GOBBLEDYGOOK
顯然，安全性很重要，並且您想防止郵件被窺視。當然，您將在客戶端和訊息傳遞系統之間使用TLS（在傳輸過程中加密）。當您這樣做時，訊息傳遞系統必須解密該連線，以便它可以弄清客戶端要說的內容。然後它將把未加密的訊息儲存在磁碟上。當然，您將堅持對磁碟進行加密，這樣，如果有人偷了磁碟，則您的訊息將是安全的（靜態加密）。但是在這兩種情況下，訊息傳遞系統都具有資料的金鑰。如果不是這樣，它將處理令人費解的流語言。
在許多情況下，這種加密級別足夠好，但是如果您要確保絕對沒有人可以窺視您的訊息，則需要進行端到端加密。生產者使用與接收訊息的使用者共享的金鑰在傳送訊息之前對訊息進行加密。當郵件儲存在郵件系統的磁碟上時，將被加密，並且郵件系統沒有金鑰。郵件系統可以完成其工作，但是您的郵件對郵件系統來說是超級安全的。
Pulsar可以在其Java客戶端中進行端到端加密。Kafka一直在談論在KIP-317中執行此操作。

5.訊息代理平衡法
Pulsar會自動為您代理代理負載平衡。它監視CPU，記憶體和網路（不是磁碟，我是否提到代理是無狀態的）代理的使用情況，並將移動負載以保持平衡。這意味著您不必新增新的代理，直到您用完所有代理的容量，這不是因為其中一個正在執行。
您可以使用Kafka進行代理負載平衡。但是，您將必須安裝另一個軟體包，例如LinkedIn的Cruise Control。或者，如果您願意（最終）付款，則可以使用Confluent的再平衡器工具。

社群與生態系統
在社群和生態系統類別中，Kafka擊敗了Pulsar。Kafka作為開放原始碼專案有5年的領先優勢，因此只能說它會有更大的社群，更多相關專案以及更多關於Stack Overflow的答案。
我只能說Pulsar社群正在發展，人們定期地貢獻新的元件和整合，並且社群Slack頻道上的人們都很友好和支援。實際上，我還能說一件事。顯然，許多Pulsar受到Kafka的啟發和啟發，並且Pulsar站在巨人的肩膀上。Kafka專案和社群值得稱讚和尊重。我知道有時候聽起來好像我不尊重卡夫卡，但是我真的對Pulsar感到興奮。

經驗分享：Apache Kafka的缺點與陷阱