Pulsar github 下載地址 https://github.com/apache/pulsar.git
那麼爲什麼我們使用Apache Pulsar構建我們的消息服務呢？
1.流和隊列 一起Apache Pulsar就像兩個產品一樣。它不僅可以處理像Kafka這樣的高速實時用例，而且還支持標準的消息隊列模式，例如競爭消費者，故障轉移訂閱和簡單的消息扇出。 Apache Pulsar會自動跟蹤主題中的客戶端讀取位置，並將該信息存儲在其高性能分佈式賬本Apache BookKeeper中。
與Kafka不同，Apache Pulsar可以處理傳統排隊系統的許多用例，例如RabbitMQ。因此，不是運行兩個系統，一個用於實時流，一個用於排隊，而是使用Pulsar。這是一個兩比一的交易，而且總是好的。
2.分區，但不是必需的分區如果你使用Kafka，你就知道分區。所有主題都在Kafka中分區。分區很重要，因爲它可以提高吞吐量。通過將工作分散到多個分區以及多個代理，可以由單個主題處理的速率上升。但是，如果您有一些不需要高費率的主題，該怎麼辦？在這些簡單的情況下，不必擔心分區以及隨之而來的API和管理複雜性，這不是很好嗎？
好吧，使用Apache Pulsar就可以這麼簡單。如果您只需要一個主題，那麼請使用主題。您不必指定分區數或考慮該主題可能具有的消費者數量。 Pulsar訂閱允許您在Pulsar跟蹤所有主題的主題上添加任意數量的消費者。如果您的消費應用程序無法跟上，您只需使用共享訂閱即可在多個使用者之間分配負載。
如果你確實需要分區主題的性能，你也可以這樣做。如果您需要，Pulsar會對主題進行分區，但前提是您需要它們。
3.日誌是好的，分佈式賬本更好.
Kafka團隊值得稱讚的是日誌是實時數據交換系統的一個很好的抽象。因爲日誌是僅附加的，所以可以快速地將數據寫入它們，並且因爲日誌中的數據是順序的，所以可以按照寫入的順序快速提取日誌。順序讀寫是快速的，隨機的不是。持久存儲交互是任何提供數據保證的系統的瓶頸，而日誌抽象使這一點儘可能高效。
簡單的日誌很棒，但是當它們變大時它們會讓你陷入麻煩。在單個服務器上安裝日誌成爲一項挑戰。如果它變滿並且您需要擴展會發生什麼？如果存儲日誌的服務器出現故障並需要從副本重新創建，會發生什麼？將大型日誌從一臺服務器複製到另一臺服務器雖然有效，但仍然需要很長時間。如果您的系統在保持實時數據的同時嘗試這樣做，那麼這可能是一個非常大的挑戰。
Apache Pulsar通過將日誌分成多個段來避免複製大型日誌的問題。它通過使用Apache BookKeeper作爲其存儲層來編寫數據時，將這些段分佈在多個服務器上。這意味着日誌永遠不會存儲在單個服務器上，因此單個服務器永遠不會成爲瓶頸。失敗場景更容易處理，擴展也很容易。只需添加另一臺服務器不需要重新平衡。
4.broker是無狀態的,數據的代理與數據的存儲是分開
無狀態是構建雲原生應用程序的任何人的耳朵。無狀態組件快速啓動，可互換，無縫擴展。如果消息經紀人無狀態，那不是很好嗎？
kafka不是無狀態的。每個代理包含其每個分區的完整日誌。如果一個經紀人失敗，不只是任何經紀人可以接管它。如果負載過高，則無法簡單地添加其他代理。代理必須與包含其分區副本的其他代理同步狀態。
在Apache Pulsar架構中，broker是無狀態的。是的，你聽到的是對的。一個完全無狀態的系統將無法持久保存消息，因此Apache Pulsar確實維持狀態，而不是在經紀人中。在Pulsar架構中，數據的代理與數據的存儲是分開的。經紀人接受來自生產者的數據並將數據發送給消費者，但數據存儲在Apache BookKeeper中。
因爲Pulsar經紀人是無狀態的，如果負擔變高，你只需要添加另一個Broker。Broker迅速啓動並立即開始工作。
5.對於DUMMIES的地理複製Geo-replication是Pulsar的一流功能。它不是一個插件或專有插件。 Pulsar的設計考慮了地理複製。配置它很容易，它只是工作。因此，無論是全局分佈式應用程序還是災難恢復方案，您都可以使用Pulsar進行設置。
6.一致的基準測試表明Pulsar提供更高的吞吐量以及更低和更一致的延遲。更快，更一致更好。
7.它是所有APACHE開源Pulsar具有許多與Kafka相同的功能，例如地理複製，流內消息處理（Pulsar功能），輸入和輸出連接器（Pulsar IO），基於SQL的主題查詢（Pulsar SQL） ），模式註冊表，以及功能Kafka沒有像分層存儲和多租戶。所有這些功能都是Apache開源項目的一部分。
Pulsar不是由商業實體控制的開源和閉源功能或開源功能的集合。所有許多有用的功能都是Apache下的開源軟件。除非不可想象的事情發生，所有這些善良都會保持開源。
結論正如您所看到的，我們有很多理由選擇Apache Pulsar來構建我們的消息傳遞基礎結構服務。我們甚至沒有考慮到更容易在Pulsar周圍建立服務的原因，例如多租戶，命名空間，身份驗證和授權，文檔，Kubernetes友好性。
對我們來說，使用Apache Pulsar而不是Kafka（或任何其他消息傳遞解決方案）是一個簡單的選擇。