在高并發(fā)中如何選擇消息隊列

小編給大家分享一下在高并發(fā)中如何選擇消息隊列，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

在高并發(fā)業(yè)務(wù)場景下，消息隊列在流量削峰、解耦上有不可替代的作用。當(dāng)前使用較多的消息隊列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。

消息隊列這么多，到底該選擇哪款消息隊列呢？

選擇消息隊列的基本標(biāo)準(zhǔn)

雖然這些消息隊列在功能和特性方面各有優(yōu)劣，但我們在選擇的時候要有一個基本標(biāo)準(zhǔn)。

首先，必須是開源的產(chǎn)品。開源意味著，如果有一天你使用的消息隊列遇到了一個影響你系統(tǒng)業(yè)務(wù)的 Bug，至少還有機會通過修改源代碼來迅速修復(fù)或規(guī)避這個 Bug，解決你的系統(tǒng)的問題，而不是等待開發(fā)者發(fā)布的下一個版本來解決。

其次，這個產(chǎn)品必須是近年來比較流行并且有一定社區(qū)活躍度的產(chǎn)品。流行的好處是，只要使用場景不太冷門，遇到 Bug 的概率會非常低，因為大部分遇到的 Bug，其他人早就遇到并且修復(fù)了。在使用過程中遇到的一些問題，也比較容易在網(wǎng)上搜索到類似的問題，然后很快的找到解決方案。還有一個優(yōu)勢就是，流行的產(chǎn)品與周邊生態(tài)系統(tǒng)會有一個比較好的集成和兼容。

最后，作為一款及格的消息隊列，必須具備的幾個特性包括：

• 消息的可靠傳遞：確保不丟消息；

• Cluster：支持集群，確保不會因為某個節(jié)點宕機導(dǎo)致服務(wù)不可用，當(dāng)然也不能丟消息；

• 性能：具備足夠好的性能，能滿足絕大多數(shù)場景的性能要求。

接下來看一下有哪些符合上面這些條件，可供選擇的開源消息隊列。

RabbitMQ

首先，我們來看下消息隊列 RabbitMQ。RabbitMQ 于 2007 年發(fā)布，是使用 Erlang 編程語言編寫的，最早是為電信行業(yè)系統(tǒng)之間的可靠通信設(shè)計的，也是少數(shù)幾個支持 AMQP 協(xié)議的消息隊列之一。

RabbitMQ：輕量級、迅捷，它的宣傳口號，也很明確地表明了 RabbitMQ 的特點：Messaging that just works，開箱即用的消息隊列。也就是說，RabbitMQ 是一個相當(dāng)輕量級的消息隊列，非常容易部署和使用。

RabbitMQ 一個比較有特色的功能是支持非常靈活的路由配置，和其他消息隊列不同的是，它在生產(chǎn)者（Producer）和隊列（Queue）之間增加了一個 Exchange 模塊，可以理解為交換機。

Exchange 模塊的作用和交換機非常相似，根據(jù)配置的路由規(guī)則將生產(chǎn)者發(fā)出的消息分發(fā)到不同的隊列中。路由的規(guī)則也非常靈活，甚至可以自己來實現(xiàn)路由規(guī)則。如果正好需要這個功能，RabbitMQ 是個不錯的選擇。

RabbitMQ 的客戶端支持的編程語言大概是所有消息隊列中最多的。

接下來說下 RabbitMQ 的幾個問題：

1. RabbitMQ 對消息堆積的支持并不好，當(dāng)大量消息積壓的時候，會導(dǎo)致 RabbitMQ 的性能急劇下降。

2. RabbitMQ 的性能是這幾個消息隊列中最差的，大概每秒鐘可以處理幾萬到十幾萬條消息。如果應(yīng)用對消息隊列的性能要求非常高，那不要選擇 RabbitMQ。

3. RabbitMQ 使用的編程語言 Erlang，擴展和二次開發(fā)成本高。

RocketMQ

