消息隊列的理解，幾種常見消息隊列對比，新手也能看得懂！—-分散式中間件消息隊列

• 2020 年 5 月 22 日
• 筆記

• 消息隊列的應用場景

廢話不多說，全是容易理解的乾貨。部落客最開始接觸消息隊列的時候是公司的轉型，由傳統業務轉型分散式。可以想像一下，分散式項目中兩個微服務之間相互調用怎麼調用？然後大家七嘴八舌

「我知道！我知道！用註冊中心！」

「我知道！我知道！用網關用網關」

「啊啊啊！我也知道Nginx！！」

哈哈哈 大家別笑，這些都是我之前的想法哈哈哈
真正進入項目的時候會遇到一個問題，你需要調用的微服務人還沒開始寫你咋調？你請求發過去一個個請求挨個消費，就在那排隊乾等著？分散式系統的高並發量一下給你系統衝擊的癱瘓掉？這些問題一出來就暴露了分散式項目一個很大的弊端，也是為什麼要用消息隊列的原因。

• 為什麼使用消息隊列

消息隊列相當於是一個中間商，這部分概念有點像中介。消費者發出的請求全到這裡，然後由消息隊列去幫你完成。

第一：舉一個生活中的場景，你需要寄一個快遞，聯繫快遞員，聯繫之後這段時間你需要在家裡等快遞員不能出門。？？？？？？？？？？（黑人問號，寄個快遞好像被禁錮了）。

目前這個困境算是解決掉了，通過快遞櫃，你需要寄的快遞放在快遞櫃里就OK了，這樣你的時間就會被解放出來，也就是程式設計師口中的非同步和解耦。這樣你就好快遞員之間沒有必然的耦合關係了。他啥時候來，今天來不來對你的影響就不是很大了。這個快遞櫃就相當於我們的消息隊列，你存快遞就是發請求，快遞員取你的快遞並發走就是請求的消費。非同步和解耦就被消息隊列實現了。

第二：當有高並發需求時，消息隊列可以把眾多的請求緩一下，然後以一個不是很劇烈的節奏去讓他們消費。這樣就消去了請求峰值。

• 消息隊列的種類以及對比

目前比較常見的消息隊列有ActiveMQ、RabbitMQ、RocketMQ、kafka（Redis也可以做這個功能，再次感慨Redis的強大）

簡單介紹一下他們的區別
ActiveMQ：早期的消息隊列，社區比較成熟，但是性能已經有點落後了，更新也慢，所以不建議用

RabbitMQ：在處理大量數據方面不及RocketMQ 、kafka，但是由於它基於 erlang 開發，所以並發能力很強，性能極其好，延時很低，達到微秒級，因此如果並發量不是很大的話，只有十來萬，百萬以內，你不用Rabbit你在想啥？

RocketMQ：這是阿里的開源項目，可以根據自己的需求DIY訂製，前提是你有這個實力（扎心了！）。有一個問題是RocketMQ沒有老老實實按照統一的消息隊列的規範來，修改起來得刪刪改改很多地方，雖然性能也很好，但是阿里哪天不想要它了，那你估計也難受了。如果如果如果公司實力很牛*，可以忽略掉這點，使用RocketMQ很香的。

kafka：他的特點很明顯，他的功能很少，但是巨牛*的吞吐量，毫秒級別的延遲。但是它唯一的缺點就是可能出現重複消費情況，概率雖然很小，但是對超大數量的資訊處理，這點毛毛雨基本上可以忽略掉。就像你列印上千萬行日誌消息，你會在意中間漏了一條日誌么?

• 消息隊列帶來的問題

系統可用性降低： 系統可用性在某種程度上降低，為什麼這樣說呢？在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之後你就需要去考慮了！

系統複雜性提高： 加入MQ之後，你需要保證消息沒有被重複消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！

一致性問題： 我上面講了消息隊列可以實現非同步，消息隊列帶來的非同步確實可以提高系統響應速度。但是，萬一消息的真正消費者並沒有正確消費消息怎麼辦？這樣就會導致數據不一致的情況了!

一致性問題的解決辦法
上面提到的,當你吧消息發送到消息隊列,但是消息隊列和另外微服務那邊出故障了沒執行完成該怎麼辦?
這裡舉個例子吧，你在12306上訂票，怎麼處理的？
對啦！就是先給你返回，後面如果失敗了會給你回復一些資訊，發個簡訊啥的，總之也算是一個解決辦法。嘿嘿
全都是手敲的，有點錯字的話大家別介意，看看就行！