rocketmq主要由nameserver、broker、producer以及consumer四部分構成，如下圖所示
所有的集群都具有水平擴充套件能力，無單點障礙。
nameserver以輕量級的方式提供服務發現和路由功能，每個nameserver存有全量的路由資訊，提供對等的讀寫服務，支援快速擴縮容。
broker負責訊息儲存，以topic為緯度支援輕量級的佇列，單機可以支撐上萬佇列規模，支援訊息推拉模型，具備多副本容錯機制（2副本或3副本）、強大的削峰填谷以及上億級訊息堆積能力，同時可嚴格保證訊息的有序性。除此之外，broker還提供了同城異地容災能力，豐富的metrics統計以及告警機制。這些都是傳統訊息系統無法比擬的。
producer由使用者進行分布式部署，訊息由producer通過多種負載均衡模式傳送到broker集群，傳送低延時，支援快速失敗。
consumer也由使用者部署，支援push和pull兩種消費模式，支援集群消費和廣播訊息，提供實時的訊息訂閱機制，滿足大多數消費場景。
topic
topic表示訊息的第一級型別，比如乙個電商系統的訊息可以分為：交易訊息、物流訊息......
一條訊息必須有乙個topic。
tag
tag表示訊息的第二級型別，比如交易訊息又可以分為：交易建立訊息，交易完成訊息.....
一條訊息可以沒有tag。rocketmq提供2級訊息分類，方便大家靈活控制。
queue
乙個topic下，我們可以設定多個queue(訊息佇列)。當我們傳送訊息時，需要要指定該訊息的topic。rocketmq會輪詢該topic下的所有佇列，將訊息傳送出去。
producer與 producer group
producer表示訊息佇列的生產者。訊息佇列的本質就是實現了publish-subscribe模式，生產者生產訊息，消費者消費訊息。所以這裡的producer就是用來生產和傳送訊息的，一般指業務系統。
producer group是一類producer的集合名稱，這類producer通常傳送一類訊息，且傳送邏輯一致。
consumer與 consumer group
訊息消費者，一般由後台系統非同步消費訊息。
push consumer
consumer 的一種，應用通常向 consumer 物件註冊乙個 listener 介面，一旦收到訊息，consumer 物件立刻** listener 介面方法。
pull consumer
consumer 的一種，應用通常主動呼叫 consumer 的拉訊息方法從 broker 拉訊息，主動權由應用控制。
consumer group是一類consumer的集合名稱，這類consumer通常消費一類訊息，且消費邏輯一致。
broker
訊息的中轉者，負責儲存和**訊息。可以理解為訊息佇列伺服器，提供了訊息的接收、儲存、拉取和**服務。broker是rocketmq的核心，它不不能掛的，所以需要保證broker的高可用。
廣播消費
一條訊息被多個consumer消費，即使這些consumer屬於同乙個consumer group，訊息也會被consumer group中的每個consumer都消費一次。在廣播消費中的consumer group概念可以認為在訊息劃分方面無意義。
集群消費
乙個consumer group中的consumer例項平均分攤消費訊息。例如某個topic有 9 條訊息，其中乙個consumer group有 3 個例項(可能是 3 個程序,或者 3 臺機器)，那麼每個例項只消費其中的 3 條訊息。
nameserver
nameserver即名稱服務，兩個功能：
接收broker的請求，註冊broker的路由資訊
介面client的請求，根據某個topic獲取其到broker的路由資訊
nameserver沒有狀態，可以橫向擴充套件。每個broker在啟動的時候會到nameserver註冊；producer在傳送訊息前會根據topic到nameserver獲取路由(到broker)資訊；consumer也會定時獲取topic路由資訊。
1、消費過程要做到冪等（即消費端去重）
2、盡量使用批量方式消費方式，可以很大程度上提高消費吞吐量。
3、優化每條訊息消費過程
線上應該關閉autocreatetopicenable，即在配置檔案中將其設定為false。
rocketmq在傳送訊息時，會首先獲取路由資訊。如果是新的訊息，由於mqserver上面還沒有建立對應的topic，這個時候，如果上面的配置開啟的話，會返回預設topic的（rocketmq會在每台broker上面建立名為tbw102的topic）路由資訊，然後producer會選擇一台broker傳送訊息，選中的broker在儲存訊息時，發現訊息的topic還沒有建立，就會自動建立topic。後果就是：以後所有該topic的訊息，都將傳送到這台broker上，達不到負載均衡的目的。
所以基於目前rocketmq的設計，建議關閉自動建立topic的功能，然後根據訊息量的大小，手動建立topic。
RocketMQ 客戶端最佳實踐
本文站在消費者和生產者的角度給出一些rocketmq客戶端使用的實踐意見。乙個應用盡可能用乙個topic，訊息子型別用tags來標識，tags可以由應用自由設定。只有傳送訊息設定了tags，消費方在訂閱訊息時，才可以利用tags在broker做訊息過濾。message.settags taga 每個...
最佳實踐 Flutter 最佳實踐
最佳實踐是乙個領域可以接受的專業標準，對於任何程式語言來說，提高 質量 可讀性 可維護性和健壯性都非常重要。讓我們探索一些設計和開發flutter應用程式的最佳實踐。class enum typedef和extension應採用駝峰命名uppercamelcase規則。class mainscree...
RocketMQ消費者實踐
最近工作中用到了rocketmq，現記錄下，如何正確實現消費 防止重複消費 如何快速消費 消費失敗如何處理 重複消費會造成資料不一致等問題。所以，消費者要做到消費冪等。1 每次消費，記錄messageid 如果再次消費該message，查詢messageid是否已存在，已存在，就跳過消費 2 使用具...