1. 概述
1.1 為什么需要消息中間件
單體架構
在單體架構中，所有的代碼、模塊都放在一份代碼中，如果其中一個模塊需要升級，哪怕只修改了一點點，整個系統(tǒng)也要一起升級，這樣耦合度太高，同時代碼管理也比較難。
分布式系統(tǒng)架構
到了分布式系統(tǒng)架構，這里現(xiàn)在有前臺系統(tǒng)、訂單系統(tǒng)、會員系統(tǒng)，這三個系統(tǒng)分別獨立部署，如果需要升級某個系統(tǒng)，其他系統(tǒng)不需要進行調整。
有些請求不是一個系統(tǒng)就能完成的，比如當在一個頁面上面同時想看會員積分和下單的信息，通過一次請求，這個請求會涉及多個系統(tǒng)。這種多個系統(tǒng)協(xié)作處理一個請求的系統(tǒng)，就被看作是分布式系統(tǒng)，當某個系統(tǒng)壓力大時，可以對單個系統(tǒng)進行擴展。
這時就會用到 RPC 技術，調用遠程接口的方式實現(xiàn)系統(tǒng)間的互相調用。 但是這種方式的耦合度比較高，為了實現(xiàn)更強的拓展性架構，所以在分布式系統(tǒng)中引入了消息中間件，通過消息中間件解決系統(tǒng)的耦合。
基于消息中間件的分布式系統(tǒng)架構
加入了消息中間件之后，請求發(fā)送到消息中間件，由子系統(tǒng)處理完成，然后再給客戶端相應。消息中間件獨立部署，只負責消息的轉發(fā)。
1.2 什么是消息中間件
滿足以下要求的工具就可以被稱為消息中間件
- 利用高效可靠的數(shù)據(jù)傳遞機制，進行平臺無關的數(shù)據(jù)交流
- 基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成
- 通過提供消息傳遞和消息隊列模型，可以在分布式環(huán)境下拓展進程間的通信
1.3 消息中間件的應用場景
跨系統(tǒng)、跨進程的數(shù)據(jù)傳遞
高并發(fā)流量削峰
數(shù)據(jù)異步處理
······
1.4 常用的消息中間件
ActiveMQ、RabbitMQ、Kafka、RocketMQ
1.5 消息中間件核心
本質
一種具備接收請求、保存數(shù)據(jù)、發(fā)送數(shù)據(jù)等功能的網絡應用
主要負責數(shù)據(jù)的接收和傳遞，所以性能一般都高于普通程序
5大核心組成
- 協(xié)議
- 持久化機制
- 消息分發(fā)機制
- 高可用設計
- 高可靠設計
2. 協(xié)議
2.1 協(xié)議是什么
協(xié)議是計算機之間通信時共同遵循的一組約定，遵循相同的約定，計算機之間才能交流。
協(xié)議是對數(shù)據(jù)格式和對交換數(shù)據(jù)時必須遵守的規(guī)則的正式描述，簡單來說協(xié)議就是規(guī)則。
2.2 協(xié)議三要素
- 語法：即數(shù)據(jù)與控制信息的結構或格式
- 語義：即需要發(fā)出何種控制信息、完成何種動作及做出何種反應
- 時序：即事件實現(xiàn)順序的詳細說明
以 HTTP 協(xié)議為例
語法：HTTP 規(guī)定了請求報文和響應報文的具體格式
語義：客戶端主動發(fā)起的操作成為請求
時許：一個請求對應一個響應
2.3 消息中間件常用的協(xié)議
OpenWire、AMQP、MQTT、Kafka、OpenMessage
思考：為什么消息中間件不直接使用 HTTP 協(xié)議？
2.4 協(xié)議介紹
2.4.1 AQMP 協(xié)議
AMQP（Advanced Message Queuing Protocol）是高級消息隊列協(xié)議
04年 JpMorgan Chase（摩根大通集團）聯(lián)合其他公司共同設計。
特性：
事務支持、持久化支持，出生于金融行業(yè)，在可靠性消息處理上有天然的優(yōu)勢。
RabbitMQ、ActiveMQ 實現(xiàn)了此協(xié)議
2.4.2 MQTT 協(xié)議
MQTT（Message Queuing Telemetry Teansport）消息隊列遙測傳輸
是 IBM 開發(fā)的一個即使通訊協(xié)議，物聯(lián)網系統(tǒng)架構中的重要組成部分。
特性：
輕量、結構簡單、傳輸快、沒有事務支持、沒有持久化相關設計。
應用場景：
適用于計算能力有限、低帶寬、網絡不穩(wěn)定的場景。
RabbitMQ、ActiveMQ 實現(xiàn)了此協(xié)議
2.4.3 OpenMessage 協(xié)議
OpenMessage 是近一兩年由阿里發(fā)起，與雅虎、滴滴出行、Streamlio 等公司共同參與創(chuàng)立的分布式消息中間件、流處理領域的應用開發(fā)標準。
特性：
結構簡單、解析快、有事務設計、有持久化設計
RocketMQ 實現(xiàn)了此協(xié)議
2.4.4 Kafka 協(xié)議
Kafka 協(xié)議是基于 TCP 的二進制協(xié)議。消息內部是通過長度來分隔，由一些基本數(shù)據(jù)類型組成。
特性：
結構簡單、解析快、無事務設計、有持久化設計
Kafka 實現(xiàn)了此協(xié)議
3. 持久化
簡單來說就是將數(shù)據(jù)存入磁盤，而不是存在內存中隨服務重啟而消失，使數(shù)據(jù)能夠永久保存叫做持久化。
3.1 常用消息中間件支持的持久化方式
| - | ActiceMQ | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|---|
| 文件系統(tǒng) | 支持 | 支持 | 支持 | 支持 |
| 數(shù)據(jù)庫 | 支持 | / | / | / |
4. 消息分發(fā)
常用消息中間件的分發(fā)策略
| - | ActiveMQ | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|---|
| 發(fā)布訂閱 | 支持 | 支持 | 支持 | 支持 |
| 輪詢分發(fā) | 支持 | 支持 | 支持 | / |
| 公平分發(fā) | / | 支持 | 支持 | / |
| 重發(fā) | 支持 | 支持 | / | 支持 |
| 消息拉取 | / | 支持 | 支持 | 支持 |
發(fā)布訂閱：當多個系統(tǒng)連接到消息中間件時，通過發(fā)布訂閱知道消息是要發(fā)送給誰。
輪詢分發(fā)、公平分發(fā)：當有多個節(jié)點有相同的訂閱，是大家公平的接收，還是通過權重計算分發(fā)的對象。
重發(fā)：當由于系統(tǒng)原因導致異常，消息中間件可以重發(fā)這條數(shù)據(jù)
消息拉?。合⑹侵鲃臃职l(fā)，還是客戶端主動拉取數(shù)據(jù)
5. 高可用
高可用性，指的是產品在規(guī)定的條件和規(guī)定的時刻或時間區(qū)間內，處于可執(zhí)行規(guī)定狀態(tài)功能的能力。
當業(yè)務量大時，一臺消息中間件服務器可能無法滿足需求，所以需要消息中間件能夠集群部署，來達到高可用目的。
5.1 Master-Slave 主從共享數(shù)據(jù)部署方式
和數(shù)據(jù)庫主從類似，但這里是共享數(shù)據(jù)，讀取同一份數(shù)據(jù)源，當一臺掛了，就切換到其他服務器，但數(shù)據(jù)還是同一份
5.2 Master-Slave 主從同步部署方式
和數(shù)據(jù)庫主從一樣，數(shù)據(jù)庫會同步到 slave 上
5.3 Broker-Cluster 多主集群同步部署方式
多個服務器可以同時接收不同消費者的請求，數(shù)據(jù)會在每個服務器上備份
5.4 Broker-Cluster 多主集群轉發(fā)部署方式
服務器可以將請求轉發(fā)給其他服務器，可以選擇轉發(fā)數(shù)據(jù)或者轉發(fā)請求，若轉發(fā)請求的話，則所有服務器公用同一份數(shù)據(jù)。
5.5 Master-Slave 與 Broker-Cluster 結合
同時實現(xiàn)負載均衡和數(shù)據(jù)的備份
6. 高可靠
高可靠性指的是系統(tǒng)可以無故障地持續(xù)運行。比如一個系統(tǒng)從來不崩潰、報錯，或者崩潰、報錯的幾率比較低，那就是高可靠。
保證消息中間件的高可靠，可以從以下幾方面考慮
- 消息傳輸可靠：通過協(xié)議保證系統(tǒng)間數(shù)據(jù)解析的正確性
- 消息存儲可靠：通過持久化來保證消息的存儲可靠性
