前言
開門見山的說，MQ肯定是有用的，不然這麼多人用它幹嘛(當然可能有人覺得可以裝逼用2333）
不過這次我們要說的RocketMQ可不是美國進口的技術，是阿里巴巴捐贈給apache，讓apache孵化用的。
阿里巴巴官方給出的RocketMQ的特點
- 是一個隊列模型的消息中間件，具有高性能、高可靠、高實時、分佈式特點。
- Producer、Consumer、隊列都可以分佈式。
- Producer向一些隊列輪流發送消息，隊列集合稱爲Topic，Consumer如果做廣播消費，則一個consumer實例消費這個Topic對應的所有隊列，如果做集羣消費，則多個Consumer實例平均消費這個topic對應的隊列集合。
- 能夠保證嚴格的消息順序
- 提供豐富的消息拉取模式
- 高效的訂閱者水平擴展能力
- 實時的消息訂閱機制
- 億級消息堆積能力
- 較少的依賴
先說說MQ的作用：
- 解耦
假如現在兩個系統，當B系統crash掉，A系統也就涼了，這就是耦合帶來的問題。
![在這裏插入圖片描述]()
假如我現在用消息隊列，就是這樣子的。
![在這裏插入圖片描述]()
即使B系統crash，A系統照常運行，A只需要把消息給到消息隊列就可以。 - 異步
假如現在有這麼個業務場景，分別有三個系統，用戶支付成功後，支付系統調用生成訂單系統來生成訂單，再繼續調用通知用戶業務系統，最後返回給支付系統，是不是支付系統要等半天？
用戶就想了，我tm等半天才能下個單，以後不在你這買了，這就損失了一名客戶
加上消息隊列會咋樣？
依然是一個鏈式調用，不同的是，這次支付系統把任務信息告訴消息隊列就可以了，剩下的事情，他就不管了，而是又消息隊列和其他系統合作去完成。
- 削峯
RocketMQ可是阿里巴巴拿來抗雙十一的中間件，你說剛不剛？
我們都知道，如果同時給服務器本不該承受的壓力，它就會宕機。
而消息隊列在削峯方面的思想就是，把大量的訂單都放到消息隊列裏，挨個去處理，這樣的結果可能是有的用戶下單要等的久一些才能成功，但是好處就在於服
務器不會涼涼鴨，如果涼了，還賣啥？
一、 RocketMQ的組成
-
Message : 消息
-
Broker: RocketMQ的核心模塊，負責接收並存儲消息。
-
NameServer: RocketMQ的註冊中心，集羣的Topic-Queue的路由配置；Broker的實時配置信息。其它模塊通過Nameservr提供的接口獲取最新的Topic配置和路由信息。
-
Topic ：用於將消息按主題做劃分，Producer將消息發往指定的Topic，Consumer訂閱該Topic就可以收到這條消息。Topic跟發送方和消費方都沒有強關聯關係，發送方可以同時往多個Topic投放消息，消費方也可以訂閱多個Topic的消息。在RocketMQ中，Topic是一個上邏輯概念。消息存儲不會按Topic分開。
-
Tag： 標籤可以被認爲是對 Topic 進一步細化。一般在相同業務模塊中通過引入標籤來標記不同用途的消息。
-
Producer：消息的生產者
-
Consumer：消息的消費者
二、RocketMQ的整體架構
從上面抽象來看，RocketMQ的原理在於：
- 生產者將消息給到隊列(Broker)
- 隊列中的消息在邏輯上是以Topic來分類的，進一步還可以通過Tag來過濾
- 消費者消費消息
從下面這個圖，可以看到Rocket MQ天生就是分佈式的，Broker作爲存儲消息的核心組件，支持主從機制，一個掛了，我還有備用呢。
無論是Broker還是Name Server 都可以做分佈式，從而讓整個系統變得高可用
- 每個Broker與Name Server集羣中的所有節點建立長連接，定時註冊Topic信息到所有Name Server。
- Producer與Name Server集羣中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息。
- Consumer與Name Server集羣中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息。
參考
https://www.cnblogs.com/qdhxhz/p/11094624.html
http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/
本人水平有限，希望各位不吝賜教。