消息中間件Kafka與RabbitMQ誰更勝一籌？-創(chuàng)新互聯(lián)

在 IM 這種講究高并發(fā)、高消息吞吐的互聯(lián)網(wǎng)場景下，MQ 消息中間件是個很重要的基礎(chǔ)設(shè)施，它在 IM 系統(tǒng)的服務(wù)端架構(gòu)中擔(dān)當(dāng)消息中轉(zhuǎn)、消息削峰、消息交換異步化等角色。
當(dāng)然，MQ 消息中間件的作用遠不止于此，它的價值不僅僅存在于技術(shù)上，更重要的是改變了以往同步處理消息的思路。
比如進行 IM 消息歷史存儲時，傳統(tǒng)的信息系統(tǒng)作法可能是收到一條消息就馬上同步存入數(shù)據(jù)庫，這種作法在小并發(fā)量的情況下可以很好的工作，但互聯(lián)網(wǎng)大并發(fā)環(huán)境下就是災(zāi)難。

MQ 消息中間件可以理解為一個水池，水池的這頭是消息生產(chǎn)者，水池的那頭是消息消費者，生產(chǎn)者和消息者無需直接對接，這將帶來很多好處：業(yè)務(wù)解耦、架構(gòu)分布式化等，生產(chǎn)者和消費者互相完全透明。
但市面上的 MQ 消息中間件產(chǎn)品很多，作為 IM 系統(tǒng)中必不可少的一環(huán)，我們該如何選型？
什么是消息隊列中間件
消息隊列中間件（簡稱消息中間件）是指利用高效可靠的消息傳遞機制進行與平臺無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。
通過提供消息傳遞和消息排隊模型，它可以在分布式環(huán)境下提供應(yīng)用解耦、彈性伸縮、冗余存儲、流量削峰、異步通信、數(shù)據(jù)同步等等功能，其作為分布式系統(tǒng)架構(gòu)中的一個重要組件，有著舉足輕重的地位。

