前言
不知道在大家的開發過程中，有沒有碰到需要用到消息隊列。之前的工作中使用的是kafka作爲消息隊列！
目前在寫自己的論文，也需要用到消息隊列，所以就把它系統的總結一下！
消息隊列中間件是分佈式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題
實現高性能，高可用，可伸縮和最終一致性架構
使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ
個人認爲消息隊列的主要特點是異步處理，主要目的是減少請求響應時間和解耦。所以主要的
使用場景就是將比較耗時而且不需要即時（同步）返回結果的操作作爲消息放入消息隊列。同時由
於使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方並不需要彼此聯繫，也不需要
受對方的影響，即解耦和。
舉一個經常遇到的場景：
假設用戶在你的軟件中註冊，服務端收到用戶的註冊請求後，它會做這些操作：
- 1） 校驗用戶名等信息，如果沒問題會在數據庫中添加一個用戶記錄
- 2）如果是用郵箱註冊會給你發送一封註冊成功的郵件，手機註冊則會發送一條短信
- 3）分析用戶的個人信息，以便將來向他推薦一些志同道合的人，或向那些人推薦他
- 4）發送給用戶一個包含操作指南的系統通知，等等。。。。
但是對於用戶來說，註冊功能實際只需要第一步，只要服務端將他的賬戶信息存到數據庫中
他便可以登錄上去做他想做的事情了。至於其他的事情，非要在這一次請求中全部完成麼？
值得用戶浪費時間等你處理這些對他來說無關緊要的事情麼？
所以實際當第一步做完後，服務端就可以把其他的操作放入對應的消息隊列中然後馬上返回
用戶結果，由消息隊列異步的進行這些操作。
或者還有一種情況，同時有大量用戶註冊你的軟件，再高併發情況下注冊請求開始出現一些
問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶
數據記錄很快的添加到數據庫中了，但是卻卡在發郵件或分析信息時的情況，導致請求的響應
時間大幅增長，甚至出現超時，這就有點不划算了。面對這種情況一般也是將這些操作放入消
息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時可以很快的完成註冊請求，不
會影響用戶使用其他功能。
所以在軟件的正常功能開發中，並不需要去刻意的尋找消息隊列的使用場景，而是當出現性能
瓶頸時，去查看業務邏輯是否存在可以異步處理的耗時操作，如果存在的話便可以引入消息隊
列來解決。否則盲目的使用消息隊列可能會增加維護和開發的成本卻無法得到可觀的性能提升
，那就得不償失了。
再舉一個例子：
由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，
update之類的請求同時到達MySQL，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從
而觸發too many connections錯誤。通過使用消息隊列，我們可以異步處理請求，從而緩解
系統的壓力。
一、消息隊列的作用和優點
1.1 使用消息隊列理由
當系統中出現“生產“和“消費“的速度或穩定性等因素不一致的時候，就需要消息隊列，作爲
抽象層，彌合雙方的差異。“ 消息 ”是在兩臺計算機間傳送的數據單位。消息可以非常簡單
例如只包含文本字符串；也可以更復雜，可能包含嵌入對象。消息被髮送到隊列中，“ 消息
隊列 ”是在消息的傳輸過程中保存消息的容器 。
舉例：
- 業務系統觸發短信發送申請，但短信發送模塊速度跟不上，需要將來不及處理的消息暫存一下，
緩衝壓力。就可以把短信發送申請丟到消息隊列，直接返回用戶成功，短信發送模塊再可以慢慢
去消息隊列中取消息進行處理。 - 調遠程系統下訂單成本較高，且因爲網絡等因素，不穩定，攢一批一起發送。
- 任務處理類的系統，先把用戶發起的任務請求接收過來存到消息隊列中，然後後端開啓多個
應用程序從隊列中取任務進行處理。
1.2 使用消息隊列好處
- 提高系統響應速度
使用了消息隊列，生產者一方，把消息往隊列裏一扔，就可以立馬返回，響應用戶了。
無需等待處理結果。
處理結果可以讓用戶稍後自己來取，如醫院取化驗單。也可以讓生產者訂閱（如：留下手機號碼
或讓生產者實現listener接口、加入監聽隊列），有結果了通知。獲得約定將結果放在某處，無
需通知。 - 提高系統穩定性
考慮電商系統下訂單，發送數據給生產系統的情況。電商系統和生產系統之間的網絡有可能掉線，
生產系統可能會因維護等原因暫停服務。如果不使用消息隊列，電商系統數據發佈出去，顧客無
法下單，影響業務開展。兩個系統間不應該如此緊密耦合。應該通過消息隊列解耦。同時讓系統
更健壯、穩定。
二、消息隊列應用場景
其實消息隊列在很多方面的可以使用，總結下來：
- 異步處理：例如短信通知、終端狀態推送、App推送、用戶註冊等
- 數據同步：業務數據推送同步
- 重試補償：記賬失敗重試
- 系統解耦：通訊上下行、終端異常監控、分佈式事件中心
- 流量消峯：秒殺場景下的下單處理
- 發佈訂閱：HSF的服務狀態變化通知、分佈式事件中心
- 高併發緩衝：日誌服務、監控上報
2.1 異步處理
場景說明：
用戶註冊後，需要發註冊郵件和註冊短信。傳統的做法有兩種 1.串行的方式；2.並行方式
- 串行方式
將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。
以上三個任務全部完成後，返回給客戶端。
![]()
- 並行方式
將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，
返回給客戶端。與串行的差別是，並行的方式可以提高處理的時間。
![]()
假設三個業務節點每個使用50毫秒鐘，不考慮網絡等其他開銷，則串行方式的時間是150毫秒，
並行的時間可能是100毫秒。
因爲CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串行方式1秒
內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。
問題引發：傳統的方式系統的性能（併發量，吞吐量，響應時間）會有瓶頸。
引入消息隊列，將不是必須的業務邏輯，異步處理。改造後的架構如下：
按照以上約定，用戶的響應時間相當於是註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件，
發送短信寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的
響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串行提高了3倍，
比並行提高了兩倍。
2.2 系統解耦
場景說明：
用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。
如下圖
傳統模式的缺點：
- 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗
- 訂單系統與庫存系統耦合
問題解決方案：
- 訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單
下單成功。 - 庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，
進行庫存操作。 - 在下單時庫存系統不能正常使用。也不影響正常下單，因爲下單後，訂單系統寫入消息隊
列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
2.3 流量削峯
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛
應用場景：
秒殺活動，一般會因爲流量過大，導致流量暴增，應用掛掉。爲解決這個問題，一般需要在應
用前端加入消息隊列。
- 可以控制活動的人數
- 可以緩解短時間內高流量壓垮應用
- 用戶的請求，服務器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接
拋棄用戶請求或跳轉到錯誤頁面。 - 秒殺業務根據消息隊列中的請求信息，再做後續處理。
2.4 日誌處理
日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。
架構簡化如下：
- 日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列
- Kafka消息隊列，負責日誌數據的接收，存儲和轉發
- 日誌處理應用：訂閱並消費kafka隊列中的日誌數據
舉例：新浪kafka日誌處理
- Kafka：接收用戶日誌的消息隊列
- Logstash：做日誌解析，統一成JSON輸出給Elasticsearch
- Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，
通過index組織數據，兼具強大的搜索和統計功能 - Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是衆多公司選擇
ELK stack的重要原因
2.4 消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。
比如實現點對點消息隊列，或者聊天室等。
- 點對點通訊
![]()
客戶端A和客戶端B使用同一隊列，進行消息通訊。 - 聊天室通訊
![]()
客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發佈和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式，點對點或發佈訂閱模式。
三、消息中間件實際使用實例
3.1 電商系統
消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。
- 應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啓消息的確認模式。
（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性） - 擴展流程（發短信，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。
- 消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。
比如主數據寫入數據庫，擴展應用根據消息隊列，並結合數據庫方式實現基於消息隊列的後
續處理。
3.2 日誌採集系統
分爲Zookeeper註冊中心，日誌收集客戶端，Kafka集羣和Storm集羣（OtherApp）四部分組成。
- Zookeeper註冊中心，提出負載均衡和地址查找服務
- 日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列
- Kafka集羣：接收，路由，存儲，轉發等消息處理
- Storm集羣：與OtherApp處於同一級別，採用拉的方式消費隊列中的數據
參考文章：
https://blog.csdn.net/seven__________7/article/details/70225830
