領(lǐng)導(dǎo)的要求：你來對(duì) Kafka、RabbitMQ 以及 RocketMQ 進(jìn)行技術(shù)選型調(diào)研

1、小猛的頓悟：訂單系統(tǒng)的很多問題都可以用MQ來解決

小猛昨天聽了明哥對(duì)MQ這個(gè)東西的一番解釋之后，已經(jīng)有了一個(gè)基本的概念了，他回到家里仔細(xì)的想了想，發(fā)現(xiàn)似乎訂單系統(tǒng)面臨的很多問題都可以用MQ來解決！

舉個(gè)例子，支付訂單流程中步驟過多，導(dǎo)致性能很差。這個(gè)問題可以用MQ來解決，讓訂單系統(tǒng)僅僅完成最核心的一些步驟和調(diào)用，然后發(fā)送消息到MQ，比如倉(cāng)儲(chǔ)系統(tǒng)之類的就可以從MQ里獲取消息，然后慢慢的執(zhí)行一些很耗時(shí)的步驟。

還有比如訂單系統(tǒng)在退款的時(shí)候，可能會(huì)遇到第三方支付系統(tǒng)退款失敗的問題，從而影響整個(gè)退款流程的失敗，這個(gè)問題也可以用MQ解決?？梢宰層唵蜗到y(tǒng)在退款的時(shí)候完成公司內(nèi)部各個(gè)系統(tǒng)的流程，然后發(fā)送消息到MQ，由一個(gè)專門的服務(wù)去負(fù)責(zé)調(diào)用第三方支付系統(tǒng)，處理可能出現(xiàn)的失敗。

在雙11大促活動(dòng)的時(shí)候，也可以讓瞬間涌入的大量下單請(qǐng)求到MQ里去排隊(duì)，然后讓訂單系統(tǒng)在后臺(tái)慢慢的獲取訂單，以數(shù)據(jù)庫可以接受的速率完成操作，避免瞬間請(qǐng)求量過大擊垮數(shù)據(jù)庫。

小猛想著覺得很興奮，訂單系統(tǒng)的諸多問題似乎都可以基于MQ來解決??！

他一大早去公司上班之后，就把自己的那些想法告訴了明哥，明哥非常的高興，他覺得小猛真是太棒了，自己就領(lǐng)悟出來了MQ在訂單系統(tǒng)里的各種用法！

2、萬事開頭難：要在訂單系統(tǒng)里用MQ技術(shù)，從哪一步開始呢？

聽著明哥的表揚(yáng)，小猛覺得特別的開心，但是另外一方面，他也有一個(gè)很大的疑問，雖然知道MQ是一個(gè)東西，可以解決訂單系統(tǒng)的一些問題，但是萬事開頭難，到底應(yīng)該從哪里入手呢？

他跟明哥提出了自己的疑惑，明哥笑著說，要做一些技術(shù)架構(gòu)的升級(jí)，引入一些新的技術(shù)，當(dāng)然要從技術(shù)調(diào)研開始了。

小猛很疑惑：技術(shù)調(diào)研應(yīng)該怎么做？

明哥解釋道：其實(shí)技術(shù)調(diào)研說白了，就是對(duì)一個(gè)技術(shù)去找到一些業(yè)內(nèi)常用的開源實(shí)現(xiàn)，然后對(duì)各種不同的實(shí)現(xiàn)都進(jìn)行一些調(diào)研，對(duì)比一下他們的優(yōu)劣勢(shì)，看看誰比較符合我們的需求，誰比較適合我們來使用。

具體來說，比如對(duì)于我們現(xiàn)在的情況，你只知道有一個(gè)MQ的概念，但是你要考慮一下：

• 業(yè)內(nèi)常用的MQ有哪些？

• 每一種MQ各自的表現(xiàn)如何？

• 這些MQ在同等機(jī)器條件下，能抗多少Q(mào)PS（每秒抗幾千QPS還是幾萬QPS）？

• 性能有多高（發(fā)送一條消息給他要2ms還是20ms）？

• 可用性能不能得到保證（要是MQ部署的機(jī)器掛了怎么辦）？

然后你還得考慮：

• 他們會(huì)不會(huì)丟失數(shù)據(jù)？

• 如果需要的話能否讓他們進(jìn)行線性的集群擴(kuò)容（就是多加幾臺(tái)機(jī)器）？

• 消息中間件經(jīng)常需要使用的一些功能他們都有嗎（比如說延遲消息、事務(wù)消息、消息堆積、消息回溯、死信隊(duì)列，等等）？

另外還得考慮這些MQ在文檔是否齊全？社區(qū)是否活躍？在行業(yè)內(nèi)是否廣泛運(yùn)用？是用什么語言編寫的？

把這些事情都搞清楚了，那么你就完成了技術(shù)調(diào)研，可以全面的對(duì)比各種MQ的優(yōu)劣勢(shì)，然后從中選擇一個(gè)最適合我們的來使用。

