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

• 消息隊列的應用場景

廢話很少說，全是容易理解的乾貨。博主最開始接觸消息隊列的時候是公司的轉型，由傳統業務轉型分佈式。能夠想象一下，分佈式項目中兩個微服務之間相互調用怎麼調用？而後你們七嘴八舌

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

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

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

哈哈哈 你們別笑，這些都是我以前的想法哈哈哈
真正進入項目的時候會遇到一個問題，你須要調用的微服務人還沒開始寫你咋調？你請求發過去一個個請求挨個消費，就在那排隊乾等着？分佈式系統的高併發量一下給你係統衝擊的癱瘓掉？這些問題一出來就暴露了分佈式項目一個很大的弊端，也是爲何要用消息隊列的緣由。

• 爲何使用消息隊列

消息隊列至關因而一箇中間商，這部分概念有點像中介。消費者發出的請求全到這裏，而後由消息隊列去幫你完成。

 

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

目前這個困境算是解決掉了，經過快遞櫃，你須要寄的快遞放在快遞櫃裏就OK了，這樣你的時間就會被解放出來，也就是程序員口中的異步和解耦。這樣你就好快遞員之間沒有必然的耦合關係了。他啥時候來，今天來不來對你的影響就不是很大了。這個快遞櫃就至關於咱們的消息隊列，你存快遞就是發請求，快遞員取你的快遞併發走就是請求的消費。異步和解耦就被消息隊列實現了。

第二：當有高併發需求時，消息隊列能夠把衆多的請求緩一下，而後以一個不是很劇烈的節奏去讓他們消費。這樣就消去了請求峯值。

 

 

 

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

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

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

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

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

kafka：他的特色很明顯，他的功能不多，可是巨牛*的吞吐量，毫秒級別的延遲。可是它惟一的缺點就是可能出現重複消費狀況，機率雖然很小，可是對超大數量的信息處理，這點毛毛雨基本上能夠忽略掉。就像你打印上千萬行日誌消息，你會在乎中間漏了一條日誌麼?

• 消息隊列帶來的問題

系統可用性下降： 系統可用性在某種程度上下降，爲何這樣說呢？在加入MQ以前，你不用考慮消息丟失或者說MQ掛掉等等的狀況，可是，引入MQ以後你就須要去考慮了！

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

一致性問題： 我上面講了消息隊列能夠實現異步，消息隊列帶來的異步確實能夠提升系統響應速度。可是，萬一消息的真正消費者並無正確消費消息怎麼辦？這樣就會致使數據不一致的狀況了!

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