從0到1設計一個MQ消息隊列
消息隊列作為系統解耦，流量控制的利器，是分布式系統核心組件之一。
了解消息隊列背后的實現是非常重要的。
今天，我們就一起來探討設計一個消息隊列背后的技術。
消息隊列整體設計思路
主要是設計一個整體的消息被消費的數據流。
這里會涉及到：消息生產Producer、Broker(消息服務端)、消息消費者Consumer。
1.Producer(消息生產者)：發送消息到Broker。
2.Broker(服務端)：Broker這個概念主要來自于Apache的ActiveMQ，特指消息隊列的服務端。
主要功能就是：把消息從發送端傳送到接收端，這里會涉及到消息的存儲、消息通訊機制等。
3.Consumer(消息消費者)：從消息隊列接收消息，consumer回復消費確認。
Broker(消息隊列服務端)設計重點
1)消息的轉儲：在更合適的時間點投遞，或者通過一系列手段輔助消息最終能送達消費機。
2)規范一種范式和通用的模式，以滿足解耦、最終一致性、錯峰等需求。
3)其實簡單理解就是一個消息轉發器，把一次RPC做成兩次RPC，發送者把消息投遞到broker，broker再將消息轉發一手到接收端。
總結起來就是兩次RPC加一次轉儲，如果要做消費確認，則是三次RPC。
為了實現上述消息隊列的基礎功能：
1)消息的傳輸
2)存儲
3)消費
就需要涉及到如下三個方面的設計：
1)通信協議
2)存儲選擇
3)消費關系維護
通訊協議
消息Message: 既是信息的載體，消息發送者需要知道如何構造消息，消息接收者需要知道如何解析消息，它們需要按照一種統一的格式描述消息，這種統一的格式稱之為消息協議。
傳統的通信協議標準有XMPP和AMQP協議等，現在更多的消息隊列從性能的角度出發使用自己設計實現的通信協議。
1.JMS
JMS(Java MessageService)實際上是指JMS API。JMS是由Sun公司早期提出的消息標準，旨在為java應用提供統一的消息操作，包括創建消息、發送消息、接收消息等。
JMS通常包含如下一些角色：
JMS提供了兩種消息模型：
1)點對點
2)以及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自身的業務需求而定制的。
存儲選型
對于分布式系統，存儲的選擇有以下幾種
1.內存
2.本地文件系統
3.分布式文件系統
4.nosql
5.DB
從速度上內存顯然是最快的，對于允許消息丟失，消息堆積能力要求不高的場景(例如日志)，內存會是比較好的選擇。
DB則是最簡單的實現可靠存儲的方案，很適合用在可靠性要求很高，最終一致性的場景(例如交易消息)，對于不需要100%保證數據完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇。
理論上，從速度來看，文件系統>分布式KV(持久化)>分布式文件系統>數據庫，而可靠性卻截然相反。
還是要從支持的業務場景出發作出最合理的選擇，如果你們的消息隊列是用來支持支付/交易等對可靠性要求非常高，但對性能和量的要求沒有這么高，而且沒有時間精力專門做文件存儲系統的研究，DB是最好的選擇。
對于不需要100%保證數據完整性的場景，要求性能和消息堆積的場景，hbase也是一個很好的選擇，典型的比如 kafka的消息落地可以使用hadoop。
消費關系處理
現在我們的消息隊列初步具備了轉儲消息的能力。
下面一個重要的事情就是解析發送接收關系，進行正確的消息投遞了。
市面上的消息隊列定義了一堆讓人暈頭轉向的名詞，如JMS 規范中的Topic/Queue，Kafka里面的Topic/Partition/ConsumerGroup，RabbitMQ里面的Exchange等等。
拋開現象看本質，無外乎是單播與廣播的區別。
所謂單播，就是點到點;而廣播，是一點對多點。
為了實現廣播功能，我們必須要維護消費關系，通常消息隊列本身不維護消費訂閱關系，可以利用zookeeper等成熟的系統維護消費關系，在消費關系發生變化時下發通知。
消息隊列需要支持高級特性
- 消息的順序
- 投遞可靠性保證
- 消息持久化
- 支持不同消息模型
- 多實例集群功能
- 事務特性等
除了上述的消息隊列基本功能以外，消息隊列在某些特殊的場景還需要支持事務，消息重試等功能。
以上，是從0到1設計一個MQ消息隊列的經驗分享。
