1、介紹

消息中間件是指在分布式系統(tǒng)中完成消息的發(fā)送和接收的基礎(chǔ)軟件。
消息中間件也可以稱消息隊(duì)列（Message Queue / MQ），互聯(lián)網(wǎng)場(chǎng)景中經(jīng)常使用消息中間件進(jìn)行消息路由、訂閱發(fā)布、異步處理等操作，來緩解系統(tǒng)的壓力。
引入消息隊(duì)列主要是為了解決如下問題的：

• 解耦 ：如訂單系統(tǒng)，可以通過消息隊(duì)列把削減庫存的工作交給庫存系統(tǒng)去處理，而不用等實(shí)時(shí)響應(yīng)。
• 執(zhí)行有序性：先進(jìn)先出原理，按照進(jìn)入消息隊(duì)列的順序處理業(yè)務(wù)事件。
• 消息路由 ：按照不同的規(guī)則，將隊(duì)列中消息發(fā)送到不同的業(yè)務(wù)服務(wù)中。
• 異步處理 ：將一些無需實(shí)時(shí)響應(yīng)結(jié)果的計(jì)算放到異步中，提升系統(tǒng)的吞吐率。
• 削峰 ：將峰值期間的操作削減，比如整個(gè)操作流程包含12個(gè)步驟，后11個(gè)步驟非強(qiáng)關(guān)注結(jié)果的數(shù)據(jù)，可以放在消息隊(duì)列中。

既然本身就是為了解決大流量場(chǎng)面而設(shè)計(jì)的，那他自身的穩(wěn)定性、健壯性就顯的無比重要，下面我們來看看消息隊(duì)列怎么去保證可用性的。

2、消息隊(duì)列的基本構(gòu)成

分析高可用特性前先復(fù)習(xí)下消息隊(duì)列的基本組件，無論是哪一種類型的消息隊(duì)列，基本都包含以下構(gòu)成：

• Broker：消息服務(wù)器，以服務(wù)的形式運(yùn)行在server端，給各個(gè)業(yè)務(wù)系統(tǒng)提供核心消息數(shù)據(jù)的中轉(zhuǎn)服務(wù)。
• Producer：消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給broker。
• Consumer：消息消費(fèi)者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理
• Topic：主題模塊，發(fā)布/訂閱模式下的消息統(tǒng)一匯集地，不同生產(chǎn)者向topic發(fā)送消息，由MQ服務(wù)器分發(fā)到不同的訂閱者，實(shí)現(xiàn)消息的廣播
• Queue：隊(duì)列，PTP模式下，特定生產(chǎn)者向特定queue發(fā)送消息，消費(fèi)者訂閱特定的queue完成指定消息的接收。
• Message：消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)消息的傳輸。

上圖中以kafka為例子，這是典型的集群模式，Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance。Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費(fèi)消息。

• producer 負(fù)責(zé)生產(chǎn)消息
• consumer 負(fù)責(zé)消費(fèi)消息
• broker 消息服務(wù)器，提供消息核心的處理工作
• zookeeper 用于生產(chǎn)者和消費(fèi)者的注冊(cè)與發(fā)現(xiàn)

3 高可用性架構(gòu)保證

了解了一個(gè)消息隊(duì)列的構(gòu)成之后，我們來看看這種結(jié)構(gòu)是怎么保障高可用性的。
首先，高可用是指系統(tǒng)的出錯(cuò)概率和無故障運(yùn)行時(shí)長(zhǎng)，從消息隊(duì)列角度出發(fā)，至少要保證一下幾點(diǎn)：

• 低消息丟失率：消息可靠性也是衡量消息中間件好壞的一個(gè)關(guān)鍵因素，尤其是在金融支付領(lǐng)域，消息可靠性尤為重要。
• 低故障率：消息中間件的可用性是指無故障運(yùn)行的時(shí)間百分比，通常用幾個(gè) 9 來衡量，如 99.99% 就是一個(gè)不錯(cuò)的指標(biāo)。
• 多副本容錯(cuò)能力：一般會(huì)要求多副本及強(qiáng)一致性，多副本可以保證在 master 節(jié)點(diǎn)宕機(jī)異常之后可以提升 slave 作為新的 master 而繼續(xù)提供服務(wù)來保障可用性。

3.1 RocketMQ

以為RocketMQ為例，集群模式如下：

• 多master 模式
• 多master多slave異步復(fù)制模式-
• 多 master多slave同步雙寫模式。
• Name Service 集群： RocketMQ 的 "中央大腦 " ， RocketMQ 的服務(wù)注冊(cè)中心，集群模式確保它的可用性。
• Produer 集群
• Consumer 集群：避免單例的消費(fèi)服務(wù)故障導(dǎo)致消息堆積。
  多master 多slave模式部署架構(gòu)圖：

Producer 與 NameServer集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)或者RR選擇）建立長(zhǎng)連接，定期從 NameServer 獲取 Topic 路由信息，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。

3.2 Kafka

Kafka集群中包含如下組成部分：

• 幾個(gè)消息生產(chǎn)者Producer（可以是業(yè)務(wù)的Web程序、定時(shí)任務(wù)服務(wù)，其他下游服務(wù)的請(qǐng)求等）
• 一個(gè)broker組（Kafka支持橫向擴(kuò)展，一般來說broker數(shù)量越多，集群吞吐率越高）
• 一個(gè)消費(fèi)組 Consumer Group，在資源充足的情況下，消費(fèi)者越多，消費(fèi)效率越高，性能也就越好
• 一個(gè)Zookeeper集群：保證消費(fèi)者和生產(chǎn)者的注冊(cè)和訂閱，避免業(yè)務(wù)之間的耦合，也提高了可用性。
  兩個(gè)關(guān)鍵點(diǎn)：

Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance。

Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費(fèi)消息。