經驗分享：RabbitMQ與Kafka等訊息系統的使用者討論 - ycombinator

banq發表於2020-05-22
MQKafka

vel0city：我已經在相當小的VM上執行RabbitMQ很長時間了。RabbitMQ不需要每條訊息大量的資源，即使使用非常小的VM（512MB RAM，單個CPU），我也看到它每秒處理數千條訊息的峰值而不會出現問題。給它一些強大的硬體，它可能會處理您正在考慮的任何負載，除非您使10gig連結的訊息或其他內容飽和。
考慮擴充套件性和效能時，RabbitMQ和Kafka非常不同。Kafka幾乎是一個透過系統路由的訊息資料庫。在許多配置中，客戶端可能會回來並要求從幾乎任何時間點重播訊息流。這意味著您需要處理大量的磁碟和記憶體訪問。傳統上，使用RabbitMQ，訊息是短暫的。確認訊息後，訊息就消失了。不存在記憶體中，也不在磁碟上。沒有人會再來詢問該訊息。這樣可以提高處理每條訊息的效率，但是代價是無法記住幾毫秒前透過系統的訊息。

addisonj：作為已經在生產環境中執行許多訊息傳遞系統的人，這是我目前的大致看法：
如果您要轉向“事件溯源”架構，通常要考慮的兩個主要問題（除了正常執行時間，規模等基本操作之外）是路由和長期儲存。
RabbitMQ有路由，但沒有儲存。Kafka 可以儲存和路由，但是可能很複雜/昂貴。Apache Pulsar確實在此閃耀，因為該API是pub / sub，但是它的日誌結構為您提供了長期保留（無需手動重新平衡），但是靈活性確實伴隨著某些操作的複雜性與RabbitMQ相比。
如果您的需求只是移動大量資料，那麼Kafka無疑是最成熟的並且擁有龐大的生態系統，但是長期保留很困難，並且在消費者群體中也有一些利器。
如果您確實真的不需要長期保留並且需要複雜的拓撲，RabbitMQ是您的最佳選擇，並且即使在相當高的訊息速率下執行也相當合理（〜10k msgs/sec應該不太難實現）
但是，如今有更多的選擇，更老的Java解決方案（例如activeMQ和rocketMQ）或更多的“最小”實現（例如NAT），更不用說雲提供商上的託管服務了。
就個人而言，我是Apache Pulsar的忠實擁護者，因為它具有靈活性和一些不錯的設計選擇，但我認為在這個領域沒有任何靈丹妙藥。

atombender：請謹慎購買RabbitMQ的叢集。執行了多年之後，我發現它非常脆弱。我們經常丟失整個佇列，因為一個小的網路故障使RabbitMQ認為存在網路分割槽，並且當其他節點變為可見時，RabbitMQ沒有可靠的方式將其狀態恢復為原來的狀態。它有很多技巧可以緩解這種情況，但是它們並不能解決核心問題。可靠執行映象佇列（未稱為“經典映象佇列”）的唯一方法是禁用自動恢復，然後每次發生這種情況時都必須手動修復RabbitMQ。如果您關心完整性，則可以使用新的仲裁佇列，該佇列使用基於Raft的共識系統，但是它們缺少“經典”佇列的許多功能。例如，沒有訊息優先順序。
如果您願意在極高的負載下丟失偶爾出現的訊息，則NATS 絕對是奇妙的，而且非常快速且易於叢集。另外，NATS Streaming 和Liftbridge是建立在NATS之上的兩個訊息代理，它們實現了可靠的傳遞。我沒有用過，但聽到了好訊息。

[1] https://www.rabbitmq.com/partitions.html

[2] https://www.rabbitmq.com/quorum-queues.html

[3] https://nats.io/

[4] https://docs.nats.io/nats-streaming-concepts/intro

[5] https://github.com/liftbridge-io/liftbridge

snapetom：由於三個原因，我最終嚮往了Rabbit。

  1. 對於中小型體系結構，更容易實現和維護。但是，我聽到的故事表明，它開始成為大型叢集體系結構的麻煩。
  2. 因為它是傳統的訊息代理，所以我負責的輸入和輸出端的編寫要簡單得多，因為我不必擔心重新聯機時的重放。Rabbit知道它已經路由到了哪個客戶端以及訊息的去向。kafka在這方面並不那麼複雜。kafka被描述為“愚蠢經紀人/智慧客戶”，而Rabbit則被描述為“智慧經紀人/愚蠢的客戶”。
  3. 縮放。Rabbit是非常可擴充套件的。一旦達到Uber/Paypal級別（例如每秒幾百萬次寫入），那麼Kafka便成為顯而易見的選擇。Rabbit每秒可以處理數千次寫入。但是，在第二家公司以及其他許多公司中，他們認為必須吸收所有資料，因此，從長遠來看，Kafka當然是更具擴充套件性的工具。劇透：我們從來沒有接近PayPal級交易。

更多資訊點選標題。


 

相關文章