[[345260]]

什么是消息中間件?

消息中間件屬于分布式系統中的一個子系統，關注于數據的發送和接收，利用高效可靠的消息傳遞機制對分布式系統中的其余各個子系統經進行集成

消息中間件的使用場景

1.異步處理非核心流程異步化，提高系統響應性能

 

原來用戶注冊一下可能得依次寫數據庫，發送郵件和短信后，才能提示用戶注冊成功

現在只要寫數據庫，寫消息隊列后就直接提示用戶注冊成功，發送郵件和短信是異步處理，提高了響應速度

2.應用解耦

系統不是強耦合，消息接受者可以隨意增加，而不需要修改消息發送者的代碼。消息發送者的成功不依賴消息接受者

rpc實現

 

 

 

 

消息隊列實現

 

如果庫存系統出了問題，用戶就不能正常下單，這是不合理的。可以通過消息隊列來解耦。

當有新的系統如廣告系統對用戶的訂單也感興趣的時候，只需要從消息隊列中拿消息即可，訂單系統完全不用改變

3.流量削峰

當上下游系統處理能力存在差距的時候，可以用消息隊列進行緩沖

在這里插入圖片描述

 

當有秒殺業務時，一下有大量請求涌入時，很可能造成系統癱瘓，此時可以用消息隊列緩沖一下

4.日志處理

將消息隊列用在日志處理中，比如Kafka可以用來解決大量日志傳輸的問題

5.消息通訊

消息隊列一般都內置了高效的通信機制，因此也可以用于單純的消息通訊，比如實現點對點消息隊列或者聊天室等

消息中間件編年史

 

初見曙光

1.消息中間件其實誕生的很早，在互聯網應用還是一片荒蕪的年代，有個在美國的印度哥們Vivek Ranadive就設想了一種通用軟件總線，采用發布訂閱的模式，像主板上的總線一樣供其他相應程序接入。他創辦了一家公司Teknekron，實現了世界上第一個消息中間件The Information Bus(TIB)

各自為戰

2.TIB受到了企業的歡迎，Teknekron的業務發展引起了當時最牛氣的IT公司IBM的注意，于是他們也開始研發了自己消息隊列軟件，于是才有了后來的wesphere mq，微軟也陸續加入了戰團。由于商業壁壘，商業MQ供應商想要解決應用應用互通的問題，而不是去創建標準來實現不同MQ產品間的互通，或者允許應用程序更改MQ平臺

劫制天下

3.為了打破這個壁壘，同時為了能夠讓消息在各個消息隊列平臺間互融互通， JMS (Java Message Service) 應運而生 。JMS 試圖通過提供公共 Java API 的方式，隱藏單獨 MQ 產品供應 商提供的實際接口，從而跨越了壁壘，以及解決了互通問題。從技術上講， Java 應用程序只需 針對 JMS API 編程，選擇合適的 MQ 驅動即可， JMS 會打理好其他部分 。ActiveMQ 就是 JMS 的 一種實現 。不過嘗試使用單獨標準化接口來膠合眾多不同的接口，最終會暴露出問題，使得 應用程序變得更加脆弱 。所以急需一種新的消息通信標準化方案 。

一統江湖

4.在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等聯合制定了 AMQP 的公開標準，由此 AMQP 登上了歷史的舞臺 。它是應用層協議的一個開放標準，以解決眾多消息中間件的需求和拓撲結 構問題 。它為面向消息的中間件設計，基于此協議的客戶端與消息中間件可傳遞消息，并不受 產品、開發語言等條件的限制 。

合久必分

5.LinkedIn在實現消息隊列的時候覺得AMQP規范并不適合自己，所以Kafka并不支持AMQP協議。RocketMQ在實現上借鑒了Kakfa的思想，所以也不支持AMQP協議，并且你會發現在Kafka和RocketMQ中都有類似Topic和Consumer Group的概念，而這些概念在AMQP協議中是不存在的

 

如何選擇消息中間件

 

