接上一篇的《什么是分布式消息中間件？》，這一篇來介紹一下消息中間件相關的一些概念和專業術語。
Topic
主題，從邏輯上講一個Topic就是一個Queue，即一個隊列；從存儲上講，一個Topic存儲了一類相同的消息，是一類消息的集合。比如一個名稱為trade.order.queue的Topic里面存的都是訂單相關的消息。
Partition
分區。分區是存在於服務端，內部保持順序、且順序不可變更的一個隊列，用於存儲消息。分區可能不應該出現在消息領域內，在使用消息中間件發送和消費時，實際上用戶是感受不到分區這個概念的。下面這幅圖便於大家去理解分區：
一個Topic存儲消息時會分為多個Partition，每個Partition內消息是有順序的。至於為什么需要將Topic划分成按照Partition存儲，在以后設計和實現部分會解釋。
Producer
生產者，消息的生產方，一般由業務系統負責產生消息。
Producer負責決定將消息發送到哪個Topic的那個Partition。
Consumer
消費者，消息的消費方，一般是后台系統負責異步消費消息。
Consumer訂閱Topic，消費Topic內部的消息。
Broker
消息的存儲者，一般也稱為Server，在JMS中叫Provider，在RocketMQ（阿里開源的消息中間件）中叫Broker。
NameServer
NameServer其實不是消息中間件的概念了，一般在分布式系統中都會有一個角色作為NameServer用於服務發現，在Kafka中使用ZooKeeper來實現，在RocketMQ中單獨寫了NameServer服務。
Group
Group用於標志Consumer的身份，擁有相同Group名稱的Consumer一般消費一類消息，且消費邏輯是相同的。
RocketMQ中Producer也需要Group標志身份，但是實際上Producer是不需要的。因為Producer之間是不相關的，Consumer之間是需要協同工作的。
這里多解釋一下為什么Consumer之間是需要協同工作的。
比如啟動了兩個Consumer來消費訂單消息，然后調用物流系統進行發貨。那么在產生一條訂單消息后，只能讓兩個Consumer中的一個來處理消息（否者就發貨兩次了）所以需要一個標識將這兩個Consumer標記為行為一致的。另一個場景是如果一個Consumer實例宕機了，這個時候需要有行為相同的Consumer去接管它的消費任務，那么就需要一個標識來標識行為相同的Consumer。
那是不是只要行為相同的Consumer只存在一個就好了呢？是的，如果只有行為一致的Consumer，那么就不存在系統工作，也可以不需要Group，每個Consumer擁有獨立的ID即可。但是實際系統是不可能的，從系統可用性和性能上都不可能（單個Consumer就有單點問題，也有性能問題，畢竟我們談的是分布式系統）。
集群消費
集群消費的含義是說一類Consumer（即Group相同的Consumer的集合）共同完成對一個Topic的消費。其實上面說明Consumer需要協同工作時舉例中就默認是集群消費了，這也是現實業務中95%以上需求的消費方式。
具體來看集群消費模式如下：
Consumer0和Consumer1屬於同一個Group，假設Topic中有0~5共6條消息，Consumer0消費到0~2，Consumer1消費到3~5，它們共同完成了Topic中消息的消費。
這存在於大量的無狀態的后台系統中，就如上面說的消費訂單消息進行發貨的例子。
廣播消費
廣播消費的含義是Topic中的每一條消息都會被一類Consumer（屬於同一個Group的多個Consumer）中的每個Consumer實例消費。
如下圖，Topic總的0~5共6條消費，Consumer0會消費到0~5完整的6條消息，Consumer1也會消費到0~5的6條消息。
這種消費往往應用在有狀態的服務，比如緩存服務器去消費消息更新自己的緩存數據，那么每一台緩存服務器都需要拿到消息。
結語
了解什么是分布式消息中間件和消息中間件的一些概念之后，下一篇計划談一談分布式消息中間件的需求，畢竟要有的放矢，明確需求才能知道要做什么，怎么做才合適。
歡迎關注此公眾號，將長期發布和分布式消息中間件相關的技術內容。當然如果需要私下交流，也可以加通過留言或信息的方式加作者微信。
PS：為什么本文開頭會用一張Kafka的Logo呢？因為Kafka真的是一個非常優秀的軟件，文中一些概念也來源於Kafka（如果對消息中間件有興趣，強烈建議去看看Kafka的文檔和實現）。