小猛都沒反應(yīng)過來呢，明哥接著說道，這個(gè)技術(shù)調(diào)研的任務(wù)，我就打算交給你了！正好讓你借著這個(gè)機(jī)會(huì)對(duì)各種MQ有一個(gè)基本的了解。其實(shí)也沒你想的那么難，對(duì)你來說要做調(diào)研的話，就是上網(wǎng)搜集資料，然后進(jìn)行梳理對(duì)比就可以了。

小猛尷尬的說，好吧，那我盡力而為。

3、Kafka、RabbitMQ以及RocketMQ的調(diào)研對(duì)比

過了幾天，小猛就完成了一份MQ技術(shù)調(diào)研報(bào)告，他找到了明哥，開始講起了自己做這份調(diào)研報(bào)告的心得體會(huì)。

首先，小猛通過網(wǎng)上搜集資料，發(fā)現(xiàn)一般國(guó)內(nèi)常用的MQ技術(shù)有四種實(shí)現(xiàn)，ActiveMQ、Kafka、RabbitMQ、RocketMQ，但是其中ActiveMQ主要是幾年以前較多公司使用，現(xiàn)在幾乎國(guó)內(nèi)用的公司都很少了。

因此小猛搜集資料的時(shí)候主要是針對(duì)Kafka、RabbitMQ、RocketMQ三種技術(shù)做的調(diào)研。

（1）Kafka的優(yōu)勢(shì)和劣勢(shì)

先來說Kafka，小猛通過查閱一些Kafka的基本資料發(fā)現(xiàn)，首先Kafka的吞吐量幾乎是行業(yè)里最優(yōu)秀的，在常規(guī)的機(jī)器配置下，一臺(tái)機(jī)器可以達(dá)到每秒十幾萬的QPS，相當(dāng)?shù)膹?qiáng)悍。

Kafka性能也很高，基本上發(fā)送消息給Kafka都是毫秒級(jí)的性能?？捎眯砸埠芨撸琄afka是可以支持集群部署的，其中部分機(jī)器宕機(jī)是可以繼續(xù)運(yùn)行的。

但是Kafka比較為人詬病的一點(diǎn)，似乎是丟數(shù)據(jù)方面的問題，因?yàn)镵afka收到消息之后會(huì)寫入一個(gè)磁盤緩沖區(qū)里，并沒有直接落地到物理磁盤上去，所以要是機(jī)器本身故障了，可能會(huì)導(dǎo)致磁盤緩沖區(qū)里的數(shù)據(jù)丟失。

而且Kafka另外一個(gè)比較大的缺點(diǎn)，就是功能非常的單一，主要是支持發(fā)送消息給他，然后從里面消費(fèi)消息，其他就沒有什么額外的高級(jí)功能了。所以基于Kafka有限的功能，可能適用的場(chǎng)景并不是很多。

因此綜上所述，以及查閱了Kafka技術(shù)在各大公司里的使用，基本行業(yè)里的一個(gè)標(biāo)準(zhǔn)，是把Kafka用在用戶行為日志的采集和傳輸上，比如大數(shù)據(jù)團(tuán)隊(duì)要收集APP上用戶的一些行為日志，這種日志就是用Kafka來收集和傳輸?shù)摹?/p>

因?yàn)槟欠N日志適當(dāng)丟失數(shù)據(jù)是沒有關(guān)系的，而且一般量特別大，要求吞吐量要高，一般就是收發(fā)消息，不需要太多的高級(jí)功能，所以Kafka是非常適合這種場(chǎng)景的。

（2）RabbitMQ的優(yōu)勢(shì)和歷史

再說RabbitMQ，在RocketMQ出現(xiàn)之前，國(guó)內(nèi)大部分公司都從ActiveMQ切換到RabbitMQ來使用，包括很多一線互聯(lián)網(wǎng)大廠，而且直到現(xiàn)在都有很多中小型公司在使用RabbitMQ。

RabbitMQ的優(yōu)勢(shì)在于可以保證數(shù)據(jù)不丟失，也能保證高可用性，即集群部署的時(shí)候部分機(jī)器宕機(jī)可以繼續(xù)運(yùn)行，然后支持部分高級(jí)功能，比如說死信隊(duì)列，消息重試之類的，這些是他的優(yōu)點(diǎn)。

但是他也有一些缺點(diǎn)，最為人詬病的，就是RabbitMQ的吞吐量是比較低的，一般就是每秒幾萬的級(jí)別，所以如果遇到特別特別高并發(fā)的情況下，支撐起來是有點(diǎn)困難的。

而且他進(jìn)行集群擴(kuò)展的時(shí)候（也就是加機(jī)器部署），還比較麻煩。

另外還有一個(gè)較為致命的缺陷，就是他的開發(fā)語言是erlang，國(guó)內(nèi)很少有精通erlang語言的工程師，因此也沒辦法去閱讀他的源代碼，甚至修改他的源代碼。

