- 消息隊列的應用場景
廢話不多說，全是容易理解的干貨。博主最開始接觸消息隊列的時候是公司的轉型，由傳統業務轉型分布式。可以想象一下，分布式項目中兩個微服務之間相互調用怎么調用？然后大家七嘴八舌
“我知道！我知道！用注冊中心！”
“我知道！我知道！用網關用網關”
“啊啊啊！我也知道Nginx！！”
哈哈哈 大家別笑，這些都是我之前的想法哈哈哈
真正進入項目的時候會遇到一個問題，你需要調用的微服務人還沒開始寫你咋調？你請求發過去一個個請求挨個消費，就在那排隊干等着？分布式系統的高並發量一下給你系統沖擊的癱瘓掉？這些問題一出來就暴露了分布式項目一個很大的弊端，也是為什么要用消息隊列的原因。
- 為什么使用消息隊列
消息隊列相當於是一個中間商，這部分概念有點像中介。消費者發出的請求全到這里，然后由消息隊列去幫你完成。
第一：舉一個生活中的場景，你需要寄一個快遞，聯系快遞員，聯系之后這段時間你需要在家里等快遞員不能出門。？？？？？？？？？？（黑人問號，寄個快遞好像被禁錮了）。
目前這個困境算是解決掉了，通過快遞櫃，你需要寄的快遞放在快遞櫃里就OK了，這樣你的時間就會被解放出來，也就是程序員口中的異步和解耦。這樣你就好快遞員之間沒有必然的耦合關系了。他啥時候來，今天來不來對你的影響就不是很大了。這個快遞櫃就相當於我們的消息隊列，你存快遞就是發請求，快遞員取你的快遞並發走就是請求的消費。異步和解耦就被消息隊列實現了。
第二：當有高並發需求時，消息隊列可以把眾多的請求緩一下，然后以一個不是很劇烈的節奏去讓他們消費。這樣就消去了請求峰值。
- 消息隊列的種類以及對比
目前比較常見的消息隊列有ActiveMQ、RabbitMQ、RocketMQ、kafka（Redis也可以做這個功能，再次感慨Redis的強大）
簡單介紹一下他們的區別
ActiveMQ：早期的消息隊列，社區比較成熟，但是性能已經有點落后了，更新也慢，所以不建議用
RabbitMQ：在處理大量數據方面不及RocketMQ 、kafka，但是由於它基於 erlang 開發，所以並發能力很強，性能極其好，延時很低，達到微秒級，因此如果並發量不是很大的話，只有十來萬，百萬以內，你不用Rabbit你在想啥？
RocketMQ：這是阿里的開源項目，可以根據自己的需求DIY定制，前提是你有這個實力（扎心了！）。有一個問題是RocketMQ沒有老老實實按照統一的消息隊列的規范來，修改起來得刪刪改改很多地方，雖然性能也很好，但是阿里哪天不想要它了，那你估計也難受了。如果如果如果公司實力很牛*，可以忽略掉這點，使用RocketMQ很香的。
kafka：他的特點很明顯，他的功能很少，但是巨牛*的吞吐量，毫秒級別的延遲。但是它唯一的缺點就是可能出現重復消費情況，概率雖然很小，但是對超大數量的信息處理，這點毛毛雨基本上可以忽略掉。就像你打印上千萬行日志消息，你會在意中間漏了一條日志么?
- 消息隊列帶來的問題
系統可用性降低： 系統可用性在某種程度上降低，為什么這樣說呢？在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后你就需要去考慮了！
系統復雜性提高： 加入MQ之后，你需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！
一致性問題： 我上面講了消息隊列可以實現異步，消息隊列帶來的異步確實可以提高系統響應速度。但是，萬一消息的真正消費者並沒有正確消費消息怎么辦？這樣就會導致數據不一致的情況了!
一致性問題的解決辦法
上面提到的,當你吧消息發送到消息隊列,但是消息隊列和另外微服務那邊出故障了沒執行完成該怎么辦?
這里舉個例子吧，你在12306上訂票，怎么處理的？
對啦！就是先給你返回，后面如果失敗了會給你回復一些信息，發個短信啥的，總之也算是一個解決辦法。嘿嘿
全都是手敲的，有點錯字的話大家別介意，看看就行！