結合部署結構圖，描述集群工作流程：
1，啟動namesrv，namesrv起來後監聽埠，等待broker、produer、consumer連上來，相當於乙個路由控制中心。
2，broker啟動，跟所有的namesrv保持長連線，定時傳送心跳包。心跳包中包含當前broker資訊(ip+埠等)以及儲存所有topic資訊。註冊成功後，namesrv集群中就有topic跟broker的對映關係。
3，收發訊息前，先建立topic，建立topic時需要指定該topic要儲存在哪些broker上。也可以在傳送訊息時自動建立topic。
4，producer傳送訊息，啟動時先跟namesrv集群中的其中一台建立長連線，並從namesrv中獲取當前傳送的topic存在哪些broker上，然後跟對應的broker建長連線，直接向broker發訊息。
5，consumer跟producer類似。跟其中一台namesrv建立長連線，獲取當前訂閱topic存在哪些broker，然後直接跟broker建立連線通道，開始消費訊息。
就是乙個註冊中心，儲存當前集群所有brokers資訊、topic跟broker的對應關係。
namesrv用於儲存topic、broker關係資訊，功能簡單，穩定性高。多個namesrv之間相互沒有通訊，單台namesrv宕機不影響其他namesrv與集群；即使整個namesrv集群宕機，已經正常工作的producer，consumer，broker仍然能正常工作，但新起的producer, consumer，broker就無法工作。
namesrv壓力不會太大，平時主要開銷是在維持心跳和提供topic-broker的關係資料。但有一點需要注意，broker向namesr發心跳時，會帶上當前自己所負責的所有topic資訊，如果topic個數太多（萬級別），會導致一次心跳中，就topic的資料就幾十m，網路情況差的話，網路傳輸失敗，心跳失敗，導致namesrv誤認為broker心跳失敗。
nameserver是rocketmq自己實現的配置伺服器，不是zookeeper。
集群最核心模組，主要負責topic訊息儲存、管理和分發等功能。
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的連線，並且向該消費組的其他例項傳送通知，觸發該消費者集群的負載均衡。
消費者端的負載均衡
先討論消費者的消費模式，消費者有兩種模式消費：集群消費，廣播消費。
廣播消費：每個消費者消費topic下的所有佇列。
集群消費：乙個topic可以由同乙個id下所有消費者分擔消費。具體例子：假如topica有6個佇列，某個消費者id起了2個消費者例項，那麼每個消費者負責消費3個佇列。如果再增加乙個消費者id相同消費者例項，即當前共有3個消費者同時消費6個佇列，那每個消費者負責2個佇列的消費。
消費者端的負載均衡，就是集群消費模式下，同乙個id的所有消費者例項平均消費該topic的所有佇列。
但是consumer 數量要小於等於佇列數量，如果consumer 超過佇列數量，那麼多餘的consumer 將不能消費訊息。
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重新傳送，這個對於使用者是透明的。
RocketMQ架構原理
訊息模型。rocketmq主要由producer broker consumer三部分組成，其中producer負責生產訊息，consumer負責消費訊息，broker負責儲存訊息。broker在實際部署過程中對應一台伺服器，每個broker可以儲存多個topic的訊息，每個topic的訊息也可以分...
RocketMQ架構簡介
apache rocketmq是一款具有低延遲，高效能和可靠性，數十億容量和靈活可擴充套件性的分布式訊息傳遞和流 平台。它由四部分組成 name servers，brokers，producers和consumers。它們中的每乙個都可以在沒有單點故障的情況下進行水平擴充套件。name server...
RocketMQ集群架構與原理解析
rocketmq是一款分布式 佇列模型的訊息中介軟體，由阿里巴巴自主研發的一款適用於高併發 高可靠性 海量資料場景的訊息中介軟體。早期開源2.x版本名為metaq 15年迭代3.x版本，更名為rocketmq，16年開始貢獻到apache，經過1年多的孵化，最終成為apache頂級的開源專案，更新非...