Broker
消息中轉角色，負責存儲消息，轉發消息，一般也稱Server。在 JMS規范中稱為 Provider。RocketMQ一般在多個服務器部署broker集群，從而達到分布式、高可用、可橫向擴展的目的。
Name Server
Name Server是一個幾乎無狀態節點，可集群部署，節點之間無同步信息。它主要提供broker注冊、Topic路由管理等功能。
Topic
在RocketMQ中，topic類似于JMS規范中的隊列，所有消息都是存放在不同的topic中，生產者與消費者都以topic名字進行生產與消費。(注：RocketMQ的topic并不是jms規范中廣播消費topic的概念)。
一個Topic可以存在多個broker之中，這樣topic就可以分布在不同的broker從而達到分布式的目的。
一個Topic下面，可以有多個隊列，可以理解成分區，Topic的消息是放在不同隊列下的。
Queue
在RocketMQ中，queue是存放數據的最小單位，queue是存在于topic下面的。在RocketMQ中，queue不同于JMS規范中的隊列，可以理解為topic的分區。
生產組
一類Producer的集合名稱，這類Producer通常發送一類消息，且發送邏輯一致，一般由業務系統負責產生消息。
消費組
一類Consumer的集合名稱，這類Consumer通常消費一類消息，且消費邏輯一致，一般是后臺系統負責異步消費。消費進度由存儲在消費組上。
消費者實例
一個消費者實例代表消費組的一員，不同的消費者用不同的實例名字創建。
生產者實例
一個生產者實例代表生產者的一員，不同的生產者用不同的實例名字創建。
PUSH消費
Consumer的一種，應用通常向Consumer對象注冊一個Listener接口，一旦收到消息，Consumer對象立刻回調Listener接口方法。在RocketMQ中，客戶端會自動起線程消費消息，線程數是5-64，意味著，listener里面的方法，會被多線程執行。客戶端內部可以根據堆積量進行調整，使用者不需要新啟、管理消費線程。并有流控機制，當客戶端緩存一定量消費不及時，會停止推送新消息。
PULL消費
Consumer的一種，應用通常主動調用Consumer的拉消息方法從Broker拉消息，主動權由應用控制，但實時性取決于應用主動拉取的頻率。在PULL消費中，線程由應用自主決定。
廣播消費
注意：使用消費模式，在很多使用場景都會帶來影響或限制，在RocketMQ中，應盡量避免使用此消費模式。在RocketMQ中，消費者有兩種不同的方式消費topic中的消息，其中一種是廣播消費。在廣播消費模式下，一條消息被多個Consumer消費，即使這些Consumer屬于同一個Consumer Group，消息也會被Consumer Group中的每個Consumer都消費一次，廣播消費中的Consumer Group概念可以認為在消息劃分方面無意義。V1.x版本由于廣播消費的消費進度，是保存在客戶端的，對于很多使用場景會帶來影響，在RocketMQ中，并不推薦使用此消費模式。
集群消費
一個Topic可以被一個或多個Consumer Group消費，每個Consumer Group有自己獨立的消費進度，消費進度是保存在服務端的。一個Consumer Group中的消費者實例可以平均分攤消費消息，做到負載均衡。例如某個Topic有9條消息，其中一個Consumer Group有3個不同的消費者實例（可能是3個進程，或者3臺機器），那么每個實例只消費其中的3條消息。在此消費模式下，可以做到Point-To-Point的消費，也可以做到JMS里面廣播消費，能滿足絕大部分場景，推薦使用此消費模式。
有序消息
消費消息的順序要同發送消息的順序一致，在RocketMQ中，主要有兩種有序消息。
普通有序消息
有序消息的一種，在正常情況下可以保證完全的順序消息，但是一旦發生通信異常，Broker重啟，由于隊列總數發生變化，哈希取模后定位的隊列會變化，產生短暫的消息順序不一致。如果業務能容忍在集群異常情況（如某個Broker宕機或者重啟）下，消息短暫的亂序，使用普通順序方式比較合適。
嚴格有序消息
有序消息的一種。無論正常異常情況都能保證順序，但是犧牲了分布式Failover特性，即Broker集群中只要有一臺機器不可用，則整個集群都不可用（或者影響hash值對應隊列的使用），服務可用性大大降低。如果服務器部署為同步雙寫模式，此缺陷可通過備機自動切換為主避免，不過仍然會存在幾分鐘的服務不可用。若業務能容忍短暫亂序，推薦普通有序消費。
