【轉載】Understanding When to use RabbitMQ or Apache Kafka

https://content.pivotal.io/rabbitmq/understanding-when-to-use-rabbitmq-or-apache-kafka

RabbitMQ： Erlang

Apache Kafka：Scala

 

https://content.pivotal.io/rabbitmq/understanding-when-to-use-rabbitmq-or-apache-kafka

來自谷歌翻譯

瞭解什麼時候使用RabbitMQ或Apache Kafka

2017年4月26日 彼得·漢弗萊

人類如何作出決定？在平常生活中，情緒每每是拉動觸發複雜或壓倒性決定的開路因素。可是對於作出長期後果的複雜決策的專家來講，這並非純粹的衝動。高績效者一般只有在專家，潛意識的頭腦吸取了做出決定所需的全部事實以後，才使用「本能」，「直覺」或其餘情緒的斷路器。

今天，有數十種消息技術，無數的ESB，以及將近100個iPaaS供應商。固然，這致使瞭如何根據您的需求選擇正確的消息傳遞技術的問題 - 特別是對於那些已經投入了特定選擇的消息。咱們切換批發？只需使用正確的工具來完成正確的工做？咱們是否正確地將業務須要框架在手邊？鑑於此，對我來講什麼是正確的工具？更糟的是，詳盡的市場分析可能永遠不會結束，但鑑於整合代碼的平均壽命，盡職調查是相當重要的。

這篇文章努力給潛意識，專家的頭腦甚至交給治療考慮，從今天最現代，最受歡迎的選擇開始：RabbitMQ和Apache Kafka。每一個都有它本身的原創故事，設計意圖，使用案例，照亮，集成能力和開發人員的經驗。起源揭示了任何一款軟件的整體設計意圖，而且是一個很好的起點。

起源
RabbitMQ是一個「傳統的」消息代理，它實現了各類消息傳遞協議。它是第一個得到合理級別的功能，客戶端庫，開發工具和質量文檔的開源消息代理商之一。RabbitMQ最初是爲了實現AMQP而開發的，AMQP是一種開放的，具備強大路由功能的消息傳遞協議。雖然Java具備像JMS這樣的消息傳遞標準，可是對於須要分佈式消息傳遞的非Java應用程序來講是沒有幫助的，這些應用程序嚴重限制了任何集成場景，微服務或單塊。隨着AMQP的出現，跨語言的靈活性對於開源消息代理來講變得真實。

Apache Kafka是在Scala開發的，最初是在LinkedIn上鍊接不一樣的內部系統。當時，LinkedIn正在轉向更分散的體系結構，須要從新構想像數據集成和實時流處理這樣的功能，擺脫之前針對這些問題的單一方法。Kafka今天在Apache軟件基金會的產品生態系統中獲得了很好的應用，在事件驅動架構中尤爲有用。

建築和設計

RabbitMQ被設計爲一個通用的消息代理，採用點到點，請求/回覆和pub-sub通訊風格模式的幾種變化。它使用一個聰明的經紀人/愚蠢的消費者模式，專一於向消費者提供一致的消息傳遞，消費者的消費速度與經紀人跟蹤消費者狀態的速度大體相同。它是成熟的，配置正確，性能良好，獲得很好的支持（客戶端庫Java，.NET，node.js，Ruby，PHP和更多的語言），而且有幾十個插件能夠擴展到更多的用例和集成場景。

 

圖15 - 簡化的總體RabbitMQ架構。資料來源：http：//kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

RabbitMQ中的通訊能夠根據須要同步或異步。發佈者將消息發送給交換機，消費者從隊列中檢索消息。經過交換將生產者從隊列中解耦出來，能夠保證生產者不須要硬編碼路由決策。RabbitMQ還提供了許多分佈式部署方案（並要求全部節點可以解析主機名）。它能夠設置爲多節點集羣來聯合集羣，而且不依賴於外部服務（但某些集羣插件可使用AWS API，DNS，Consul等）。

Apache Kafka設計用於高容量的發佈 - 訂閱消息和流，意味着持久，快速和可擴展。就其本質而言，Kafka提供了一個持久的消息存儲庫，相似於在服務器羣集中運行的日誌，它將記錄流存儲在稱爲主題的類別中。

 

