消息中間件小結

消息中間件小結

消息中間件概述

什麼是消息中間件

消息中間件，也可以叫做中央消息隊列或者是消息隊列（區別於本地消息隊列，本地消息隊列指的是JVM內的隊列實現），是一種獨立的隊列系統，消息中間件經常用來解決內部服務之間的異步調用問題。請求服務方把請求隊列放到隊列中即可返回，然後等待服務提供方去隊列中獲取請求進行處理，之後通過回調等機制把結果返回給請求服務方。
消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數據交流；並基於數據通信來進行分佈式系統的集成；通過提供消息傳遞和消息排隊模型，它可以在分佈式環境下拓展進程間的通信。
常見的消息中間件有ActiveMQ、RabbitMQ、Kafka、RocketMQ。

消息中間件核心設計

本質

消息中間件其實是一種具備接受請求、保存數據、發送數據等功能的網絡應用。消息中間件和一般網絡應用程序的區別是它主要負責數據的接受和傳遞，所以性能一般都高於普通程序。

5大核心組成

1、協議
2、持久化機制
3、消息分發機制
4、高可用設計
5、高可靠設計

協議

消息中間件常用的協議：OpenWire、AMQP、MQTT、Kafka、OpenMessage。
AMQP協議：有事務支持、持久化支持，出生金融行業，在可靠性消息處理上具備天然的優勢。
MQTT協議：輕量、結構簡單、傳輸快、沒有事務支持、沒有持久化相關設計。適用於計算能力有限。低帶寬、網絡不穩定的場景。
Open Message協議：結構簡單、解析快、有事務設計、有持久化設計。
Kafka協議：結構簡單、解析快、無事務設計、有持久化設計。

持久化

持久化簡單來說就是將數據存入磁盤，而不是存在內存中隨服務重啓而消失，使數據能夠永久保存。

持久化方式	ActiveMQ	RabbitMQ	Kafka	RocketMQ
文件系統	支持	支持	支持	支持
數據庫	支持	/	/	/

消息分發

消息分發策略	ActiveMQ	RabbitMQ	Kafka	RocketMQ
發佈訂閱	支持	支持	支持	支持
輪詢分發	支持	支持	支持	/
輪詢分發	支持	支持	支持	/
公平分發	/	支持	支持	/
重發	支持	支持	/	支持
消息拉取	/	支持	支持	支持

高可用

高可用性是指產品在規定的條件和規定的時刻或時間區間內處於可執行規定功能狀態的能力。
當業務量大時，一臺消息中間件服務器可能無法滿足需求，所以需要消息中間件能夠集羣部署，來達到高可用的目的。集羣部署的方案有Master-Slave主從共享數據的部署方式、Master-Slave主從同步部署方式、Broker-Cluster多主集羣同步部署方式、Broker-Cluster多主集羣轉發部署方式、Master-Slave和Broker-Cluster結合。

高可靠

高可靠性是指系統可以無故障地持續運行。比如一個系統從來不崩潰、報錯，或者崩潰、報錯的機率較低，那就是高可靠。
保證消息中間件的高可靠性，可以從以下方面考慮。
消息傳輸可靠：通過協議來保證系統間數據解析的正確性。
消息存儲可靠：通過持久化來保證消息的存儲可靠性。

消息中間件的應用場景

削峯限流

在不使用消息隊列服務器的時候，用戶的請求數據直接寫入數據庫，在高併發的情況下數據庫壓力劇增，使得響應速度變慢。但是在使用消息隊列之後，用戶的請求數據發送給消息隊列之後立即 返回，再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。由於消息隊列服務器處理速度快於數據庫（消息隊列也比數據庫有更好的伸縮性），因此響應速度得到大幅改善。
通過以上分析我們可以得出消息隊列具有很好的削峯作用的功能——即通過異步處理，將短時間高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務。
因爲用戶請求數據寫入消息隊列之後就立即返回給用戶了，但是請求數據在後續的業務校驗、寫數據庫等操作中可能失敗。因此使用消息隊列進行異步處理之後，需要適當修改業務流程進行配合，比如用戶在提交訂單之後，訂單數據寫入消息隊列，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之後，甚至出庫後，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們平時手機訂火車票和電影票。

解耦

消息隊列使利用發佈-訂閱模式工作，消息發送者（生產者）發佈消息，一個或多個消息接受者（消費者）訂閱消息。 消息發送者將消息發送至分佈式消息隊列即結束對消息的處理，消息接受者從分佈式消息隊列獲取該消息後進行後續處理，並不需要知道該消息從何而來。對新增業務，只要對該類消息感興趣，即可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。

分佈式事務的解決方案

可通過MQ來保證兩個系統的最終一致性，即解決分佈式事務問題。該MQ需要做到消息可靠發送和消息可靠消費。
用MQ解決分佈式事務的方案通用性強、拓展性強、方案成熟，但只適合異步場景、存在延遲（需要業務上能夠容忍）。

使用消息中間件帶來的問題

1、系統可用性降低：系統可用性在某種程度上降低。引入MQ之後，需要考慮消息丟失或者說MQ掛掉等的情況。
2、系統複雜性提高：加入MQ之後，你需要保證消息沒有被重複消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！
3、一致性問題：消息中間件可以實現異步，異步確實可以提高系統響應速度。但是，萬一消息的真正消費者並沒有正確消費消息怎麼辦？這樣就會導致數據不一致的情況了!

常見的消息中間件對比

對比方向	概要
吞吐量	萬級的ActiveMQ和RabbitMQ的吞吐量要比十萬級甚至是百萬級的RocketMQ和Kafka低一個數量級。
可用性	都可以實現高可用。ActiveMQ和RabbitMQ都是基於主從架構實現高可用性。RocketMQ基於分佈式架構。kafka也是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用。
時效性	RabbitMQ基於erlang開發，所以併發能力很強，性能極其好，延時很低，達到微秒級。其他三個都是 ms 級。
功能支持	除了Kafka，其他三個功能都較爲完備。Kafka功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準。
消息丟失	ActiveMQ和RabbitMQ丟失的可能性非常低，RocketMQ和Kafka理論上不會丟失。

消息中間件官方網站

學習消息中間件，官方網站提供了很好的文檔。
ActiveMQ http://activemq.apache.org/
RabbitMQ https://www.rabbitmq.com/
Kafka http://kafka.apache.org/
RocketMQ http://rocketmq.apache.org/