是壹個隊列模型的消息中間件，具有高性能、高可靠、高實時、分布式特點。
實例消費這個 Topic 對應的所有隊列，如果做集群消費，則多個 Consumer 實例平均消費這個 topic 對應的隊列集合。
RocketMQ 網絡部署特點
1）高並發讀寫服務
Broker的高並發讀寫主要是依靠以下兩點：
2） 負載均衡與動態伸縮
負載均衡 ：Broker上存Topic信息，Topic由多個隊列組成，隊列會平均分散在多個Broker上，而Producer的發送機制保證消息盡量平均分布到所有隊列中，最終效果就是所有消息都平均落在每個Broker上。
動態伸縮能力（非順序消息） ：Broker的伸縮性體現在兩個維度：Topic, Broker。
3） 高可用&高可靠
高可用：集群部署時壹般都為主備，備機實時從主機同步消息，如果其中壹個主機宕機，備機提供消費服務，但不提供寫服務。
高可靠：所有發往broker的消息，有同步刷盤和異步刷盤機制；同步刷盤時，消息寫入物理文件才會返回成功，異步刷盤時，只有機器宕機，才會產生消息丟失，broker掛掉可能會發生，但是機器宕機崩潰是很少發生的，除非突然斷電
4）Broker與Namesrv的心跳機制
單個Broker跟所有Namesrv保持心跳請求，心跳間隔為30秒，心跳請求中包括當前Broker所有的Topic信息。Namesrv會反查Broer的心跳信息，如果某個Broker在2分鐘之內都沒有心跳，則認為該Broker下線，調整Topic跟Broker的對應關系。但此時Namesrv不會主動通知Producer、Consumer有Broker宕機。
消費者啟動時需要指定Namesrv地址，與其中壹個Namesrv建立長連接。消費者每隔30秒從nameserver獲取所有topic的最新隊列情況，這意味著某個broker如果宕機，客戶端最多要30秒才能感知。連接建立後，從namesrv中獲取當前消費Topic所涉及的Broker，直連Broker。
Consumer跟Broker是長連接，會每隔30秒發心跳信息到Broker。Broker端每10秒檢查壹次當前存活的Consumer，若發現某個Consumer 2分鐘內沒有心跳，就斷開與該Consumer的連接，並且向該消費組的其他實例發送通知，觸發該消費者集群的負載均衡。
消費者端的負載均衡
先討論消費者的消費模式，消費者有兩種模式消費：集群消費，廣播消費。
消費者端的負載均衡，就是集群消費模式下，同壹個ID的所有消費者實例平均消費該Topic的所有隊列。
Producer啟動時，也需要指定Namesrv的地址，從Namesrv集群中選壹臺建立長連接。如果該Namesrv宕機，會自動連其他Namesrv。直到有可用的Namesrv為止。
生產者每30秒從Namesrv獲取Topic跟Broker的映射關系，更新到本地內存中。再跟Topic涉及的所有Broker建立長連接，每隔30秒發壹次心跳。在Broker端也會每10秒掃描壹次當前註冊的Producer，如果發現某個Producer超過2分鐘都沒有發心跳，則斷開連接。
生產者端的負載均衡
生產者發送時，會自動輪詢當前所有可發送的broker，壹條消息發送成功，下次換另外壹個broker發送，以達到消息平均落到所有的broker上。
這裏需要註意壹點：假如某個Broker宕機，意味生產者最長需要30秒才能感知到。在這期間會向宕機的Broker發送消息。當壹條消息發送到某個Broker失敗後，會往該broker自動再重發2次，假如還是發送失敗，則拋出發送失敗異常。業務捕獲異常，重新發送即可。客戶端裏會自動輪詢另外壹個Broker重新發送，這個對於用戶是透明的。
綁定hosts或dns：
主機命名說明：
在實際應用中都會涉及多環境的問題，比如有線下環境(dev)和生產環境(prod)，不同環境的應用最好保持配置壹致，減少各個每個環境的配置工作量。
Rocketmq各環境統壹連接地址 ：
NAMESRV_ADDR="nameserver1.rocketmq.test.com:9876;nameserver2.rocketmq.test.com:9876"
根據Rocketmq集群說明，其實最終只需暴露nameserver的地址給應用即可，因此，各個環境綁定各個環境對應的hosts/dns即可使用統壹連接的地址。
rocketmq各個組件都支持橫向擴容：
通過web可以查看集群狀態，查看topic信息以及創建更改topic，管理producer和consumer等。
用戶手冊： /apache/rocketmq-externals/blob/master/rocketmq-console/doc/1_0_0/UserGuide_CN.md