消息的順序消費在很多交易型的業務場景中都會被要求實現，而且，消息隊列的順序消費解決方案在很多互聯網公司的面試中經常會被問到。

　　在使用了多個消息隊列后發現，雖然每個消息隊列都有各自的順序消費解決方案，但是RocketMQ經過了多年電商的洗禮，其功能性的要求，已經設計的非常全面。這樣的全面可以通過RocketMQ消息模型的架構設計得以體現。我們看看RocketMQ是怎么解決消息的順序消費。

　　一、RocketMQ的消息模型

　　1.技術架構

　　RocketMQ架構上主要分為四部分，如上圖所示:

　　NameServer：NameServer是一個非常簡單的Topic路由注冊中心，其角色類似Dubbo中的zookeeper，支持Broker的動態注冊與發現。主要包括兩個功能：Broker管理，NameServer接受Broker集群的注冊信息并且保存下來作為路由信息的基本數據。然后提供心跳檢測機制，檢查Broker是否還存活;路由信息管理，每個NameServer將保存關于Broker集群的整個路由信息和用于客戶端查詢的隊列信息。然后Producer和Conumser通過NameServer就可以知道整個Broker集群的路由信息，從而進行消息的投遞和消費。NameServer通常也是集群的方式部署，各實例間相互不進行信息通訊。Broker是向每一臺NameServer注冊自己的路由信息，所以每一個NameServer實例上面都保存一份完整的路由信息。當某個NameServer因某種原因下線了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以動態感知Broker的路由的信息。

　　Producer：消息的發布者，支持分布式集群方式部署。消息發布者通過消息隊列的負載均衡模塊選擇相應的Broker集群進行消息投遞，投遞的過程低延遲并且支持快速失敗。

　　Consumer：消息的消費者，支持分布式集群方式部署。RocketMQ同時支持push推和pull拉的兩種消息消費模式。消息消費者也支持集群和廣播兩種消費方式，同時提供了實時消息的訂閱機制，滿足大多數用戶的需求。

　　BrokerServer：Broker主要負責消息的存儲、投遞和查詢以及服務高可用保證，為了實現這些功能，Broker包含了以下幾個重要子模塊。

　　Remoting Module：整個Broker的實體，負責處理來自clients端的請求。

　　Client Manager：負責管理客戶端(Producer/Consumer)和維護Consumer的Topic訂閱信息。

　　Store Service：提供方便簡單的API接口處理消息存儲到物理硬盤和查詢功能。

　　HA Service：高可用服務，提供Master Broker 和 Slave Broker之間的數據同步功能。

　　Index Service：根據特定的Message key對投遞到Broker的消息進行索引服務，以提供消息的快速查詢。

　　2. 部署架構

　　RocketMQ 網絡部署特點

　　NameServer是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。

　　Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave 的對應關系通過指定相同的BrokerName，不同的BrokerId 來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與NameServer集群中的所有節點建立長連接，定時注冊Topic信息到所有NameServer。注意：當前RocketMQ版本在部署架構上支持一Master多Slave，但只有BrokerId=1的從服務器才會參與消息的讀負載。

　　Producer與NameServer集群中的其中一個節點(隨機選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic 服務的Master建立長連接，且定時向Master發送信息。Producer完全無狀態，可集群部署。

　　Consumer與NameServer集群中的其中一個節點(隨機選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送信息。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，消費者在向Master拉取消息時，Master服務器會根據拉取偏移量與最大偏移量的距離(判斷是否讀老消息，產生讀I/O)，以及從服務器是否可讀等因素建議下一次是從Master還是Slave拉取。

　　結合部署架構圖，描述集群工作流程：

　　啟動NameServer，NameServer起來后監聽端口，等待Broker、Producer、Consumer連上來，相當于一個路由控制中心。

　　Broker啟動，跟所有的NameServer保持長連接，定時發送心跳包。心跳包中包含當前Broker信息(IP+端口等)以及存儲所有Topic信息。注冊成功后，NameServer集群中就有Topic跟Broker的映射關系。

　　收發消息前，先創建Topic，創建Topic時需要指定該Topic要存儲在哪些Broker上，也可以在發送消息時自動創建Topic。

　　Producer發送消息，啟動時先跟NameServer集群中的其中一臺建立長連接，并從NameServer中獲取當前發送的Topic存在哪些Broker上，輪詢從隊列列表中選擇一個隊列，然后與隊列所在的Broker建立長連接從而向Broker發消息。

　　Consumer跟Producer類似，跟其中一臺NameServer建立長連接，獲取當前訂閱Topic存在哪些Broker上，然后直接跟Broker建立連接通道，開始消費消息。

　　二、順序消息的應用場景

　　順序消費的應用場景有很多，無論是在面試，或是實際生產環境中要解決順序消費問題，都需要對消息隊列的應用場景有一定的理解。

　　1.AIOT中消息的順序消費

　　比如有這么一個物聯網的應用場景，IOT中的設備在初始化時需要按順序接收這樣的消息：

　　操作1:設置設備名稱

　　操作2:設置設備的網絡

　　操作3:重啟設備使配置生效

　　如果這個順序顛倒了，可能就沒有辦法讓設備的配置生效，因為只有重啟設備才能讓配置生效，但重啟的消息卻在設置設備消息之前被消費。

　　2.用戶服務中的順序消費

　　應用為了提高用戶粘合度，往往通過積分制度提供用戶活躍度。比如接下來有這一系列的場景：

　　操作1:新注冊用戶，將用戶積分設置為10分。

　　操作2:獎勵行為，比如用戶完善了個人信息，則積分+5分。

　　操作3:懲罰行為，比如用戶發表違規言論，則積分-3分。

　　如果上述的操作是順序進行的，則用戶積分為12分。如果上述操作的步驟順序發生了變化，比如消費者先消費了操作2的消息，再消費操作1和3的消息，則分數變為7分，此時就出現了因為亂序消費導致的錯誤結果。

　　三、如何實現順序消息

　　順序消息要求消費者消費消息的順序按照發送者發送消息的順序執行。RocketMQ中實現的消息順序有兩個維度，分別是局部有序和全局有序。

　　1.局部有序

　　局部消息指的是消費者消費某個topic的某個隊列中的消息是順序的。在圖上的八個隊列中，消費者可以隨機的消費這8個隊列，也就是說消費者不能保證消費隊列的順序。但是消費者在消費某一個隊列的時候，一定可以進行順序消費。也就是說，在消費者兩次訪問一個隊列中的消息時，一定是按照從左到右的順序依次消費消息。所以針對于某一個隊列來講，消費是順序的。但如果把問題定位在整個隊列中時，不同的消息在不同的隊列中，又不能保證消息的有序性，不如消息A到了隊列2，消息B到了隊列1，消費者先消費了隊列1再消費隊列2，就不能保證有序性。但如果消息C隨著消息B進入隊列1，那么消息C一定是在消息B之后被消費。

　　消費者使用MessageListenerOrderly類做消息監聽，實現局部順序。

　　2.全局有序

　　消費者消費全部消息都是順序的，只能通過一個某個topic只有一個隊列才能實現，這種應用場景較少，且性能較差。

　　3.亂序消費

　　消費者消費消息不需要關注消息的順序。消費者使用MessageListenerConcurrently類做消息監聽。