RocketMQ 是阿里巴巴在 2012 年開源的消息隊列產(chǎn)品，用 Java 語言實現(xiàn)，在設(shè)計時參考了 Kafka，并做出了自己的一些改進，后來捐贈給 Apache 軟件基金會，2017 正式畢業(yè)，成為 Apache 的頂級項目。RocketMQ 在阿里內(nèi)部被廣泛應(yīng)用在訂單，交易，充值，流計算，消息推送，日志流式處理，Binglog 分發(fā)等場景。經(jīng)歷過多次雙十一考驗，它的性能、穩(wěn)定性和可靠性都是值得信賴的。

RocketMQ 有著不錯的性能，穩(wěn)定性和可靠性，具備一個現(xiàn)代的消息隊列應(yīng)該有的幾乎全部功能和特性，并且它還在持續(xù)的成長中。

RocketMQ 有非常活躍的中文社區(qū)，大多數(shù)問題可以找到中文的答案。RocketMQ 使用 Java 語言開發(fā)，源代碼相對比較容易讀懂，容易對 RocketMQ 進行擴展或者二次開發(fā)。

RocketMQ 對在線業(yè)務(wù)的響應(yīng)時延做了很多的優(yōu)化，大多數(shù)情況下可以做到毫秒級的響應(yīng)，如果你的應(yīng)用場景很在意響應(yīng)時延，那應(yīng)該選擇使用 RocketMQ。

RocketMQ 的性能比 RabbitMQ 要高一個數(shù)量級，每秒鐘大概能處理幾十萬條消息。

RocketMQ 的劣勢是與周邊生態(tài)系統(tǒng)的集成和兼容程度不夠。

Kafka

Apache Kafka 是一個分布式消息發(fā)布訂閱系統(tǒng)。它最初由 LinkedIn 公司基于獨特的設(shè)計實現(xiàn)為一個分布式的日志提交系統(tǒng)，之后成為 Apache 項目的一部分。

在早期的版本中，為了獲得極致的性能，在設(shè)計方面做了很多的犧牲，比如不保證消息的可靠性，可能會丟失消息，也不支持集群，功能上也比較簡陋，這些犧牲對于處理海量日志這個特定的場景都是可以接受的。

但是，隨后幾年 Kafka 逐步補齊了這些短板，當(dāng)下的 Kafka 已經(jīng)發(fā)展為一個非常成熟的消息隊列產(chǎn)品，無論在數(shù)據(jù)可靠性、穩(wěn)定性和功能特性等方面都可以滿足絕大多數(shù)場景的需求。

Kafka 與周邊生態(tài)系統(tǒng)的兼容性是最好的沒有之一，尤其在大數(shù)據(jù)和流計算領(lǐng)域，幾乎所有的相關(guān)開源軟件系統(tǒng)都會優(yōu)先支持 Kafka。

Kafka 性能高效、可擴展良好并且可持久化。它的分區(qū)特性，可復(fù)制和可容錯都是不錯的特性。

Kafka 使用 Scala 和 Java 語言開發(fā)，設(shè)計上大量使用了批量和異步的思想，使得 Kafka 能做到超高的性能。Kafka 的性能，尤其是異步收發(fā)的性能，是三者中最好的，但與 RocketMQ 并沒有量級上的差異，大約每秒鐘可以處理幾十萬條消息。

在有足夠的客戶端并發(fā)進行異步批量發(fā)送，并且開啟壓縮的情況下，Kafka 的極限處理能力可以超過每秒 2000 萬條消息。

但是 Kafka 異步批量的設(shè)計帶來的問題是，它的同步收發(fā)消息的響應(yīng)時延比較高，因為當(dāng)客戶端發(fā)送一條消息的時候，Kafka 并不會立即發(fā)送出去，而是要等一會兒攢一批再發(fā)送，在它的 Broker 中，很多地方都會使用這種先攢一波再一起處理的設(shè)計。當(dāng)你的業(yè)務(wù)場景中，每秒鐘消息數(shù)量沒有那么多的時候，Kafka 的時延反而會比較高。所以，Kafka 不太適合在線業(yè)務(wù)場景。

消息隊列對比

以上是“在高并發(fā)中如何選擇消息隊列”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！