圖11 - 全球Apache Kafka架構（1個主題，1個分區，複製因子4）。資料來源：http：//kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

每條消息由一個鍵，一個值和一個時間戳組成。與RabbitMQ幾乎相反，Kafka僱用了一個愚蠢的經紀人，並使用聰明的消費者來閱讀它的緩衝區。卡夫卡並不試圖追蹤每一個消費者閱讀哪些消息，只保留未讀消息; 相反，Kafka將全部消息保留必定的時間，消費者負責跟蹤他們在每一個日誌（消費者狀態）中的位置。所以，經過合適的開發人員建立消費者代碼，Kafka能夠支持大量的消費者，並以不多的開銷保留大量的數據。如上圖所示，Kafka確實須要運行外部服務 - 在這種狀況下，Apache Zookeeper一般被認爲是不可理解的，安裝和運行的。

需求和用例
許多開發人員在乎識到必須將許多東西鏈接在一塊兒時纔會開始探索消息，而其餘集成模式（如共享數據庫）則不可行或太危險。

Apache Kafka包括經紀人自己，這其實是最知名的和最受歡迎的部分，並已經設計和突出地銷售到流處理場景。除此以外，Apache Kafka最近還添加了Kafka Streams，它能夠替代Apache Spark，Apache Flink，Apache Beam / Google Cloud Data Flow等流媒體平臺。該文檔在討論網站活動跟蹤，指標，日誌聚合，流處理，事件採購和提交日誌等經常使用用例方面作得很好。其中描述的用例之一是消息傳遞，這可能會產生一些混淆。所以，讓咱們解開這一點，並清楚地說明哪些消息傳遞場景最適合於Kafka，例如：

從A流到B，沒有複雜的路由，最大吞吐量（100k / sec +），按分區順序傳遞至少一次。
當您的應用程序須要訪問流歷史記錄時，按分區順序傳遞至少一次。Kafka是一個持久的消息存儲庫，客戶端能夠根據須要「重放」事件流，而不是傳統的消息代理，一旦消息被傳遞，它就會從隊列中移除。
卡夫卡的持久存儲，一個是流處理
事件採購
RabbitMQ是一個通用的消息傳遞解決方案，一般用於容許Web服務器快速響應請求，而不是在用戶等待結果時被迫執行資源繁重的過程。將消息分發給多個收件人進行消費或在高負載（20k + /秒）之間平衡工做人員之間的負載也是很好的。當您的需求超出吞吐量時，RabbitMQ提供了不少功能：可靠的交付，路由，聯合，HA，安全，管理工具和其餘功能。讓咱們來看看最適合RabbitMQ的一些場景，好比：

您的應用程序須要使用現有協議的任何組合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
您須要在每條消息的基礎上進行更細粒度的一致性控制/保證（死信隊列等）。可是，Kafka最近爲事務添加了更好的支持。
您的應用程序須要點對點，請求/回覆以及發佈/訂閱消息
複雜的路由到消費者，整合多個服務/應用與非平凡的路由邏輯
RabbitMQ還能夠有效地解決上面幾個Kafka強大的使用案例，可是在附加軟件的幫助下。當應用程序須要訪問流歷史記錄時，RabbitMQ常常與Apache Cassandra一塊兒使用，或者與須要「無限」隊列的應用程序的LevelDB插件一塊兒使用，但RabbitMQ自己並不具有這些功能。

要深刻了解Kafka和RabbitMQ的微服務特定用例，請轉到Pivotal博客，閱讀Fred Melo的這篇短文。

開發者體驗
RabbitMQ 經過社區插件正式支持Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift等許多其餘客戶端和開發工具。RabbitMQ客戶端庫已經成熟而且有據可查。

Apache Kafka已經在這個領域取得了長足的進步，雖然它只是一個Java客戶端，可是還有一個社區開源客戶端，生態系統項目和一個適配器SDK 的增加目錄，容許你創建你本身的系統集成。許多配置是經過.properties文件或編程方式完成的。

這兩個選項的受歡迎程度對許多其餘確保RabbitMQ和Kafka在他們的技術上運行良好的軟件提供商有很大的影響。

開發人員的經驗...刷新咱們在Spring Kafka，Spring Cloud Stream等中提供的支持是不對的。