目前開源的消息中間件可謂是琳瑯滿目，能讓大家耳熟能詳?shù)木陀泻芏?，比?ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ 等，不管選擇其中的哪一款，都會有用的不趁手的地方，畢竟不是為你量身定制的。
可能有些大廠在長期的使用過程中積累了一定的經(jīng)驗，加上其消息隊列的使用場景也相對穩(wěn)定固化，或者目前市面上的消息中間件無法滿足自身需求，同時它也具備足夠的精力和人力而選擇自研來為自己量身打造一款消息中間件。
但是絕大多數(shù)公司還是不會選擇重復(fù)造輪子，那么選擇一款適合自己的消息中間件顯得尤為重要。
就算是前者，那么在自研出穩(wěn)定且可靠的相關(guān)產(chǎn)品之前也會經(jīng)歷這樣一個選型過程。
在整體架構(gòu)中引入消息中間件，勢必要考慮很多因素，比如成本及收益問題，怎么樣才能達到最優(yōu)的性價比？
雖然消息中間件種類繁多，但是各自都有各自的側(cè)重點，選擇合適自己、揚長避短無疑是最好的方式。如果你對此感到無所適從，本文或許可以參考一二。
各類消息隊列簡述
ActiveMQ
Apache 出品的、采用 Java 語言編寫的完全基于 JMS1.1 規(guī)范的面向消息的中間件，為應(yīng)用程序提供高效的、可擴展的、穩(wěn)定的和安全的企業(yè)級消息通信。
不過由于歷史原因包袱太重，目前市場份額沒有后面三種消息中間件多，其最新架構(gòu)被命名為 Apollo，號稱下一代 ActiveMQ，有興趣的同學(xué)可自行了解。
RabbitMQ
采用 Erlang 語言實現(xiàn)的 AMQP 協(xié)議的消息中間件，最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息。
RabbitMQ 發(fā)展到今天，被越來越多的人認(rèn)可，這和它在可靠性、可用性、擴展性、功能豐富等方面的卓越表現(xiàn)是分不開的。
Kafka
起初是由 LinkedIn 公司采用 Scala 語言開發(fā)的一個分布式、多分區(qū)、多副本且基于 ZooKeeper 協(xié)調(diào)的分布式消息系統(tǒng)，現(xiàn)已捐獻給 Apache 基金會。
它是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，以可水平擴展和高吞吐率而被廣泛使用。目前越來越多的開源分布式處理系統(tǒng)如 Cloudera、Apache Storm、Spark、Flink 等都支持與 Kafka 集成。
RocketMQ
是阿里開源的消息中間件，目前已經(jīng)捐獻給 Apache 基金會，它是由 Java 語言開發(fā)的，具備高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用等特點，經(jīng)歷過雙 11 的洗禮，實力不容小覷。
ZeroMQ
號稱史上最快的消息隊列，基于 C 語言開發(fā)。ZeroMQ 是一個消息處理隊列庫，可在多線程、多內(nèi)核和主機之間彈性伸縮。
雖然大多數(shù)時候我們習(xí)慣將其歸入消息隊列家族之中，但是其和前面的幾款有著本質(zhì)的區(qū)別，ZeroMQ 本身就不是一個消息隊列服務(wù)器，更像是一組底層網(wǎng)絡(luò)通訊庫，對原有的 Socket API 上加上一層封裝而已。
目前市面上的消息中間件還有很多，比如騰訊系的 PhxQueue、CMQ、CKafka，又比如基于 Go 語言的 NSQ，有時人們也把類似 Redis 的產(chǎn)品也看做消息中間件的一種。
當(dāng)然，它們都很優(yōu)秀，但是本文篇幅限制無法窮其所有，下面會針對性地挑選 RabbitMQ 和 Kafka 兩款典型的消息中間件來做分析，力求站在一個公平公正的立場來闡述消息中間件選型中的各個要點。
消息中間件選型要點
衡量一款消息中間件是否符合需求，需要從多個維度進行考察。
首要的就是功能維度，這個直接決定了你能否大程度上地實現(xiàn)開箱即用，進而縮短項目周期、降低成本等。
如果一款消息中間件的功能達不到想要的功能，那么就需要進行二次開發(fā)，這樣會增加項目的技術(shù)難度、復(fù)雜度以及增大項目周期等。
消息中間件具體選型指標(biāo)
功能維度
功能維度又可以劃分成多個子維度，大致可以分為以下這些。
優(yōu)先級隊列
優(yōu)先級隊列不同于先進先出隊列，優(yōu)先級高的消息具備優(yōu)先被消費的特權(quán)，這樣可以為下游提供不同消息級別的保證。
不過這個優(yōu)先級也是需要有一個前提的：如果消費者的消費速度大于生產(chǎn)者的速度，并且消息中間件服務(wù)器（一般簡單的稱之為 Broker）中沒有消息堆積。
那么對于發(fā)送的消息設(shè)置優(yōu)先級也就沒有什么實質(zhì)性的意義了，因為生產(chǎn)者剛發(fā)送完一條消息就被消費者消費了，那么就相當(dāng)于 Broker 中至多只有一條消息，對于單條消息來說優(yōu)先級是沒有什么意義的。
延遲隊列
當(dāng)你在網(wǎng)上購物的時候是否會遇到這樣的提示：“三十分鐘之內(nèi)未付款，訂單自動取消”，這個是延遲隊列的一種典型應(yīng)用場景。
延遲隊列存儲的是對應(yīng)的延遲消息，所謂“延遲消息”是指當(dāng)消息被發(fā)送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。
延遲隊列一般分為兩種：
基于消息的延遲，是指為每條消息設(shè)置不同的延遲時間，那么每當(dāng)隊列中有新消息進入的時候就會重新根據(jù)延遲時間排序，當(dāng)然這也會對性能造成極大的影響。
基于隊列的延遲，實際應(yīng)用中大多采用這種，設(shè)置不同延遲級別的隊列，比如5s、10s、30s、1min、5mins、10mins等，每個隊列中消息的延遲時間都是相同的，這樣免去了延遲排序所要承受的性能之苦，通過一定的掃描策略（比如定時）即可投遞超時的消息。
死信隊列
由于某些原因消息無法被正確投遞，為了確保消息不會被無故丟棄，一般將其置于一個特殊角色的隊列，這個隊列稱為死信隊列。
與此對應(yīng)的還有一個“回退隊列”的概念，試想如果消費者在消費時發(fā)生了異常，那么就不會對這一次消費進行確認(rèn)（Ack）, 進而發(fā)生回滾消息的操作之后消息始終會放在隊列的頂部，然后不斷被處理和回滾，導(dǎo)致隊列陷入死循環(huán)。
為了解決這個問題，可以為每個隊列設(shè)置一個回退隊列，它和死信隊列都是為異常的處理提供的一種機制保障。實際情況下，回退隊列的角色可以由死信隊列和重試隊列來扮演。
重試隊列
其實可以看成是一種回退隊列，具體指消費端消費消息失敗時，為防止消息無故丟失而重新將消息回滾到 Broker 中。
與回退隊列不同的是重試隊列一般分成多個重試等級，每個重試等級一般也會設(shè)置重新投遞延時，重試次數(shù)越多投遞延時就越大。
舉個例子：消息第一次消費失敗入重試隊列 Q1，Q1 的重新投遞延遲為 5s，在 5s 過后重新投遞該消息。
如果消息再次消費失敗則入重試隊列 Q2，Q2 的重新投遞延遲為 10s，在 10s 過后再次投遞該消息。
以此類推，重試越多次重新投遞的時間就越久，為此需要設(shè)置一個上限，超過投遞次數(shù)就入死信隊列。
重試隊列與延遲隊列有相同的地方，都是需要設(shè)置延遲級別，它們彼此的區(qū)別是：延遲隊列動作由內(nèi)部觸發(fā)，重試隊列動作由外部消費端觸發(fā)；延遲隊列作用一次，而重試隊列的作用范圍會向后傳遞。
消費模式
消費模式分為推（push）模式和拉（pull）模式：
推模式，是指由 Broker 主動推送消息至消費端，實時性較好，不過需要一定的流制機制來確保服務(wù)端推送過來的消息不會壓垮消費端。
拉模式，是指消費端主動向 Broker 端請求拉取（一般是定時或者定量）消息，實時性較推模式差，但是可以根據(jù)自身的處理能力而控制拉取的消息量。
廣播消費
消息一般有兩種傳遞模式——點對點（P2P，Point-to-Point）模式和發(fā)布/訂閱（Pub/Sub）模式：
對于點對點的模式而言，消息被消費以后，隊列中不會再存儲，所以消息消費者不可能消費到已經(jīng)被消費的消息。雖然隊列可以支持多個消費者，但是一條消息只會被一個消費者消費。
發(fā)布訂閱模式定義了如何向一個內(nèi)容節(jié)點發(fā)布和訂閱消息，這個內(nèi)容節(jié)點稱為主題（Topic），主題可以認(rèn)為是消息傳遞的中介，消息發(fā)布者將消息發(fā)布到某個主題，而消息訂閱者則從主題中訂閱消息。
主題使得消息的訂閱者與消息的發(fā)布者互相保持獨立，不需要進行接觸即可保證消息的傳遞，發(fā)布/訂閱模式在消息的一對多廣播時采用。
RabbitMQ 是一種典型的點對點模式，而 Kafka 是一種典型的發(fā)布訂閱模式。
但是 RabbitMQ 中可以通過設(shè)置交換器類型來實現(xiàn)發(fā)布訂閱模式而達到廣播消費的效果，Kafka 中也能以點對點的形式消費，你完全可以把其消費組（Consumer Group）的概念看成是隊列的概念。
不過對比來說，Kafka 中因為有了消息回溯功能的存在，對于廣播消費的力度支持比 RabbitMQ 的要強。
消息回溯
一般消息在消費完成之后就被處理了，之后再也不能消費到該條消息。消息回溯正好相反，是指消息在消費完成之后，還能消費到之前被消費掉的消息。
對于消息而言，經(jīng)常面臨的問題是“消息丟失”，至于是真正由于消息中間件的缺陷丟失還是由于使用方的誤用而丟失，一般很難追查。
如果消息中間件本身具備消息回溯功能的話，可以通過回溯消費復(fù)現(xiàn)“丟失的”消息進而查出問題的源頭所在。
消息回溯的作用遠不止于此，比如還有索引恢復(fù)、本地緩存重建，有些業(yè)務(wù)補償方案也可以采用回溯的方式來實現(xiàn)。
消息堆積+持久化
流量削峰是消息中間件的一個非常重要的功能，而這個功能其實得益于其消息堆積能力。
從某種意義上來講，如果一個消息中間件不具備消息堆積的能力，那么就不能把它看做是一個合格的消息中間件。
消息堆積分內(nèi)存式堆積和磁盤式堆積：
RabbitMQ 是典型的內(nèi)存式堆積，但這并非絕對，在某些條件觸發(fā)后會有換頁動作來將內(nèi)存中的消息換頁到磁盤（換頁動作會影響吞吐），或者直接使用惰性隊列來將消息直接持久化至磁盤中。
Kafka 是一種典型的磁盤式堆積，所有的消息都存儲在磁盤中。
一般來說，磁盤的容量會比內(nèi)存的容量要大得多，對于磁盤式的堆積其堆積能力就是整個磁盤的大小。
從另外一個角度講，消息堆積也為消息中間件提供了冗余存儲的功能。援引《紐約時報》的案例，其直接將 Kafka 用作存儲系統(tǒng)。
消息追蹤
對于分布式架構(gòu)系統(tǒng)中的鏈路追蹤（Trace），大家一定不陌生。對于消息中間件，消息的鏈路追蹤（以下簡稱消息追蹤）同樣重要，最通俗來理解，就是要知道消息從哪來，存在哪里以及發(fā)往哪里去。
基于此功能，我們可以對發(fā)送或者消費完的消息進行鏈路追蹤服務(wù)，進而可以進行問題的快速定位與排查。
消息過濾
消息過濾是指按照既定的過濾規(guī)則為下游用戶提供指定類別的消息。
就以 Kafka 而言，完全可以將不同類別的消息發(fā)送至不同的 Topic 中，由此可以實現(xiàn)某種意義的消息過濾，或者 Kafka 還可以根據(jù)分區(qū)對同一個 Topic 中的消息進行分類。
不過，更加嚴(yán)格意義上的消息過濾，應(yīng)該是對既定的消息采取一定的方式按照一定的過濾規(guī)則進行過濾。
同樣以 Kafka 為例，可以通過客戶端提供的 Consumer Interceptor 接口或者 Kafka Stream 的 Filter 功能進行消息過濾。
多租戶
也可以稱為多重租賃技術(shù)，是一種軟件架構(gòu)技術(shù)，主要用來實現(xiàn)多用戶的環(huán)境下公用相同的系統(tǒng)或程序組件，并且仍可以確保各用戶間數(shù)據(jù)的隔離性。
RabbitMQ 就能夠支持多租戶技術(shù)，每一個租戶表示為一個 VHost，其本質(zhì)上是一個獨立的小型 RabbitMQ 服務(wù)器，又有自己獨立的隊列、交換器及綁定關(guān)系等，并且它擁有自己獨立的權(quán)限。
VHost 就像是物理機中的虛擬機一樣，它們在各個實例間提供邏輯上的分離，為不同程序安全保密地允許數(shù)據(jù)，它既能將同一個 RabbitMQ 中的眾多客戶區(qū)分開，又可以避免隊列和交換器等命名沖突。
多協(xié)議支持
消息是信息的載體，為了讓生產(chǎn)者和消費者都能理解所承載的信息（生產(chǎn)者需要知道如何構(gòu)造消息，消費者需要知道如何解析消息），它們就需要按照一種統(tǒng)一的格式描述消息，這種統(tǒng)一的格式稱之為消息協(xié)議。
有效的消息一定具有某種格式，而沒有格式的消息是沒有意義的。
一般消息層面的協(xié)議有 AMQP、MQTT、STOMP、XMPP 等（消息領(lǐng)域中的 JMS 更多的是一個規(guī)范而不是一個協(xié)議），支持的協(xié)議越多其應(yīng)用范圍就會越廣，通用性越強。
比如 RabbitMQ 能夠支持 MQTT 協(xié)議就讓其在物聯(lián)網(wǎng)應(yīng)用中獲得一席之地。還有的消息中間件是基于其本身的私有協(xié)議運轉(zhuǎn)的，典型的如 Kafka。
跨語言支持
對很多公司而言，其技術(shù)棧體系中會有多種編程語言，如 C/C++、Java、Go、PHP 等，消息中間件本身具備應(yīng)用解耦的特性，如果能夠進一步的支持多客戶端語言，那么就可以將此特性的效能擴大。
跨語言的支持力度也從側(cè)面反映出一個消息中間件的流行程度。
流量控制
針對的是發(fā)送方和接收方速度不匹配的問題，提供一種速度匹配服務(wù)抑制發(fā)送速率使接收方應(yīng)用程序的讀取速率與之相適應(yīng)。通常的流控方法有 Stop-and-Wait、滑動窗口以及令牌桶等。
消息順序性
顧名思義，是指保證消息有序。這個功能有個很常見的應(yīng)用場景就是 CDC（Change Data Chapture）。
以 MySQL 為例，如果其傳輸?shù)?Binlog 的順序出錯，比如原本是先對一條數(shù)據(jù)加 1，然后再乘以 2，發(fā)送錯序之后就變成了先乘以 2 后加 1，造成數(shù)據(jù)不一致。
安全機制
在 Kafka 0.9 版本之后就開始增加了身份認(rèn)證和權(quán)限控制兩種安全機制：
身份認(rèn)證，是指客戶端與服務(wù)端連接進行身份認(rèn)證，包括客戶端與 Broker 之間、Broker 與 Broker 之間、Broker 與 ZooKeeper 之間的連接認(rèn)證，目前支持 SSL、SASL 等認(rèn)證機制。
權(quán)限控制，是指對客戶端的讀寫操作進行權(quán)限控制，包括對消息或 Kafka 集群操作權(quán)限控制。權(quán)限控制是可插拔的，并支持與外部的授權(quán)服務(wù)進行集成。
對于 RabbitMQ 而言，其同樣提供身份認(rèn)證（TLS/SSL、SASL）和權(quán)限控制（讀寫操作）的安全機制。
消息冪等性
確保消息在生產(chǎn)者和消費者之間進行傳輸，一般有三種傳輸保障（Delivery Guarantee）：
At most once，至多一次，消息可能丟失，但絕不會重復(fù)傳輸。
At least once，至少一次，消息絕不會丟，但是可能會重復(fù)。
Exactly once，精確一次，每條消息肯定會被傳輸一次且僅一次。
對于大多數(shù)消息中間件而言，一般只提供 At most once 和 At least once 兩種傳輸保障，對于第三種一般很難做到，由此消息冪等性也很難保證。
Kafka 自 0.11 版本開始引入了冪等性和事務(wù)，Kafka 的冪等性是指單個生產(chǎn)者對于單分區(qū)單會話的冪等。
而事務(wù)可以保證原子性地寫入到多個分區(qū)，即寫入到多個分區(qū)的消息要么全部成功，要么全部回滾，這兩個功能加起來可以讓 Kafka 具備 EOS（Exactly Once Semantic）的能力。
不過如果要考慮全局的冪等，還需要從上下游方面綜合考慮，即關(guān)聯(lián)業(yè)務(wù)層面，冪等處理本身也是業(yè)務(wù)層面所需要考慮的重要議題。
以下游消費者層面為例，有可能消費者消費完一條消息之后沒有來得及確認(rèn)消息就發(fā)生異常，等到恢復(fù)之后又得重新消費原來消費過的那條消息，那么這種類型的消息冪等是無法由消息中間件層面來保證的。
如果要保證全局的冪等，需要引入更多的外部資源來保證，比如以訂單號作為唯一性標(biāo)識，并且在下游設(shè)置一個去重表。
事務(wù)性消息
事務(wù)本身是一個并不陌生的詞匯，事務(wù)是由事務(wù)開始（Begin Transaction）和事務(wù)結(jié)束（End Transaction）之間執(zhí)行的全體操作組成。
支持事務(wù)的消息中間件并不在少數(shù)，Kafka 和 RabbitMQ 都支持，不過此兩者的事務(wù)是指生產(chǎn)者發(fā)生消息的事務(wù)，要么發(fā)送成功，要么發(fā)送失敗。
消息中間件可以作為用來實現(xiàn)分布式事務(wù)的一種手段，但其本身并不提供全局分布式事務(wù)的功能。
下表是對 Kafka 與 RabbitMQ 功能的總結(jié)性對比及補充說明：

