消息隊列基礎知識
消息隊列場景
異步
下單系統付了錢後，搞了個扣減優惠券、又搞了個增減積分、再來個發短信，這樣子搞下來流程RT(ResponseTime)響應就慢了，怎麼辦呢？
大概是這樣的
異步，在下單支付成功後，發消息，讓其它系統去處理，整個鏈路是這樣的。
解耦
訂單流程，扣積分，扣優惠券，發短信，去庫存。。。每次加一個你就要調用一個接口然後還要重新發布系統，耦合性太差了。所以通過MQ解耦，各系統做系統的事。
削峯
比方說秒殺，平時流量很低，做秒殺活動時，流量很大，突然懟進來了，服務器，Redis,Mysql各自承受能力不一樣，如果全部流量照單全收，必然會掛。
所以呢，把請求放在MQ隊列裏面，至於每秒消費多少，取決於服務器處理能力。比方說能處理5000QPS,那就每秒消費這麼多，稍微比正常的慢一點，不至於打掛服務器，等流量高峯下去了，服務也就沒壓力。
事務消息
下單了，支付成功的消息通過事務消息告訴周邊系統，各自去處理，要是下單掛了，周邊系統也就不會收到下單成功的消息。如果是周邊系統異常了，那也不影響下單程序嘛，讓其它系統的開發去負責排查了。各自管各自的系統嘛。
消息隊列的三個特點
系統複雜性
怎麼講呢，就是說一個簡單的系統，你引入消息中間件，就得考慮消息的重複消費、消息丟失、消息的順序消息等情況。
數據一致性
分佈式服務本身存在一個問題，不僅僅是消息隊列的問題。只是說數據一致性這個問題比較嚴重。
怎麼嚴重呢？比方說，你下單的服務保證自己成功了，成功發了消息，其它系統成功還是失敗，你就不管了嗎？
顯然這樣不好，所以呢，這裏要提下分佈式事務，把下單、優惠券、庫存、積分系統都放在一個事務裏，要成功都成功，要失敗都失敗。
可用性
消息集羣多Master多Slave,同步刷盤
消息組件那麼多，如何選呢？
比較主流的消息中間件有Kafa、ActiveMQ、RabbitMQ、RocketMQ等。。。
Kafa、RocketMQ在國內挺火的，很多大公司都在用。
下面再從網上找的圖對比下四大消息中間件的區別：
延伸閱讀
對RocketMQ感興趣的同學，點擊下方鏈接延伸閱讀：
RocketMQ事務消息原理解析：https://blog.csdn.net/Bao_jingyu/article/details/104726534
基於Docker部署RocketMQ雙主雙從異步集羣搭建：https://blog.csdn.net/Bao_jingyu/article/details/105359418