安全和操做
二者都是RabbitMQ的優點。RabbitMQ管理插件提供了一個HTTP API，一個基於瀏覽器的用於管理和監控的UI，以及面向運營商的CLI工具。像CollectD，Datadog或New Relic等外部工具是長期監測數據存儲所必需的。RabbitMQ還提供用於監視，審計和應用程序故障排除的API和工具。除了支持TLS以外，RabbitMQ還提供由內置數據存儲，LDAP或基於HTTPS外部提供程序支持的RBAC，並支持使用x509證書而不是用戶名/密碼對進行身份驗證。額外的認證方法能夠至關簡單地用插件開發。

這些領域對Apache Kafka構成挑戰。在安全性方面，最近的Kafka 0.9版本增長了TLS，JAAS基於角色的訪問控制和kerberos / plain / scram auth，使用CLI管理安全策略。這對早期版本進行了重大改進，您只能鎖定網絡級別的訪問權限，這對於共享或多租戶不起做用。

Kafka使用由shell腳本，屬性文件和專門格式化的JSON文件組成的管理CLI。Kafka經紀商，生產商和消費者經過Yammer / JMX發佈指標，但不保留任何歷史記錄，這實際上意味着使用第三方監控系統。使用這些工具，操做能夠管理分區和主題，檢查消費者偏移位置，並使用Apache Zookeeper爲Kafka提供的HA和FT功能。雖然不少人對Zookeeper的要求持懷疑態度，但卻爲Kafka用戶提供了集羣優點。

例如，一個3節點Kafka集羣系統即便在2次故障後也能正常工做。可是，若是你想在Zookeeper中支持儘量多的故障，你須要額外的5個Zookeeper節點，由於Zookeeper是一個基於法定人數的系統，只能容忍N / 2 + 1故障。這顯然不該該與Kafka節點共處 - 因此爲了站起來一個3節點的Kafka系統，你須要8臺服務器。在推導任何Kafka系統的可用性時，運營商必須考慮到ZK集羣的屬性，不管是在資源消耗和設計方面。

性能
卡夫卡的設計在這裏閃耀：100k /秒的表現每每是人們選擇阿帕奇卡夫卡的關鍵驅動力。

固然，每秒鐘消息的速率很難說明和量化，由於它們依賴於包括你的環境和硬件在內的不少東西，工做負載的性質，使用哪一種傳輸保證（例如，持久代價高昂，鏡像更是如此）等等。

每秒20K條消息很容易經過一個單一的兔子隊列來推進，確實比這更難，並不須要太多的保證。隊列由一個簡單的Erlang輕量級線程支持，該線程在本地操做系統線程池中進行協做調度 - 所以，單個隊列永遠不會作比CPU週期可以工做更多的工做，這成爲天然的瓶頸或瓶頸在。

每秒增長消息一般是經過巧妙的路由（例如，能夠同時運行不一樣的隊列）來打破多個隊列中的流量這樣的事情來正確地利用在一個環境中可用的並行性。當RabbitMQ 每秒鐘達到100萬條消息時，基本上徹底是爲了作到這一點 - 可是使用了大量的資源，大約有30個RabbitMQ節點。大多數RabbitMQ用戶均可以享受到由三到七個RabbitMQ節點組成的集羣的卓越性能。

打電話
吸取一些在市場上其餘一些頂級選項的研究。若是你想更深刻的選擇最受歡迎的選擇，那麼Nicolas Nannoni的碩士論文啓發了這篇文章，它在4.4節（第39頁）中提供了一個並排比較表，這個表在兩年後還算合理 - 值得閱讀。

在研究的同時，儘量頻繁地與利益相關方和企業進行交流。瞭解業務用例是爲您的狀況作出正確選擇的惟一最重要的因素。那麼，若是你是流行的心理學迷，你最好的選擇就是睡上一覺，讓它滲透，讓你的本能接管。你有這個

關於做者
彼得·漢弗萊
Pieter Humphrey是負責Pivotal Software，Inc. Java開發人員營銷的產品營銷經理。Pieter來自BEA / Oracle，長期以來一直是開發人員工具，Java EE，SOA，EAI，應用程序服務器和其餘Java中間件的發展者，銷售工程師自1998年以來。在Twitter上找到我在https://www.twitter.com/pieterhumphrey。

更多內容經過Pieter Humphrey