性能
功能維度是消息中間件選型中的一個重要的參考維度，但這并不是唯一的維度，有時候性能比功能還要重要，況且性能和功能很多時候是相悖的，魚和熊掌不可兼得。
Kafka 在開啟冪等、事務(wù)功能的時候會使其性能降低；RabbitMQ 在開啟 rabbitmq_tracing 插件的時候也會極大影響其性能。
性能指什么？
消息中間件的性能一般是指其吞吐量。雖然從功能維度上來說，RabbitMQ 的優(yōu)勢要大于 Kafka，但是 Kafka 的吞吐量要比 RabbitMQ 高出 1 至 2 個數(shù)量級。
一般 RabbitMQ 的單機 QPS 在萬級別之內(nèi)，而 Kafka 的單機 QPS 可以維持在十萬級別，甚至可以達到百萬級。
注明：消息中間件的吞吐量始終會受到硬件層面的限制。就以網(wǎng)卡帶寬為例，如果單機單網(wǎng)卡的帶寬為 1Gbps，如果要達到百萬級的吞吐，那么消息體大小不得超過(1Gb/8)/100W，即約等于 134B。
換句話說如果消息體大小超過 134B，那么就不可能達到百萬級別的吞吐。這種計算方式同樣可以適用于內(nèi)存和磁盤。
性能的指標(biāo)是什么？
時延作為性能維度的一個重要指標(biāo)，卻往往在消息中間件領(lǐng)域被忽視，因為一般使用消息中間件的場景對時效性的要求并不是很高，如果要求時效性完全可以采用 RPC 的方式實現(xiàn)。
消息中間件具備消息堆積的能力，消息堆積越大也就意味著端到端的時延也就越長，與此同時延時隊列也是某些消息中間件的一大特色。那么為什么還要關(guān)注消息中間件的時延問題呢？
消息中間件能夠解耦系統(tǒng)，對于一個時延較低的消息中間件而言，它可以讓上游生產(chǎn)者發(fā)送消息之后可以迅速的返回，也可以讓消費者更加快速的獲取到消息，在沒有堆積的情況下，可以讓整體上下游的應(yīng)用之間的級聯(lián)動作更加高效。
雖然不建議在時效性很高的場景下使用消息中間件，但是如果所使用的消息中間件的時延方面比較優(yōu)秀，那么對于整體系統(tǒng)的性能將會是一個不小的提升。
可靠性+可用性
消息丟失是使用消息中間件時所不得不面對的一個痛點，其背后消息可靠性也是衡量消息中間件好壞的一個關(guān)鍵因素。尤其是在金融支付領(lǐng)域，消息可靠性尤為重要。
然而說到可靠性必然要說到可用性，注意這兩者之間的區(qū)別：
消息中間件的可靠性是指對消息不丟失的保障程度。
而消息中間件的可用性是指無故障運行的時間百分比，通常用幾個 9 來衡量。
從狹義的角度來說，分布式系統(tǒng)架構(gòu)是一致性協(xié)議理論的應(yīng)用實現(xiàn)，對于消息可靠性和可用性而言也可以追溯到消息中間件背后的一致性協(xié)議：
對于 Kafka 而言，其采用的是類似 PacificA 的一致性協(xié)議，通過 ISR（In-Sync-Replica）來保證多副本之間的同步，并且支持強一致性語義（通過 Acks 實現(xiàn)）。
對應(yīng)的 RabbitMQ 是通過鏡像環(huán)形隊列實現(xiàn)多副本及強一致性語義的。
多副本可以保證在 Master 節(jié)點宕機異常之后可以提升 Slave 作為新的 Master 而繼續(xù)提供服務(wù)來保障可用性。
Kafka 設(shè)計之初是為日志處理而生，給人們留下了數(shù)據(jù)可靠性要求不高的不良印象，但是隨著版本的升級優(yōu)化，其可靠性得到極大的增強，詳細可以參考 KIP101。
就目前而言，在金融支付領(lǐng)域使用 RabbitMQ 居多，而在日志處理、大數(shù)據(jù)等方面 Kafka 使用居多，隨著 RabbitMQ 性能的不斷提升和 Kafka 可靠性的進一步增強，相信彼此都能在以前不擅長的領(lǐng)域分得一杯羹。
同步刷盤是增強一個組件可靠性的有效方式，消息中間件也不例外，Kafka 和 RabbitMQ 都可以支持同步刷盤。
但是筆者對同步刷盤有一定的疑問：絕大多數(shù)情景下，一個組件的可靠性不應(yīng)該由同步刷盤這種極其損耗性能的操作來保障，而是采用多副本的機制來保證。
這里還要提及的一個方面是擴展能力，這里我狹隘地將此歸納到可用性這一維度，消息中間件的擴展能力能夠增強其可用能力及范圍，比如前面提到的 RabbitMQ 支持多種消息協(xié)議，這個就是基于其插件化的擴展實現(xiàn)。
還有從集群部署上來講，歸功于 Kafka 的水平擴展能力，其基本上可以達到線性容量提升的水平，在 LinkedIn 實踐介紹中就提及了有部署超過千臺設(shè)備的 Kafka 集群。
運維管理
在消息中間件的使用過程中難免會出現(xiàn)各式各樣的異常情況，有客戶端的，也有服務(wù)端的，那么怎樣及時有效的進行監(jiān)測及修復(fù)？
業(yè)務(wù)線流量有峰值有低谷，尤其是電商領(lǐng)域，那么怎樣進行有效的容量評估，尤其是大促期間？腳踢電源、網(wǎng)線被挖等事件層出不窮，如何有效的做好異地多活？
這些都離不開消息中間件的衍生產(chǎn)品——運維管理。運維管理也可以進行進一步的細分，比如申請、審核、監(jiān)控、告警、管理、容災(zāi)、部署等。
申請、審核很好理解，在源頭對資源進行管控，既可以有效校正應(yīng)用方的使用規(guī)范，配合監(jiān)控也可以做好流量統(tǒng)計與流量評估工作。
一般申請、審核與公司內(nèi)部系統(tǒng)交融性較大，不適合使用開源類的產(chǎn)品。
監(jiān)控、告警也比較好理解，對消息中間件的使用進行全方位的監(jiān)控，既可以為系統(tǒng)提供基準(zhǔn)數(shù)據(jù)，也可以在檢測到異常的情況配合告警，以便運維、開發(fā)人員的迅速介入。
除了一般的監(jiān)控項（比如硬件、GC 等）之外，消息中間件還需要關(guān)注端到端時延、消息審計、消息堆積等方面：
對于 RabbitMQ 而言，最正統(tǒng)的監(jiān)控管理工具莫過于 rabbitmq_management 插件了，但是社區(qū)內(nèi)還有 AppDynamics、Collectd、DataDog、Ganglia、Munin、Nagios、New Relic、Prometheus、Zenoss 等多種優(yōu)秀的產(chǎn)品。
Kafka 在此方面也毫不遜色，比如：Kafka Manager、Kafka Monitor、Kafka Offset Monitor、Burrow、Chaperone、Confluent Control Center 等產(chǎn)品，尤其是 Cruise 還可以提供自動化運維的功能。
不管是擴容、降級、版本升級、集群節(jié)點部署、還是故障處理都離不開管理工具的應(yīng)用，一個配套完備的管理工具集可以在遇到變更時做到事半功倍。
故障可大可小，一般是一些應(yīng)用異常，也可以是機器掉電、網(wǎng)絡(luò)異常、磁盤損壞等單機故障，這些故障單機房內(nèi)的多副本足以應(yīng)付。
如果是機房故障就要涉及異地容災(zāi)了，關(guān)鍵點在于如何有效的進行數(shù)據(jù)復(fù)制，Kafka 可以參考 MirrorMarker、uReplicator 等產(chǎn)品，而 RabbitMQ 可以參考 Federation 和 Shovel。
社區(qū)力度及生態(tài)發(fā)展
對于目前流行的編程語言而言，如 Java、Python，如果你在使用過程中遇到了一些異常，基本上可以通過搜索引擎的幫助來得到解決，因為一個產(chǎn)品用的人越多，踩過的坑也就越多，對應(yīng)的解決方案也就越多。
消息中間件也同樣適用，如果你選擇了一種“生僻”的消息中間件，可能在某些方面運用的得心應(yīng)手，但是版本更新緩慢、遇到棘手問題也難以得到社區(qū)的支持而越陷越深。
相反如果你選擇了一種“流行”的消息中間件，其更新力度大，不僅可以迅速的彌補之前的不足，而且也能順應(yīng)技術(shù)的快速發(fā)展來變更一些新的功能，這樣可以讓你也“站在巨人的肩膀上”。
在運維管理維度我們提及了 Kafka 和 RabbitMQ 都有一系列開源的監(jiān)控管理產(chǎn)品，這些正是得益于其社區(qū)及生態(tài)的迅猛發(fā)展。
消息中間件選型誤區(qū)總結(jié)
選型誤區(qū)
在進行消息中間件選型之前可以先問自己一個問題：是否真的需要一個消息中間件？
在搞清楚這個問題之后，還可以繼續(xù)問自己一個問題：是否需要自己維護一套消息中間件？
很多初創(chuàng)型公司為了節(jié)省成本會選擇直接購買消息中間件有關(guān)的云服務(wù)，自己只需要關(guān)注收發(fā)消息即可，其余的都可以外包出去。
很多人面對消息中間件有一種自研的沖動，你完全可以對 Java 中的 ArrayBlockingQueue 做一個簡單的封裝，你也可以基于文件、數(shù)據(jù)庫、Redis 等底層存儲封裝而形成一個消息中間件。
消息中間件做為一個基礎(chǔ)組件并沒有想象中的那么簡單，其背后還需要配套的管理運維整個生態(tài)的產(chǎn)品集。
自研還會有交接問題，如果文檔不齊全、運作不規(guī)范將會帶給新人噩夢般的體驗。
是否真的有自研的必要？如果不是 KPI 的壓迫可以先考慮下面這兩個問題：
目前市面上的消息中間件是否都真的無法滿足目前的業(yè)務(wù)需求？
團隊是否有足夠的能力、人力、財力、精力來支持自研？
很多人在做消息中間件選型時會參考網(wǎng)絡(luò)上的很多對比類的文章，但是其專業(yè)性、嚴(yán)謹(jǐn)性、以及其政治立場問題都有待考證，需要帶著懷疑的態(tài)度去審視這些文章。
比如有些文章會在沒有任何限定條件及場景的情況下直接定義某款消息中間件最好。
還有些文章沒有指明消息中間件版本及測試環(huán)境就來做功能和性能對比分析，諸如此類的文章都可以唾棄之。
消息中間件猶如小馬過河，選擇合適的才最重要。這需要貼合自身的業(yè)務(wù)需求，技術(shù)服務(wù)于業(yè)務(wù)，大體上可以根據(jù)上一節(jié)所提及的功能、性能等 6 個維度來一一進行篩選。更深層次的抉擇在于你能否掌握其魂。
筆者鄙見：RabbitMQ 在于 Routing，而 Kafka 在于 Streaming，了解其根本對于自己能夠?qū)ΠY下藥選擇到合適的消息中間件尤為重要。
消息中間件選型切忌一味的追求性能或者功能，性能可以優(yōu)化，功能可以二次開發(fā)。
如果要在功能和性能方面做一個抉擇的話，那么選性能，因為總體上來說性能優(yōu)化的空間沒有功能擴展的空間大。然而看長期發(fā)展，生態(tài)又比性能以及功能都要重要。
可靠性誤區(qū)
很多時候，可靠性方面也容易存在一個誤區(qū)：想要找到一個產(chǎn)品來保證消息的絕對可靠，很不幸的是這世界上沒有絕對的東西，只能說盡量趨于完美。
想要盡可能的保障消息的可靠性也并非單單只靠消息中間件本身，還要依賴于上下游，需要從生產(chǎn)端、服務(wù)端和消費端這 3 個維度去努力保證。
消息中間件選型還有一個考量標(biāo)準(zhǔn)就是盡量貼合團隊自身的技術(shù)棧體系，雖然說沒有蹩腳的消息中間件，只有蹩腳的程序員，但是讓一個 C 棧的團隊去深挖 PhxQueue 總比去深挖 Scala 編寫的 Kafka 要容易的多。
消息中間件大道至簡：一發(fā)一存一消費，沒有最好的消息中間件，只有最合適的消息中間件。

在格爾木等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站制作、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需規(guī)劃網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,營銷型網(wǎng)站,成都外貿(mào)網(wǎng)站建設(shè),格爾木網(wǎng)站建設(shè)費用合理。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享名稱：消息中間件Kafka與RabbitMQ誰更勝一籌？-創(chuàng)新互聯(lián)
網(wǎng)頁網(wǎng)址：http://muchs.cn/article44/dphhee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、響應(yīng)式網(wǎng)站、移動網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、企業(yè)建站、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)