所以現(xiàn)在行業(yè)里的一個(gè)情況是，很多BAT等一線互聯(lián)網(wǎng)大廠都切換到使用更加優(yōu)秀的RocketMQ了，但是很多中小型公司覺得RabbitMQ基本可以滿足自己的需求還在繼續(xù)使用中，因?yàn)橹行⌒凸静⒉恍枰貏e高的吞吐量，RabbitMQ已經(jīng)足以滿足他們的需求了，而且也不需要部署特別大規(guī)模的集群，也沒必要去閱讀和修改RabbitMQ的源碼。

（3）RocketMQ的優(yōu)勢(shì)和劣勢(shì)

RocketMQ是阿里開源的消息中間件，久經(jīng)沙場(chǎng)，非常的靠譜。他幾乎同時(shí)解決了Kafka和RabbitMQ的缺陷。

RocketMQ的吞吐量也同樣很高，單機(jī)可以達(dá)到10萬QPS以上，而且可以保證高可用性，性能很高，而且支持通過配置保證數(shù)據(jù)絕對(duì)不丟失，可以部署大規(guī)模的集群，還支持各種高級(jí)的功能，比如說延遲消息、事務(wù)消息、消息回溯、死信隊(duì)列、消息積壓，等等。

而且RocketMQ是基于Java開發(fā)的，符合國(guó)內(nèi)大多數(shù)公司的技術(shù)棧，很容易就可以閱讀他的源碼，甚至是修改他的源碼。

所以現(xiàn)在國(guó)內(nèi)很多一線互聯(lián)網(wǎng)大廠都切換為使用RocketMQ了，他們需要RocketMQ的高吞吐量，大規(guī)模集群部署能力，以及各種高階的功能去支撐自己的各種業(yè)務(wù)場(chǎng)景，同時(shí)還可以根據(jù)自己的需求定制修改RocketMQ的源碼。

RocketMQ是非常適合用在Java業(yè)務(wù)系統(tǒng)架構(gòu)中的，因?yàn)樗芨叩男阅鼙憩F(xiàn)，還有他的高階功能的支持，可以讓我們解決各種業(yè)務(wù)問題。

當(dāng)然，RocketMQ也有一點(diǎn)美中不足的地方，就是經(jīng)過我的調(diào)查發(fā)現(xiàn)，RocketMQ的官方文檔相對(duì)簡(jiǎn)單一些，但是Kafka和RabbitMQ的官方文檔就非常的全面和詳細(xì)，這可能是RocketMQ目前唯一的缺點(diǎn)。

（4）活躍的社區(qū)和廣泛的運(yùn)用

最后一點(diǎn)，基本上Kafka、RabbitMQ和RocketMQ的社區(qū)都還算活躍，更新頻率都還可以，而且基本運(yùn)用都非常的廣泛。

尤其是Kafka和RabbitMQ，目前Kafka幾乎是國(guó)內(nèi)大數(shù)據(jù)領(lǐng)域日志采集傳輸?shù)臉?biāo)準(zhǔn)，RabbitMQ在各種中小公司里運(yùn)用極為廣泛，RocketMQ也是開始在一些大公司和其他公司里快速推行中。

4、經(jīng)驗(yàn)老到的明哥：其實(shí)我早有準(zhǔn)備

當(dāng)小猛把這一番調(diào)研結(jié)果結(jié)合自己寫好的調(diào)研文檔給明哥講完之后，明哥哈哈的笑著說，不錯(cuò)不錯(cuò)，以一個(gè)新人的能力而言，做調(diào)研到這個(gè)程度基本上是差不多了。

不過其實(shí)幾種MQ的技術(shù)對(duì)比和分析，我自己也早就做過了，讓你去做這個(gè)調(diào)研，主要是鍛煉一下你，讓你多了解了解。

小猛有點(diǎn)不好意思的撓撓頭說到：原來是這樣，那我就不在關(guān)公面前耍大刀了，明哥，那你覺得我們?cè)撚媚膫€(gè)MQ呢？

似乎看起來RabbitMQ也能滿足我們，畢竟我們現(xiàn)在也屬于中小型互聯(lián)網(wǎng)公司，并發(fā)量沒那么大；但是RocketMQ似乎是更好的選擇，他規(guī)避掉了RabbitMQ的全部缺點(diǎn)。

明哥說到，雖然我們現(xiàn)在是一個(gè)中小型互聯(lián)網(wǎng)公司，看起來似乎RabbitMQ足以應(yīng)對(duì)我們的需求，但是假設(shè)未來我們成長(zhǎng)為一個(gè)大公司呢？也許我們也會(huì)有每秒幾十萬的QPS，也許我們以后也需要對(duì)MQ進(jìn)行源碼的二次開發(fā)，那此時(shí)RabbitMQ還合適嗎？

所以，我的決定是，一步到位，直接用RocketMQ作為我們公司的技術(shù)選型。

小猛聽完明哥的分析和決定之后，覺得老大霸氣側(cè)漏，那就啥也不說了，后面就跟著明哥用RocketMQ去重構(gòu)訂單系統(tǒng)吧！

End

專欄版權(quán)歸公眾號(hào)儒猿技術(shù)窩所有

未經(jīng)許可不得傳播，如有侵權(quán)將追究法律責(zé)任