MQ理論介紹
一、為什麼需要消息隊列(MQ)
主要原因是由於在高併發環境下，同步請求來不及處理，請求往往會發生阻塞。大量的請求到達訪問數據庫，導致行鎖表鎖，最後請求線程會堆積過多，從而觸發 too many connection錯誤，引發雪崩效應。我們使用消息隊列，通過異步處理請求，從而緩解系統的壓力。核心：異步處理、流量削峰、應用解耦
二、應用場景
異步處理，流量削峰，應用解耦，消息通訊四個場景
2.1、異步處理
- 場景1：用戶註冊後，需要發送註冊郵件和註冊短信。串行方式：將註冊信息寫入 數據庫 成功後，發送註冊郵件，再發送註冊短信。以上三個任務全部完成後，返回給客戶端
- 並行方式：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，返回給客戶端。與串行的差別是，並行的方式可以提高處理的時間
<code>假設三個業務節點每個使用50毫秒鐘，不考慮網絡等其他開銷，則串行方式的時間是150毫秒，並行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的，假設CPU在1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次（1000/150）。
並行方式處理的請求量是10次（1000/100）
/<code>
- 小結：如以上案例描述，傳統的方式系統的性能（併發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題？引入消息隊列，將不是必須的業務邏輯，異步處理。改造後的架構如下：
<code> 按照以上約定，用戶的響應時間相當於是註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件，發送短信寫入消息隊列後，直接返回，
因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。
比串行提高了3倍，比並行提高了2倍。
/<code>
- 場景2：訂單處理，前端應用將訂單信息放到隊列，後端應用從隊列裡依次獲得消息處理，高峰時的大量訂單可以積壓在隊列裡慢慢處理掉。
2.2、流量削峰
流量削峰也是消息隊列中的常用場景，一般在 秒殺或團搶活動 中使用廣泛
- 應用場景：秒殺活動，一般會因為流量過大，導致流量報增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。可以控制活動的人數可以緩解短時間內高流量壓垮應用
- 讓消息不直接到達服務器，而是先讓 「消息隊列」 保存這些數據，然後讓下面的服務器每一次都取各自能處理的請求數再去處理，這樣當請求數超過服務器最大負載時，就不至於把服務器搞掛了。
- 秒殺業務根據消息隊列中的請求信息，再做後續處理
2.3、應用解耦
- 場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用系統庫存接口。
- 傳統模式的缺點：假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗解決訂單系統與庫存系統耦合，如何解決？引入消息隊列後的方案：
<code>訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功
庫存系統：訂閱下單的消息，採用pub/sub(發佈/訂閱)的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作
/<code>
- 假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入信息隊列就不再關心其他後續操作了。實現訂單系統與庫存系統的應用解耦。
2.4、日誌處理
日誌處理是將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下
- 日誌採集客戶端，負載日誌數據採集，定時寫入Kafka隊列
- Kafka消息隊列，負載日誌數據的接收，儲存和轉發
- 日誌處理應用：訂閱並消費Kafka隊列中的日誌數據
- (1) Kafka：接收用戶日誌的消息隊列
- (2) Logstash：做日誌解析，統一成JSON 輸出給Elasticsearch
- (3)Kibana：基於Elasticsearch 的數據可視化組件，超強的數據可視化能力是眾多公司選擇Elkstack的重要原因
2.5、消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制就，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
- 點對點通訊：
客戶端A和客戶端B使用同一隊列，進行消息通訊。
- 聊天室通訊：
客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發佈和接收。實現類似聊天室效果。以上實際是消息隊列的兩種消息模式，點對點或發佈訂閱模式。
3、衡量指標
我們從服務性能、數據存儲、集群結構三個方面去對比，選擇適合自己項目的消息中間件
特性ActiveMQRabbitMQRocketMQKafka單機吞吐量萬級萬級十萬級十萬級topic 數量對吞吐量的影響--topic 可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降topic 從幾十個到幾百個的時候，吞吐量會大幅度下降時效性毫秒級微秒級毫秒級毫秒級可用性高高非常高，分佈式架構非常高，分佈式架構消息可靠性有較低的概率丟失數據-經過參數優化配置，可以做到 0 丟失經過參數優化配置，消息可以做到 0 丟失功能支持完善併發能力很強，性能極其好，延時很低MQ 功能較為完善，還是分佈式的，擴展性好功能較為簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準優劣勢總結非常成熟，功能強大；偶爾會有較低概率丟失消息；社區不活躍了性能極其好，延時很低；功能完善；提供管理界面；社區比較活躍；吞吐量較低；使用 erlang 開發源碼閱讀不方便；接口簡單易用；吞吐量高；分佈式擴展方便；社區還算活躍；經過雙 11 的考驗MQ 功能比較少；吞吐量高；分佈式架構；可能存在消息重複消費問題；主要適用大數據實時計算以及日誌收集；
4、AvctiveMQ和RabbitMQ
4.1、ActiveMQ
特點：
早期主流的消息中間件，包括ZeroMQ，但是這幾年使用的很少了，主要在長期維護的項目中使用。API豐富，本身很成熟但是在高併發、大數據
環境下的性能不夠出色，主要試用於中小型項目，有較低的概率丟失數據，最主要是的，官方現在維護的頻率一直在降低，好幾個月才發佈一個版本。
架構：
1、Master-Slave模式，通過Zookeeper實現節點切換和故障轉移
2、NetWork模式，相當於多套Master-Slave模式，通過NetWork網關進行集成
4.2、RabbitMQ
RabbitMQ 是使用 Erlang 語言開發的開源消息隊列系統。基於AMQP協議來實現的。AMQP的主要特徵是面向消息、隊列、路由(包括點對點和發佈與訂閱)、可靠性、安全。
AMQP協議：更多的用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次場景。
好處在於可以支撐高併發、高吞吐、性能很高，同時有非常完善便捷的後臺管理界面可以使用。另外，他還支持集群化、高可用部署架構、消息高可靠支持，功能較為完善。
閱讀更多 JAVA技術刀 的文章