1. ActiveMQ 的社區算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。
2. RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ，但是由于它基于 erlang 開發，所以并發能力很強，性能極其好，延時很低，達到微秒級。但是也因為 RabbitMQ 基于 erlang 開發，所以國內很少有公司有實力做erlang源碼級別的研究和定制。如果業務場景對并發量要求不是太高(十萬級、百萬級)，那這四種消息隊列中，RabbitMQ 一定是你的首選。如果是大數據領域的實時計算、日志采集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范。
3. RocketMQ 阿里出品，Java 系開源項目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些。
4. Kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展。同時 Kafka 最好是支撐較少的 topic 數量即可，保證其超高吞吐量。Kafka 唯一的一點劣勢是有可能消息重復消費，那么對數據準確性會造成極其輕微的影響，在大數據領域中以及日志采集中，這點輕微影響可以忽略。Kafka天然適合大數據實時計算以及日志收集。

 

消息模型

如果讓你設計一個消息隊列?你會怎么實現呢?

可能你立馬就會想到用隊列，一邊放，一邊取。這其實就是消息隊列常見的一種消息模型，隊列模型

 

所以一個簡單的消息隊列用Redis中的List就能實現。當然Redis5.0版本之后針對消息隊列這種場景專門設計了一個數據結構Streams。

隊列模型有哪些缺點呢?

如果將一類消息發送給不同的消費者，每個消費者都要接收全量的消息，此時就很不方便。因為你要將相同的消息發送到不同的隊列，多一個消費者就得多發一份隊列。這樣生產者必須知道有多少個消費者，不利于解耦。

那么該如何解決這個問題呢?

想想RabbitMQ的結構圖

 

RabbitMQ并不是直接把消息發送到隊列中的，而是發送到Exchange中，Exchange和Queue進行關聯，消息由Exchange根據規則發送到對應的隊列。這樣生產者和消費者完成了解耦。

還有哪種方式能解決這種多消費者的問題呢?

答對了，就是發布訂閱模型

 

RocketMQ和Kafka都是基于發布訂閱模型實現的，RocketMQ的消息模型圖如下

 

生產者是發布者，消費者是訂閱者，消息是主題

為了提高消費的并行度，一類消息會被分發到多個隊列中，在RocketMQ中叫Queue，在Kafka中叫做Partition(分區)，都是類似的概念。

AMQP協議詳解

前面說到消息中間件有2種協議，JMS和AMQP。JMS你可以類比為JDBC，搞了一套接口讓不同廠商來實現這個接口，但是這個協議設計的確實不夠優雅，因此就不介紹這個協議了，除非你用ActiveMQ，不然學了真沒啥用。詳細說一下AMQP協議，畢竟現在用RabbitMQ的公司還是很多的，要想學好RabbitMQ，AMQP協議是必須要清楚的。

AMQP協議模型

 

上圖是AMQP協議中一個消息的流轉過程，畫的的很清楚，不詳細介紹了。

AMQP核心概念介紹一些AMQP協議常見的概念。

概念解釋

概念	解釋
Server	又稱Broker，接受客戶端的連接，實現AMQP實體服務
Connection	一個網絡連接，比如TCP/IP套接字連接
Channel	多路復用連接中的一條獨立的雙向數據流通道。為會話提供物理傳輸介質
Message	消息，服務器和應用程序之間傳送的數據，由Properties和Body組成。Properties可以對消息進行修飾，比如消息的優先級，延遲等高級特性，Body則就是消息體內容
Virtual Host	虛擬地址，用于進行邏輯隔離，最上層的消息路由。一個Virtual Host里面可以有若干個Exchange和Queue，同一個Virtual Host里面不能有相同名稱的Exchange或Queue
Binding	消息隊列和交換器之間的關聯
Routing Key	一個消息頭，交換器可以用這個消息頭決定如何路由某條消息
Message Queue	消息隊列，用來保存消息直到發送給消費者

 

如果有用過ActiveMQ和RabbitMQ，對上面的名詞一定不會陌生。后面一篇文章就結合RabbitMQ來闡述上面的概念。

本文轉載自微信公眾號「Java識堂」，可以通過以下二維碼關注。轉載本文請聯系Java識堂公眾號。