rocketmq中有很多概念，其中包括一些術語和角色。
理清楚基本的概念能有效的幫助理解rocketmq的原理以及排查問題。
生產者。傳送訊息的客戶端角色。傳送訊息的時候需要指定topic。
消費者。消費訊息的客戶端角色。通常是後台處理非同步消費的系統。 rocketmq中consumer有兩種實現：pushconsumer和pullconsumer。
pushconsumer
推送模式（雖然rocketmq使用的是長輪詢）的消費者。訊息的能及時被消費。使用非常簡單，內部已處理如執行緒池消費、流控、負載均衡、異常處理等等的各種場景。
pullconsumer
拉取模式的消費者。應用主動控制拉取的時機，怎麼拉取，怎麼消費等。主動權更高。但要自己處理各種場景。
標識傳送同一類訊息的producer，通常傳送邏輯一致。傳送普通資訊的時候，僅標識使用，並無特別用處。若事務訊息，如果某條傳送某條訊息的producer-a宕機，使得事務訊息一直處於prepared狀態並超時，則broker會回查同乙個group的其 他producer，確認這條訊息應該commit還是rollback。但開源版本並不支援事務訊息。
標識一類consumer的集合名稱，這類consumer通常消費一類訊息，且消費邏輯一致。同乙個consumer group下的各個例項將共同消費topic的訊息，起到負載均衡的作用。
消費進度以consumer group為粒度管理，不同consumer group之間消費進度彼此不受影響，即訊息a被consumer group1消費過，也會再給consumer group2消費。
注： rocketmq要求同乙個consumer group的消費者必須要擁有相同的註冊資訊，即必須要聽一樣的topic(並且tag也一樣)。
標識一類訊息的邏輯名字，訊息的邏輯管理單位。無論訊息生產還是消費，都需要指定topic。
rocketmq支援給在傳送的時候給topic打tag，同乙個topic的訊息雖然邏輯管理是一樣的。但是消費topic1的時候，如果你訂閱的時候指定的是taga，那麼tagb的訊息將不會投遞。
簡稱queue或q。訊息物理管理單位。乙個topic將有若干個q。若topic同時建立在不通的broker，則不同的broker上都有若干q，訊息將物理地儲存落在不同broker結點上，具有水平擴充套件的能力。
無論生產者還是消費者，實際的生產和消費都是針對q級別。例如producer傳送訊息的時候，會預先選擇（預設輪詢）好該topic下面的某一條q地傳送；consumer消費的時候也會負載均衡地分配若干個q，只拉取對應q的訊息。
每一條message queue均對應乙個檔案，這個檔案儲存了實際訊息的索引資訊。並且即使檔案被刪除，也能通過實際純粹的訊息檔案（commit log）恢復回來。
rocketmq中，有很多offset的概念。但通常我們只關心暴露到客戶端的offset。一般我們不特指的話，就是指邏輯message queue下面的offset。
注： 邏輯offset的概念在rocketmq中字面意思實際上和真正的意思有一定差別，這點在設計上顯得有點混亂。祥見下面的解釋。
可以認為一條邏輯的message queue是無限長的陣列。一條訊息進來下標就會漲1,而這個陣列的下標就是offset。
max offset
字面上可以理解為這是標識message queue中的max offset表示訊息的最大offset。但是從原始碼上看，這個offset實際上是最新訊息的offset+1，即：下一條訊息的offset。
min offset：
標識現存在的最小offset。而由於訊息儲存一段時間後，消費會被物理地從磁碟刪除，message queue的min offset也就對應增長。這意味著比min offset要小的那些訊息已經不在broker上了，無法被消費。
consumer offset
字面上，可以理解為標記consumer group在一條邏輯message queue上，訊息消費到**即消費進度。但從原始碼上看，這個數值是消費過的最新消費的訊息offset+1，即實際上表示的是下次拉取的offset位置。
消費者拉取訊息的時候需要指定offset，broker不主動推送訊息， offset的訊息返回給客戶端。
consumer剛啟動的時候會獲取持久化的consumer offset，用以決定從**開始消費，consumer以此發起第一次請求。
每次訊息消費成功後，這個offset在會先更新到記憶體，而後定時持久化。在集群消費模式下，會同步持久化到broker，而在廣播模式下，則會持久化到本地檔案。
消費者的一種消費模式。乙個consumer group中的各個consumer例項分攤去消費訊息，即一條訊息只會投遞到乙個consumer group下面的乙個例項。
實際上，每個consumer是平均分攤message queue的去做拉取消費。例如某個topic有3條q，其中乙個consumer group 有 3 個例項（可能是 3 個程序，或者 3 臺機器），那麼每個例項只消費其中的1條q。
而由producer傳送訊息的時候是輪詢所有的q,所以訊息會平均散落在不同的q上，可以認為q上的訊息是平均的。那麼例項也就平均地消費訊息了。
這種模式下，消費進度的儲存會持久化到broker。
消費者的一種消費模式。訊息將對乙個consumer group下的各個consumer例項都投遞一遍。即即使這些 consumer 屬於同乙個consumer group，訊息也會被consumer group 中的每個consumer都消費一次。
實際上，是乙個消費組下的每個消費者例項都獲取到了topic下面的每個message queue去拉取消費。所以訊息會投遞到每個消費者例項。
這種模式下，消費進度會儲存持久化到例項本地。
消費訊息的順序要同傳送訊息的順序一致。由於consumer消費訊息的時候是針對message queue順序拉取並開始消費，且一條message queue只會給乙個消費者（集群模式下），所以能夠保證同乙個消費者例項對於q上訊息的消費是順序地開始消費（不一定順序消費完成，因為消費可能並行）。
在rocketmq中，順序消費主要指的是都是queue級別的區域性順序。這一類訊息為滿足順序性，必須producer單執行緒順序傳送，且傳送到同乙個佇列，這樣consumer就可以按照producer傳送的順序去消費訊息。
生產者傳送的時候可以用messagequeueselector為某一批訊息（通常是有相同的唯一標示id）選擇同乙個queue，則這一批訊息的消費將是順序訊息（並由同乙個consumer完成訊息）。或者message queue的數量只有1，但這樣消費的例項只能有乙個，多出來的例項都會空跑。
順序訊息的一種，正常情況下可以保證完全的順序訊息，但是一旦發生異常，broker宕機或重啟，由於佇列總數發生髮化，消費者會觸發負載均衡，而預設地負載均衡演算法採取雜湊取模平均，這樣負載均衡分配到定位的佇列會髮化，使得佇列可能分配到別的例項上，則會短暫地出現訊息順序不一致。
如果業務能容忍在集群異常情況（如某個 broker 宕機或者重啟）下，訊息短暫的亂序，使用普通順序方式比較合適。
順序訊息的一種，無論正常異常情況都能保證順序，但是犧牲了分布式 failover 特性，即 broker集群中只要有一台機器不可用，則整個集群都不可用，服務可用性大大降低。
如果伺服器部署為同步雙寫模式，此缺陷可通過備機自動切換為主避免，不過仍然會存在幾分鐘的服務不可用。（依賴同步雙寫，主備自動切換，自動切換功能目前並未實現）
目前已知的應用只有資料庫 binlog 同步強依賴嚴格順序訊息，其他應用絕大部分都可以容忍短暫亂序，推薦使用普通的順序訊息
RocketMQ 術語詳解（通俗易懂）
rocketmq中有很多概念，其中包括一些術語和角色。理清楚基本的概念能有效的幫助理解rocketmq的原理以及排查問題。生產者。傳送訊息的客戶端角色。傳送訊息的時候需要指定topic。消費者。消費訊息的客戶端角色。通常是後台處理非同步消費的系統。rocketmq中consumer有兩種實現 pus...
RocketMQ 是什麼 專業術語
github 上關於 rocketmq 的介紹 rcoketmq 是一款低延遲 高可靠 可伸縮 易於使用的訊息中介軟體。具有以下特性 支援發布 訂閱 pub sub 和點對點 p2p 訊息模型 在乙個佇列中可靠的先進先出 fifo 和嚴格的順序傳遞 支援拉 pull 和推 push 兩種訊息模式 單...
RocketMQ命令使用詳解
nohup sh mqnamesrv usr local rocketmq apache rocketmq all logs mqnamesrv.log 2 1 545 nohup sh mqbroker autocreatetopicenable true c usr local rocketmq...