消息隊列整體設計思路
主要是設計一個整體的消息被消費的數據流。
這裏會涉及到：消息生產Producer、Broker(消息服務端)、消息消費者Consumer。
1.Producer(消息生產者)：發送消息到Broker。
2.Broker(服務端)：Broker這個概念主要來自於Apache的ActiveMQ，特指消息隊列的服務端。
主要功能就是：把消息從發送端傳送到接收端，這裏會涉及到消息的存儲、消息通訊機制等。
3.Consumer(消息消費者)：從消息隊列接收消息，consumer回覆消費確認。
Broker(消息隊列服務端)設計重點1）消息的轉儲：在更合適的時間點投遞，或者通過一系列手段輔助消息最終能送達消費機。
2）規範一種範式和通用的模式，以滿足解耦、最終一致性、錯峯等需求。
3）其實簡單理解就是一個消息轉發器，把一次RPC做成兩次RPC，發送者把消息投遞到broker，broker再將消息轉發一手到接收端。
總結起來就是兩次RPC加一次轉儲，如果要做消費確認，則是三次RPC。
爲了實現上述消息隊列的基礎功能：
- 消息的傳輸
- 存儲
- 消費
就需要涉及到如下三個方面的設計：
- 通信協議
- 存儲選擇
- 消費關係維護
通訊協議
消息Message:既是信息的載體，消息發送者需要知道如何構造消息，消息接收者需要知道如何解析消息，它們需要按照一種統一的格式描述消息，這種統一的格式稱之爲消息協議。
傳統的通信協議標準有XMPP和AMQP協議等，現在更多的消息隊列從性能的角度出發使用自己設計實現的通信協議。
1.JMS
JMS（Java MessageService）實際上是指JMS API。JMS是由Sun公司早期提出的消息標準，旨在爲java應用提供統一的消息操作，包括創建消息、發送消息、接收消息等。
JMS通常包含如下一些角色：
JMS提供了兩種消息模型：
- 點對點
- 以及publish-subscribe（發佈訂閱）模型。
當採用點對點模型時，消息將發送到一個隊列，該隊列的消息只能被一個消費者消費。
而採用發佈訂閱模型時，消息可以被多個消費者消費。
在發佈訂閱模型中，生產者和消費者完全獨立，不需要感知對方的存在。
2.AMQP
AMQP是 Advanced Message Queuing Protocol，即高級消息隊列協議。
AMQP不是一個具體的消息隊列實現，而 是一個標準化的消息中間件協議。
目標是讓不同語言，不同系統的應用互相通信，並提供一個簡單統一的模型和編程接口。 目前主流的ActiveMQ和RabbitMQ都支持AMQP協議。
AMQP是一種協議，更準確的說是一種binary wire-level protocol（鏈接協議）。這是其和JMS的本質差別，AMQP不從API層進行限定，而是直接定義網絡交換的數據格式。
JMS和AMQP比較
JMS: 只允許基於JAVA實現的消息平臺的之間進行通信
AMQP: AMQP允許多種技術同時進行協議通信
3.Kafka的通信協議
Kafka的Producer、Broker和Consumer之間採用的是一套自行設計的基於TCP層的協議。Kafka的這套協議完全是爲了Kafka自身的業務需求而定製的。
存儲選型
對於分佈式系統，存儲的選擇有以下幾種
- 內存
- 本地文件系統
- 分佈式文件系統
- nosql
- DB
從速度上內存顯然是最快的，對於允許消息丟失，消息堆積能力要求不高的場景(例如日誌)，內存會是比較好的選擇。
DB則是最簡單的實現可靠存儲的方案，很適合用在可靠性要求很高，最終一致性的場景(例如交易消息)，對於不需要100%保證數據完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇。
理論上，從速度來看，文件系統>分佈式KV（持久化）>分佈式文件系統>數據庫，而可靠性卻截然相反。
還是要從支持的業務場景出發作出最合理的選擇，如果你們的消息隊列是用來支持支付/交易等對可靠性要求非常高，但對性能和量的要求沒有這麼高，而且沒有時間精力專門做文件存儲系統的研究，DB是最好的選擇。
對於不需要100%保證數據完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇，典型的比如 kafka的消息落地可以使用hadoop。
消費關係處理
現在我們的消息隊列初步具備了轉儲消息的能力。
下面一個重要的事情就是解析發送接收關係，進行正確的消息投遞了。
市面上的消息隊列定義了一堆讓人暈頭轉向的名詞，如JMS 規範中的Topic/Queue，Kafka裏面的Topic/Partition/ConsumerGroup，RabbitMQ裏面的Exchange等等。
拋開現象看本質，無外乎是單播與廣播的區別。
所謂單播，就是點到點；而廣播，是一點對多點。
爲了實現廣播功能，我們必須要維護消費關係，通常消息隊列本身不維護消費訂閱關係，可以利用zookeeper等成熟的系統維護消費關係，在消費關係發生變化時下發通知。
消息隊列需要支持高級特性
除了上述的消息隊列基本功能以外，消息隊列在某些特殊的場景還需要支持事務，消息重試等功能。
- 消息的順序
- 投遞可靠性保證
- 消息持久化
- 支持不同消息模型
- 多實例集羣功能
- 事務特性等
以上就是如何設計一個消息隊列MQ的介紹，由於篇幅關係，後續再詳解消息隊列需要支持的高級特性。