消息隊列作為系統(tǒng)解耦，流量控制的利器，成為分布式系統(tǒng)核心組件之一。

如果你對消息隊列背后的實現(xiàn)原理關(guān)注不多，其實了解消息隊列背后的實現(xiàn)非常重要。

不僅知其然還要知其所以然，這才是一個優(yōu)秀的工程師需要具備的特征。

今天，我們就一起來探討設(shè)計一個消息隊列背后的技術(shù)。

消息隊列整體設(shè)計思路

主要是設(shè)計一個整體的消息被消費的數(shù)據(jù)流。

這里會涉及到：消息生產(chǎn)Producer、Broker(消息服務(wù)端)、消息消費者Consumer。

1.Producer(消息生產(chǎn)者)：發(fā)送消息到Broker。

2.Broker(服務(wù)端)：Broker這個概念主要來自于Apache的ActiveMQ，特指消息隊列的服務(wù)端。

主要功能就是：把消息從發(fā)送端傳送到接收端，這里會涉及到消息的存儲、消息通訊機制等。

3.Consumer(消息消費者)：從消息隊列接收消息，consumer回復(fù)消費確認(rèn)。

Broker(消息隊列服務(wù)端)設(shè)計重點

1）消息的轉(zhuǎn)儲：在更合適的時間點投遞，或者通過一系列手段輔助消息最終能送達消費機。

2）規(guī)范一種范式和通用的模式，以滿足解耦、最終一致性、錯峰等需求。

3）其實簡單理解就是一個消息轉(zhuǎn)發(fā)器，把一次RPC做成兩次RPC，發(fā)送者把消息投遞到broker，broker再將消息轉(zhuǎn)發(fā)一手到接收端。

總結(jié)起來就是兩次RPC加一次轉(zhuǎn)儲，如果要做消費確認(rèn)，則是三次RPC。

為了實現(xiàn)上述消息隊列的基礎(chǔ)功能：

1）消息的傳輸

2）存儲

3）消費

就需要涉及到如下三個方面的設(shè)計：

1）通信協(xié)議

2）存儲選擇

3）消費關(guān)系維護

通訊協(xié)議

消息Message:既是信息的載體，消息發(fā)送者需要知道如何構(gòu)造消息，消息接收者需要知道如何解析消息，它們需要按照一種統(tǒng)一的格式描述消息，這種統(tǒng)一的格式稱之為消息協(xié)議。

傳統(tǒng)的通信協(xié)議標(biāo)準(zhǔn)有XMPP和AMQP協(xié)議等，現(xiàn)在更多的消息隊列從性能的角度出發(fā)使用自己設(shè)計實現(xiàn)的通信協(xié)議。

1.JMS

JMS（Java MessageService）實際上是指JMS API。JMS是由Sun公司早期提出的消息標(biāo)準(zhǔn)，旨在為java應(yīng)用提供統(tǒng)一的消息操作，包括創(chuàng)建消息、發(fā)送消息、接收消息等。

JMS通常包含如下一些角色：

JMS提供了兩種消息模型：

1）點對點

2）以及publish-subscribe（發(fā)布訂閱）模型。

當(dāng)采用點對點模型時，消息將發(fā)送到一個隊列，該隊列的消息只能被一個消費者消費。

而采用發(fā)布訂閱模型時，消息可以被多個消費者消費。

在發(fā)布訂閱模型中，生產(chǎn)者和消費者完全獨立，不需要感知對方的存在。

2.AMQP

AMQP是 Advanced Message Queuing Protocol，即高級消息隊列協(xié)議。

AMQP不是一個具體的消息隊列實現(xiàn)，而 是一個標(biāo)準(zhǔn)化的消息中間件協(xié)議。

目標(biāo)是讓不同語言，不同系統(tǒng)的應(yīng)用互相通信，并提供一個簡單統(tǒng)一的模型和編程接口。 目前主流的ActiveMQ和RabbitMQ都支持AMQP協(xié)議。

