MQ訊息中介軟體在分散式系統中的作用(四)
1.訊息中介軟體在分散式系統中的作用介紹
訊息中介軟體是在分散式系統中完成訊息的傳送和接收的基礎軟體。
1.1訊息中介軟體可利用高效可靠的訊息傳遞機制進行平臺無關的資料交流,
並基於資料通訊來進行分散式系統的整合。通過提供訊息傳遞和訊息
排隊模型,可以在分散式環境下擴充套件程序間的通訊。
通過訊息中介軟體,應用程式或元件之間可以進行可靠的非同步通訊,從而
降低系統之間的耦合度,提高系統的可擴充套件性和可用性。
1.2通過使用訊息中介軟體對Dubbo服務間的呼叫進行解耦
總結:
1.分散式服務間的非同步通訊
2.對Dubbo服務間的呼叫進行解耦
3.通過非同步提高程式響應速度
非同步通訊、解耦、併發緩衝
訊息中介軟體使用的典型場景優四個
1.典型的非同步處理
2.應用解耦
3.流量削鋒
4.訊息通訊四個場景
2.JMS(Java Message Service)
JMS是JavaEE中的一個關於訊息的規範,是一套與具體平臺無關的API。
JMS元素
JMS提供者----連接面向訊息中介軟體的,JMS介面的一個實現。
JMS客戶------生產或消費訊息的基於Java的應用程式或物件。
JMS生產者----建立併發送訊息的JMS客戶。
JMS消費者----接收訊息的JMS客戶。
JMS訊息------可以在JMS客戶之間傳遞的資料的物件
JMS佇列------一個容納那些被髮送的等待閱讀的訊息的區域。
JMS主題------一種支援傳送訊息給多個訂閱者的機制。
JMS應用程式介面
ConnectionFactory(連線工廠)------使用者用來建立到JMS提供者的連線的被管物件。
Connection(連線)-------------------連線代表了應用程式和訊息伺服器之間的通訊鏈路。
Destination(目標)-------------------訊息釋出和接收的地點,或者是佇列,或者是主題。
MessageProducer(訊息生產者)-----由會話建立的物件,用於傳送訊息到目標。
MessageConsumer(訊息消費者)----由會話建立的物件,用於接收發送到目標的訊息。
Message(訊息)----------------------是在消費者和生產者之間傳送的物件。
Session(會話)------------------------表示一個單執行緒的上下文,用於傳送和接收訊息。
2.1JMS訊息模型
1、點對點或佇列模型
JMS 點對點佇列模型特點:
1、訊息生產者生產訊息傳送到queue中,然後訊息消費者從queue中取出並且消費訊息。
2、訊息被消費以後,queue中不再有儲存,所以訊息消費者不可能消費到已經被消費的訊息。
3、Queue支援存在多個消費者,但是對一個訊息而言,只會有一個消費者可以消費。
2、釋出者/訂閱者模型
JMS 釋出/訂閱模型特點:
訊息生產者(釋出)將訊息釋出到topic中,同時有多個訊息消費者(訂閱)消費該訊息。
釋出到topic的訊息會被所有訂閱者消費。
3.MQ對比與選擇
實現了JMS規範的訊息中介軟體產品
ActiveMQ、RocketMQ、RabbitMQ、HornetQ……
ActiveMQ |
RabbitMQ |
RocketMq |
Joram |
HornetQ |
OpenMQ |
MuleMQ |
SonicMQ |
ZeroMQ |
|
關注度 |
高 |
高 |
中 |
中 |
中 |
中 |
低 |
低 |
中 |
成熟度 |
成熟 |
成熟 |
比較成熟 |
比較成熟 |
比較成熟 |
比較成熟 |
新產品無成功案例 |
成熟 |
不成熟 |
所屬社群/公司 |
Apache |
Mozilla Public License |
Alibaba |
OW2 |
Jboss |
Sun |
Mule |
Progress |
|
社群活躍度 |
高 |
高 |
中 |
中 |
中 |
低 |
高 |
低 |
低 |
文件 |
多 |
多 |
中 |
多 |
中 |
中 |
少 |
少 |
中 |
特點 |
功能齊全,被大量開源專案使用 |
由於Erlang 語言的併發能力,效能很好 |
各個環節分散式擴充套件設計,主從 HA;支援上萬個佇列;多種消費模式;效能很好 |
在 Linux 平臺上直接呼叫作業系統的 AIO,效能得到很大的提升 |
效能非常 好,與 MuleESB 無縫整合 |
效能優越的商業 MQ |
低延時,高效能,最高 43萬條訊息每秒 |
||
授權方式 |
開源 |
開源 |
開源 |
開源 |
開源 |
開源 |
商業 |
商業 |
開源 |
開發語言 |
Java |
Erlang |
Java |
Java |
Java |
Java |
Java |
Java |
C |
支援的協議 |
OpenWire、 STOMP、 REST、XMPP、 AMQP |
AMQP |
自己定義的一 套(社群提供 JMS--不成熟) |
JMS |
JMS |
JMS |
JMS |
JMS |
TCP、UDP |
客戶端支援語言 |
Java、C、 C++、 Python、 PHP、 Perl、.net等 |
Java、C、 C++、 Python、 PHP、Perl 等 |
Java C++(不成熟) |
Java |
Java |
Java |
Java |
Java、C、 C++、.net |
python、 java、 php、.net 等 |
持久化 |
記憶體、檔案、資料庫 |
記憶體、檔案 |
磁碟檔案 |
記憶體、檔案 |
記憶體、檔案 |
記憶體、檔案 |
記憶體、檔案 |
記憶體、檔案、資料庫 |
在訊息傳送端儲存 |
事務 |
支援 |
不支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
不支援 |
叢集 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
不支援 |
負載均衡 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
支援 |
不支援 |
管理介面 |
一般 |
好 |
無社群有 web console 實現 |
一般 |
無 |
一般 |
一般 |
好 |
無 |
部署方式 |
獨立、嵌入 |
獨立 |
獨立 |
獨立、嵌入 |
獨立、嵌入 |
獨立、嵌入 |
獨立 |
獨立 |
獨立 |
評價 |
優點: 成熟的產品,已經在很多公司得到應用(非大規模場景)。有較多的文件。各種協議支援較好,有多重語言的成熟的客戶端;缺點: 根據其他使用者反饋,會出莫名其妙的問題,切會丟 失訊息。 其重心放到 activemq6.0 產品—apollo上去了,目前社群不活躍,且對 5.x 維護較少; Activemq 不適合用於上千個佇列的應用場景 |
優點: 由於 erlang語言的特性,mq效能較好;管理介面較豐富,在網際網路公司也有較大規模的應用;支援amqp系誒,有多中語言且支援 amqp 的客 戶端可用 缺點: erlang語言難度較 大。叢集不支援動態擴充套件。 |
優點: 模型簡單,介面易用(JMS的介面很多場合並不太實 用)。在阿里大規模應用。目前支付寶中的餘額寶等新興產 品均使用 rocketmq。叢集規模大概在 50 臺左右,單日處理訊息上 百億;效能非常好,可以大量堆 積訊息在 broker 中;支援多種消費,包括叢集消費、廣播消費等。開發度較活躍,版本 更新很快。 缺點: 產品較新,文件比較缺乏。 沒有在 mq 核心中去實現JMS 等介面,對已有系統而言不能相容。阿里內部還有一套未開源 的 MQ API,這一層API可以將上層應用和下層 MQ 的實現解耦(阿里內部有多個mq的實現,如 notify、 |
||||||
metaq1.x, metaq2.x, rocketmq 等),使得下面mq可以很方便的進行切換和升級而對應用無任何影響,目前這一套東西未開源 |