我們在使用不同的消息隊列產品時，會遇到不同的“名詞”，今天我們今天來聊一些相關內容，包括隊列、主題、分區等。

消息隊列進化史

好的架構不是設計出來的，而是不斷演進得來的，消息隊列的發展歷史，也印證了這一點，消息隊列的消息模型主要包括兩類：

1. 隊列模型
2. 發佈-訂閱模型

隊列模型

最初的消息隊列就是一個嚴格意義上的隊列，它是一個先進先出（FIFO）的線性表，在具體實現時可以採用鏈表或者數組的形式，隊列只允許在後端進行插入操作，在前端進行刪除操作。

早期的消息隊列就是按照”隊列“的數據結構進行設計，其中生產者（Producer）發消息就是入隊操作，消費者（Consumer）收消息就是出隊操作。

如果有多個生產者向同一個隊列裡面發送消息，這個隊列中可以消費到的消息，就是這些生產者生產的所有消息的合集，消息的順序就是按照這些生產者發送消息的自然順序，如果有多個消費者接收同一個隊列的消息，這些消費者之間是競爭的關係，每個消費者只能收到隊列中的一部分消息，即任何一條消息只能被其中的一個消費者收到。

如果需要將一份消息發送到多個消費者，要求每個消費者都要收到全量消息，這時單個隊列就不能滿足需求，可以考慮針對每個消費者都建一個單獨的隊列，讓生產者發送多份，但是這樣做，就違背了消息隊列實現“服務解耦”的初衷。

發佈-訂閱模型

發佈-訂閱模型就是為瞭解決隊列模型中遇到的多個消費者都消費全量信息的問題。

在發佈-訂閱模型中，

• 消息的發送方稱作發佈者
• 消息的接收方稱作訂閱者
• 服務端存放消息的容器稱為主題

發佈者將消息發佈到主題中，訂閱者在接收消息之前需要先“訂閱主題”。

分佈-訂閱模型和隊列模型相比，生產者就是發佈者，消費者就是訂閱者，隊列就是主題，並沒有本質的區別，它們最大的區別在於，一份消息數據能不能被消費多次的問題。

在發佈-訂閱模型中，如果只有一個訂閱者，那它和隊列模型就基本一致了，即發佈-訂閱模型在功能層面上是可以相容隊列模型的。

常見消息隊列產品的設計模型

接下來我們看常用的消息隊列產品的隊列模型設計。

RabbitMQ

RabbitMQ是少數來在堅持使用隊列模型的產品之一，對於多個消費者的問題，它提供了Exchange模塊，位於生產者和消費者之間，生產者不關心將消息發給哪個隊列，而是將消息發給Exchange，由Exchange上配置的策略來決定將消息隊列發送到哪個隊列中。

同一份消息如果需要被多個消費者來消費，需要配置Exchange將消息發送到多個隊列，每個隊列中都存放一份完整的消息數據，可以為一個消費者提供消費服務。

RocketMQ

RocketMQ使用的消息模型是標準的發佈-訂閱模型。

幾乎所有的消息隊列都使用一種“請求-確認”機制，確保消息不會在傳遞過程中由於網路或者伺服器故障而丟失，具體做法：

1. 在生產端，生產者先將消息發送給伺服器，伺服器在收到消息並將其放入到主題或者隊列後，給生產者發送確認的響應。
2. 在消費端，消費者在收到消息並完成自己的業務邏輯後，給服務端發送消息消費成功的確認。

這個機制保證了消息在傳遞過程中的可靠性，但是引入這個機制後，為了確保消息的有序消費，在某一條消息被成功消費之前，下一條消息是不能被消費的。即每個主題在任意時刻，至多只能有一個消費者在消費，這也就沒有辦法水平擴展消費者的數量來提升消費端整體性能。

為瞭解決這個問題，RocketMQ引入了隊列的概念，在每個主題中包含多個隊列，通過多個隊列來實現多實例並行消費消息。RocketMQ只保證消息在隊列上是有序消費的，在主題層面是無法保證的。

RocketMQ的訂閱者是通過消費組來體現的，每個消費組都消費主題中的一份完整的消息，不同消費組之間的消費進度是相互隔離的，即一條消息被消費組1消費後，還會被消費組2消費。

消費組中有多個消費者，同一個組內的消費者是競爭的關係，每個消費者負責消費組內的一部分消息。如果一條消息被消費者1消費，那麼同一個消費組內的其他消費者沒有辦法再次消費這條消息。

為了維護多個消費組的不同的消息消費進度，RocketMQ會為每個消費組在每個隊列上都維護一個消費位置信息，即Offset。這個位置之前的消息都已經被消費，之後的消息都沒有被消費，沒成功消費一條消息，消費位置加一。

Kafka

Kafka也是採取發佈-訂閱模型。

Kafka和RocketMQ相比，消息模型是一樣的，區別在於RocketMQ中的“隊列”，在Kafka中，被替換成“分區”。