AMQP是一種協(xié)議，更準(zhǔn)確的說是一種binary wire-level protocol（鏈接協(xié)議）。這是其和JMS的本質(zhì)差別，AMQP不從API層進行限定，而是直接定義網(wǎng)絡(luò)交換的數(shù)據(jù)格式。

JMS和AMQP比較

JMS: 只允許基于JAVA實現(xiàn)的消息平臺的之間進行通信

AMQP: AMQP允許多種技術(shù)同時進行協(xié)議通信

**3.Kafka的通信協(xié)議
**
Kafka的Producer、Broker和Consumer之間采用的是一套自行設(shè)計的基于TCP層的協(xié)議。Kafka的這套協(xié)議完全是為了Kafka自身的業(yè)務(wù)需求而定制的。

存儲選型

對于分布式系統(tǒng)，存儲的選擇有以下幾種

1）內(nèi)存

2）本地文件系統(tǒng)

3）分布式文件系統(tǒng)

4）nosql

5）DB

從速度上內(nèi)存顯然是最快的，對于允許消息丟失，消息堆積能力要求不高的場景(例如日志)，內(nèi)存會是比較好的選擇。

DB則是最簡單的實現(xiàn)可靠存儲的方案，很適合用在可靠性要求很高，最終一致性的場景(例如交易消息)，對于不需要100%保證數(shù)據(jù)完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇。

理論上，從速度來看，文件系統(tǒng)>分布式KV（持久化）>分布式文件系統(tǒng)>數(shù)據(jù)庫，而可靠性卻截然相反。

還是要從支持的業(yè)務(wù)場景出發(fā)作出最合理的選擇，如果你們的消息隊列是用來支持支付/交易等對可靠性要求非常高，但對性能和量的要求沒有這么高，而且沒有時間精力專門做文件存儲系統(tǒng)的研究，DB是最好的選擇。

對于不需要100%保證數(shù)據(jù)完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇，典型的比如 kafka的消息落地可以使用hadoop。

消費關(guān)系處理

現(xiàn)在我們的消息隊列初步具備了轉(zhuǎn)儲消息的能力。

下面一個重要的事情就是解析發(fā)送接收關(guān)系，進行正確的消息投遞了。

市面上的消息隊列定義了一堆讓人暈頭轉(zhuǎn)向的名詞，如JMS 規(guī)范中的Topic/Queue，Kafka里面的Topic/Partition/ConsumerGroup，RabbitMQ里面的Exchange等等。

拋開現(xiàn)象看本質(zhì)，無外乎是單播與廣播的區(qū)別。

所謂單播，就是點到點；而廣播，是一點對多點。

為了實現(xiàn)廣播功能，我們必須要維護消費關(guān)系，通常消息隊列本身不維護消費訂閱關(guān)系，可以利用zookeeper等成熟的系統(tǒng)維護消費關(guān)系，在消費關(guān)系發(fā)生變化時下發(fā)通知。

消息隊列需要支持高級特性

1.消息的順序
2.投遞可靠性保證
3.消息持久化
4.支持不同消息模型
5.多實例集群功能
6.事務(wù)特性等

除了上述的消息隊列基本功能以外，消息隊列在某些特殊的場景還需要支持事務(wù)，消息重試等功能。

以上就是如何設(shè)計一個消息隊列MQ的介紹，由于篇幅關(guān)系，后續(xù)再詳解消息隊列需要支持的高級特性。

覺得有用請點贊支持，送你[架構(gòu)學(xué)習(xí)資料包]，資料包內(nèi)容：

1.最新最全的架構(gòu)師學(xué)習(xí)圖譜高清版：架構(gòu)師知識點一目了然；

2.架構(gòu)師學(xué)習(xí)專題88期資料合集：配合圖譜，學(xué)習(xí)更科學(xué)；

3.程序員高贊的架構(gòu)師學(xué)習(xí)圖書9本。

總結(jié)

以上是生活随笔為你收集整理的高并发架构系列：如何从0到1设计一个MQ消息队列的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。