什么是消息中間件？

• 消息中間件是在消息的傳輸過(guò)程中保存消息的容器
• 消息中間件將消息從源中繼（生產(chǎn)者）到目標(biāo)（消費(fèi)者）時(shí)充當(dāng)中間人的角色

消息中間件的目的是提供路由并保證消息的傳遞，如果發(fā)送消息時(shí)接收者不可用，消息隊(duì)列會(huì)保留消息，直到可以成功地傳遞它為止，當(dāng)然消息隊(duì)列保存消息也是有期限的。

消息中間件 Broker

消息中間件有什么特點(diǎn)呢？

• 異步處理模式

消息發(fā)送者發(fā)送一個(gè)消息而無(wú)需等待響應(yīng)，消息發(fā)送者將消息發(fā)送到一條虛擬的通道（主題或隊(duì)列）上，消息接收者訂閱或監(jiān)聽通道。一條消息可能最終轉(zhuǎn)發(fā)給一個(gè)或多個(gè)消息接收者，這些接收者都無(wú)需對(duì)消息發(fā)送者做出同步回應(yīng)，整個(gè)過(guò)程是異步的。

例如：用戶信息注冊(cè)，注冊(cè)完畢后發(fā)送郵件和短信。

• 應(yīng)用程序之間調(diào)用關(guān)系為松耦合

應(yīng)用程序之間調(diào)用關(guān)系為松耦合

• 消息發(fā)送者和接收者不必了解對(duì)方，只需要確認(rèn)消息。
• 消息發(fā)送者和接收者不必同時(shí)在線

例如：在線交易系統(tǒng)為了保證數(shù)據(jù)的最終一致（一致性），在支付系統(tǒng)處理完畢后會(huì)把支付結(jié)果放到消息中間件中通知訂單系統(tǒng)修改訂單支付狀態(tài)。兩個(gè)系統(tǒng)通過(guò)消息中間件解耦。

消息傳遞服務(wù)模型

消息傳遞服務(wù)模型

消息傳遞服務(wù)模型

消息中間件英文全稱為Message Oriented Middleware，簡(jiǎn)稱為MOM。

Message-oriented middleware（MOM）is software or hardware infrastructure supporting sending and receiving messages between distributed systems.

消息中間件是在分布式系統(tǒng)間支持收發(fā)消息的軟件或硬件

消息中間件

消息中間件的傳遞模型

1. 點(diǎn)對(duì)點(diǎn)模型（PTP, Point To Point）

• 點(diǎn)對(duì)點(diǎn)模型用于消息生產(chǎn)者和消費(fèi)者之間點(diǎn)到點(diǎn)的通信
• 消息生產(chǎn)者將消息發(fā)送到由某個(gè)名字標(biāo)識(shí)的特定消費(fèi)者。這個(gè)名字實(shí)際上對(duì)應(yīng)消息服務(wù)中的一個(gè)隊(duì)列（Queue），在消息傳遞給消費(fèi)者之前會(huì)被存儲(chǔ)在這個(gè)隊(duì)列中。
• 隊(duì)列消息可以存放在內(nèi)存中也可以是持久的，以保證在消息服務(wù)出現(xiàn)故障時(shí)仍然能夠傳遞消息。

點(diǎn)對(duì)點(diǎn)模型

點(diǎn)對(duì)點(diǎn)模型特性

• 每個(gè)消息只有一個(gè)消費(fèi)者
• 發(fā)送者和接收者之間沒有時(shí)間依賴
• 接收者確認(rèn)消息接收和處理成功

點(diǎn)對(duì)點(diǎn)模型

2. 發(fā)布訂閱模型（Pub/Sub）

訂閱

• 發(fā)布訂閱模型支持向一個(gè)特定的消息主題生產(chǎn)消息
• 零個(gè)或多個(gè)訂閱者可能對(duì)接收來(lái)自特定消息主題的消息感興趣
• 發(fā)布訂閱模型中發(fā)布者和訂閱者彼此不知道對(duì)方，好比是匿名公告板。
• 多個(gè)消費(fèi)者可以獲得消息
• 在發(fā)布者和訂閱者之間存在時(shí)間依賴性
• 發(fā)布者需要建立一個(gè)訂閱（subscription）以便消費(fèi)者能夠訂閱
• 訂閱者必須保持持續(xù)的活動(dòng)狀態(tài)以接收消息
• 除非訂閱者建立了持久的訂閱，在訂閱者未連接時(shí)發(fā)布的消息將在訂閱者重新連接時(shí)重新發(fā)布。

發(fā)布訂閱模型

發(fā)布訂閱模型特性

• 每個(gè)消息可以有多個(gè)訂閱者
• 客戶端只有訂閱后才能接收到消息
• 持久訂閱和非持久訂閱

發(fā)布訂閱模型

發(fā)布訂閱模型特點(diǎn)

• 發(fā)布者和訂閱者之間有時(shí)間依賴
  接收者和發(fā)布者之間只有建立了訂閱關(guān)系后才能接收到消息
• 持久訂閱
  訂閱關(guān)系建立后消息就不會(huì)消失，不管訂閱者是否在線。
• 非持久訂閱
  訂閱者為了接收消息必須一直在線，當(dāng)僅有一個(gè)訂閱者時(shí)相當(dāng)于點(diǎn)對(duì)點(diǎn)模型。

互聯(lián)網(wǎng)消息中間件應(yīng)用場(chǎng)景

