介紹：
消息隊列(Message Queue，簡稱MQ)。消息中間件作爲實現分佈式消息系統可拓展、可伸縮性的關鍵組件，具有高吞吐量、高可用等等優點。
優勢：
- 削峯填谷（主要解決瞬時寫壓力大於應用服務能力導致消息丟失、系統奔潰等問題）
- 系統解耦（解決不同重要程度、不同能力級別系統之間依賴導致一死全死）
- 提升性能（當存在一對多調用時，可以發一條消息給消息系統，讓消息系統通知相關係統）
- 蓄流壓測（線上有些鏈路不好壓測，可以通過堆積一定量消息再放開來壓測）
目前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相比於Rabbitmq、kafka具有主要優勢特性有：
- 支持事務型消息（消息發送和DB操作保持兩方的最終一致性，rabbitmq和kafka不支持）
- 支持結合rocketmq的多個系統之間數據最終一致性（多方事務，二方事務是前提）
- 支持18個級別的延遲消息（rabbitmq和kafka不支持）
- 支持指定次數和時間間隔的失敗消息重發（kafka不支持，rabbitmq需要手動確認）
- 支持consumer端tag過濾，減少不必要的網絡傳輸（rabbitmq和kafka不支持）
- 支持重複消費（rabbitmq不支持，kafka支持）
Rocketmq、kafka、Rabbitmq的詳細對比，請參照下表格：
基礎：
RocketMQ主要組成：NameServer、Broker（代理）、Producer（消
息生產者）、Cosumer（消息消費者）
集羣部署結構：
NameServer
NameServer： rocketmq名稱服務器，更新和發現 broker服務。一個幾乎無狀態節點，可集羣部署，節點之間無任何信息同步
Broker：消息中轉角色，負責存儲和轉發消息。
Broker分爲Master和Slave。一個Master可以對應多個Slave，但是一個Slave只能對應一個Master。Master和Slave的對應關係通過指定相同的BrokerName，不同的BrokerId來定義。BrokerId爲0表示Master，BrokerId非0表示Slave。然後所有的Broker和Name Server上的節點建立長連接,定時註冊Topic信息到所有Name Server。
Broker-Master：broker 消息主機服務器 Broker-Slave： broker 消息從機服務器
每個Broker與Name Server集羣中的所有節點建立長連接，定時(每隔30s)註冊Topic信息到所有Name Server。Name Server定時(每隔10s)掃描所有存活broker的連接，如果Name Server超過2分鐘沒有收到心跳，則Name Server斷開與Broker的連接。
Producer： 消息生產者。
Producer與Name Server其中一個節點建立連接。定期從Name Server取Topic信息。並與提供該Topic信息的Master建立長連接。Producer也可以集羣部署。
Producer每隔30s（由ClientConfig的pollNameServerInterval）從Name server獲取所有topic隊列的最新情況，這意味着如果Broker不可用，Producer最多30s能夠感知，在此期間內發往Broker的所有消息都會失敗。
Producer每隔30s（由ClientConfig中heartbeatBrokerInterval決定）向所有關聯的broker發送心跳，Broker每隔10s中掃描所有存活的連接，如果Broker在2分鐘內沒有收到心跳數據，則關閉與Producer的連接。
Consumer： 消息消費者。
Consumer 與Name Server 集羣中的其中一個節點（隨機選擇）建立長連接，定期從Name Server 取Topic 路由信息，並向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
Consumer每隔30s從Name server獲取topic的最新隊列情況，這意味着Broker不可用時，Consumer最多最需要30s才能感知。
Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval決定）向所有關聯的broker發送心跳，Broker每隔10s掃描所有存活的連接，若某個連接2分鐘內沒有發送心跳數據，則關閉連接；並向該Consumer Group的所有Consumer發出通知，Group內的Consumer重新分配隊列，然後繼續消費。
當Consumer得到master宕機通知後，轉向slave消費，slave不能保證master的消息100%都同步過來了，因此會有少量的消息丟失。但是一旦master恢復，未同步過去的消息會被最終消費掉。
消費者對列是消費者連接之後（或者之前有連接過）才創建的。我們將原生的消費者標識由 {IP}@{消費者group}擴展爲 {IP}@{消費者group}{topic}{tag}，（例如 xxx.xxx.xxx.xxx@mqtest_producer-group_2m2sTest_tag-zyk ）。任何一個元素不同，都認爲是不同的消費端，每個消費端會擁有一份自己消費對列（默認是broker對列數量*broker數量）。新掛載的消費者對列中擁有commitlog中的所有數據。
消費模式（**在默認情況下，就是集羣消費 **CLUSTERING）
-
廣播消費 BROADCASTING
類似於ActiveMQ中的發佈訂閱模式，一條消息被多個consumer消費，即使這些consumer屬於同一個ConsumerGroup,消息也會被ConsumerGroup中的每個Consumer都消費一次，廣播消費中ConsumerGroup概念可以認爲在消息劃分方面無意義。
-
集羣消費 CLUSTERING （默認）
一個ConsumerGroup中的Consumer實例分攤消費消息，實現了天然的消息負載均衡。例如某個Topic有9條消息，其中一個ConsumerGroup有3個實例（可能是3個進程，或者3臺機器），那麼每個實例只消費其中部分，消費完的消息不能被其他實例消費。默認的分配算法是AllocateMessageQueueAveragely
消息原語
冪等 ：RocketMQ使用的消息原語是At Least Once，所以consumer可能多次收到同一個消息，此時務必做好冪等
安裝
本文介紹源碼編譯安裝
downlaod source
下載rocketMq source 地址 點我
下載源碼後配置編譯環境 編譯需要 jdk 和 maven 3.2.x
好環境後，開始解壓編譯源碼，編譯用時較長，因爲需要下載一些依賴
> unzip rocketmq-all-4.x.0-source-release.zip
> cd rocketmq-all-4.x..0/
> mvn -Prelease-all -DskipTests clean install -U
> cd distribution/target/apache-rocketmq
啓動
nohup sh bin/mqnamesrv &
tail -f ~/logs/rocketmqlogs/namesrv.log
nohup sh bin/mqbroker -n localhost:9876 &
tail -f ~/logs/rocketmqlogs/broker.log
停止
sh bin/mqshutdown broker
sh bin/mqshutdown namesrv
常用命令
rocketMq添加主題命令 該命令執行會在broker所在機器創建一個新的topic，若topic已存在，則會更新topic的屬性
sh mqadmin updateTopic -n localhost:9876 -b localhost:10911 -t orderTopic
deleteTopic
從Broker和Name Server刪除Topic
sh mqadmin deleteTopic -t TopicTest -c DefaultCluster -n 192.168.0.1:9876
查詢name server 的topic list
sh mqadmin topicList -n localhost:9876
更多命令查看
https://blog.csdn.net/gwd1154978352/article/details/80829534
code
代碼地址如下：點我
目前只有鏈接原生rocketMq 的代碼，日後會添加連接 阿里rocketmq 的代碼畢竟現在大家都用阿里雲
參考：
https://www.jianshu.com/p/2838890f3284
https://www.jianshu.com/p/84ab3a7e4b91
https://blog.csdn.net/u014427391/article/details/78343163
