一、概述
消息隊列中間件是分布式系統(tǒng)中的重要組件，主要實現(xiàn)異步消息，應(yīng)用解耦，流量削峰和消息通訊等功能。實現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu)。
消息隊列中間件（Message Queue Middleware）是指利用高效可靠的消息傳遞機(jī)制，進(jìn)行與平臺無關(guān)的數(shù)據(jù)交流，并給予數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成。通過提供消息傳遞和消息隊列模型，它可以在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信。
二、應(yīng)用場景
- 異步處理
- 系統(tǒng)解耦（解決不同重要程度、能力級別的系統(tǒng)之間依賴導(dǎo)致雪崩）
- 流量削峰 （解決瞬時寫壓力大于應(yīng)用服務(wù)能力而導(dǎo)致的消息丟失、系統(tǒng)崩潰等問題）
異步處理
場景說明：用戶注冊后，需要發(fā)注冊郵件和注冊短信。傳統(tǒng)的做法有下面兩種。
（1）串行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件，再發(fā)送注冊短信。以上三個任務(wù)全部完成后，返回給客戶端。
（2）并行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件的同時，發(fā)送注冊短信。以上三個任務(wù)完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時間。
假設(shè)三個業(yè)務(wù)節(jié)點每個使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開銷，則串行方式的時間是150毫秒，并行的時間可能是100毫秒。
因為CPU在單位時間內(nèi)處理的請求數(shù)是一定的，假設(shè)CPU在1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請求量是7次（1000/150）。并行方式處理的請求量是10次（1000/100）。
小結(jié)：如以上案例描述，采用傳統(tǒng)方式的系統(tǒng)性能（并發(fā)量，吞吐量，響應(yīng)時間）會有瓶頸。如何解決這個問題呢？
引入消息隊列，將不是必須的業(yè)務(wù)邏輯，異步處理。
按照以上約定，用戶的響應(yīng)時間相當(dāng)于是注冊信息寫入數(shù)據(jù)庫的時間，也就是50毫秒。注冊郵件，發(fā)送短信寫入消息隊列后，直接返回，因為寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應(yīng)時間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。
系統(tǒng)解耦
場景說明：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。
傳統(tǒng)模式的缺點：
1） 假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導(dǎo)致訂單失??；
2） 訂單系統(tǒng)與庫存系統(tǒng)耦合；
如何解決以上問題呢？引入應(yīng)用消息隊列后的方案，
訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。
庫存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據(jù)下單信息，進(jìn)行庫存操作。
假如：在下單時庫存系統(tǒng)如果不能正常使用，也不影響正常下單。實現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦。
流量削峰
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團(tuán)搶活動中使用廣泛。
應(yīng)用場景：秒殺活動，一般會因為流量過大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個問題，一般需要在應(yīng)用前端加入消息隊列。
- 可以控制活動的人數(shù)；
- 可以緩解短時間內(nèi)高流量壓垮應(yīng)用；
消息通訊
消息通訊是指，消息隊列一般都內(nèi)置了高效的通信機(jī)制，因此可以用在簡單的消息通訊。
三、消息模型
在JMS標(biāo)準(zhǔn)中，有兩種消息模型P2P（Point toPoint）,Publish/Subscribe(Pub/Sub)。
P2P模式
每個消息只有一個消費者(即一旦被消費，消息就不再在消息隊列中)。
Pub/Sub模式
包含三個角色：主題（Topic），發(fā)布者（Publisher），訂閱者（Subscriber） 。
每個消息可以有多個消費者。
四、MQ選型
五、其他相關(guān)理論
AMQP
高級消息隊列協(xié)議（AMQP）是應(yīng)用層協(xié)議規(guī)范。作為線路層協(xié)議，而不是API（例如JMS）。用在對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求在其次。
JNDI
即Java命名和目錄接口，是一種標(biāo)準(zhǔn)的Java命名系統(tǒng)接口?？梢栽诰W(wǎng)絡(luò)上查找和訪問服務(wù)。通過指定一個資源名稱，該名稱對應(yīng)數(shù)據(jù)庫或命名服務(wù)中的一個記錄，同時返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發(fā)送目標(biāo)或消息來源的作用。