1. 用戶注冊(cè)，注冊(cè)成功后過(guò)一會(huì)兒發(fā)送郵件確認(rèn)或短信確認(rèn)。（發(fā)布訂閱模式）

用戶注冊(cè)

SOA（Service-oriented Architecture）面向服務(wù)的架構(gòu)，是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進(jìn)行拆分，并通過(guò)這些服務(wù)之間定義良好的接口和鍥約聯(lián)系起來(lái)。

SOA

2. 日志分析，將日志進(jìn)行集中收集，用于計(jì)算PV、用戶行為分析...

日志分析

MVP（Minimum Variable Product）最小可行產(chǎn)品，小流量實(shí)驗(yàn) AV-Test，通過(guò)Nginx分流，需要集中收集日志。

3. 數(shù)據(jù)復(fù)制

• 將數(shù)據(jù)從源頭復(fù)制到多個(gè)目的地，一般是要求順序或保證因果序列。
• 用于跨機(jī)房數(shù)據(jù)傳輸、搜索、離線數(shù)據(jù)計(jì)算等。

數(shù)據(jù)復(fù)制

數(shù)據(jù)復(fù)制需要做到兩點(diǎn)

• 數(shù)據(jù)的完整性：md5校驗(yàn)...
• 數(shù)據(jù)的順序性：有限狀態(tài)機(jī)（FSM，F(xiàn)inite-state machine）

4. 延遲消息發(fā)送和暫存（點(diǎn)對(duì)點(diǎn)模式）

• 將消息中間件當(dāng)成可靠的消息暫存地
• 定時(shí)進(jìn)行消息投遞，比如模擬用戶秒殺訪問(wèn)，進(jìn)行系統(tǒng)性能壓測(cè)。

延遲消息發(fā)送和暫存

TCPcopy是一種請(qǐng)求復(fù)制的工具，基于TCP的packages，其功能時(shí)候復(fù)制在線數(shù)據(jù)包，修改TCP/IP頭部信息，發(fā)送給測(cè)試服務(wù)器，達(dá)到欺騙測(cè)試服務(wù)器的TCP程序的目的，從而為欺騙上層應(yīng)用打下堅(jiān)實(shí)基礎(chǔ)。

• 分布式壓力測(cè)試工具，利用在線數(shù)據(jù)，可以測(cè)試系統(tǒng)能夠承受的壓力大小，可提前發(fā)現(xiàn)bug。
• 普通上線測(cè)試，發(fā)現(xiàn)新系統(tǒng)是否穩(wěn)定。
• 對(duì)比試驗(yàn)，針對(duì)不同版本程序做性能對(duì)比等試驗(yàn)。
• 流量放大，利用多種手段構(gòu)造無(wú)限在線壓力。
• 熱備份
• 實(shí)戰(zhàn)演練

5. 消息廣播（發(fā)布訂閱模式）

• 緩存數(shù)據(jù)同步更新
• 往應(yīng)用推送數(shù)據(jù)，比如更新本地緩存...

消息廣播

利用分布式租約（Lease）機(jī)制的方式保證數(shù)據(jù)的一致性，通過(guò)添加時(shí)間戳的方式保證數(shù)據(jù)一致。

消息中間件分類

• push推消息模型
  消息生產(chǎn)者將消息發(fā)送給消息傳遞服務(wù)，消息傳遞服務(wù)再將消息推送給消息消費(fèi)者。對(duì)于發(fā)布訂閱模式，推消息模型使用的會(huì)多一些。推消息模型的好處在于實(shí)時(shí)性比較高。
• pull拉消息模型
  消費(fèi)者請(qǐng)求消息服務(wù)接收消息，生產(chǎn)者從消息服務(wù)中拉取該消息。拉消息模型適合于點(diǎn)對(duì)點(diǎn)的模式，針對(duì)時(shí)效性要求不高的場(chǎng)景。

推拉模型對(duì)比

1. 服務(wù)端

• push處理消息存儲(chǔ)、處理請(qǐng)求、保存推送軌跡、保存訂閱關(guān)系、消費(fèi)者負(fù)載均衡、集中式...
• pull處理消息存儲(chǔ)、處理請(qǐng)求、分布式...

2. 客戶端

• push處理響應(yīng)與請(qǐng)求
• pull處理響應(yīng)和請(qǐng)求，保存pull狀態(tài)（如拉取位置的偏移量offset）、異常情況下的消息暫存和恢復(fù)recover...

3. 實(shí)時(shí)性

• push較好，收到消息后可立即發(fā)送給客戶端。
• pull方式主要取決于pull的時(shí)間間隔

4. 消費(fèi)者故障

• push中消費(fèi)者故障情況下服務(wù)端堆積消息，重復(fù)推送耗費(fèi)資源。保存推送軌跡壓力很大。
• pull中消費(fèi)者故障對(duì)服務(wù)端沒有影響。

5. 其他

• push對(duì)消息推送有更多控制，能實(shí)現(xiàn)多樣化的推送機(jī)制，當(dāng)消費(fèi)者數(shù)量增多時(shí)，推送壓力大性能天花板，消費(fèi)者處理能力差異導(dǎo)致堆消息。
• pull需要在客戶端實(shí)現(xiàn)消息過(guò)濾，浪費(fèi)資源。需要在不同客戶端之間協(xié)調(diào)，做負(fù)載均衡。

應(yīng)用場(chǎng)景

• 消息廣播適用于push推送的消息隊(duì)列
• 延遲消息發(fā)送和暫存適用于pull拉取的方式

未完待續(xù)...