背景知識(shí)

JMS一個(gè)在 Java標(biāo)準(zhǔn)化組織（JCP）內(nèi)開(kāi)發(fā)的標(biāo)準(zhǔn)（代號(hào)JSR 914）。2001年6月25日，Java消息服務(wù)發(fā)布JMS 1.0.2b，2002年3月18日J(rèn)ava消息服務(wù)發(fā)布 1.1.

Java消息服務(wù)（Java Message Service，JMS）應(yīng)用程序接口是一個(gè)Java平臺(tái)中關(guān)于面向消息中間件（MOM）的API，用于在兩個(gè)應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。 

點(diǎn)對(duì)點(diǎn)與發(fā)布訂閱最初是由JMS定義的。這兩種模式主要區(qū)別或解決的問(wèn)題就是發(fā)送到隊(duì)列的消息能否重復(fù)消費(fèi)(多訂閱)

1.JMS中定義

JMS規(guī)范目前支持兩種消息模型：點(diǎn)對(duì)點(diǎn)（point to point， queue）和發(fā)布/訂閱（publish/subscribe，topic）。 

點(diǎn)對(duì)點(diǎn)

• 消息生產(chǎn)者生產(chǎn)消息發(fā)送到queue中，然后消息消費(fèi)者從queue中取出并且消費(fèi)消息。這里要注意：
• 消息被消費(fèi)以后，queue中不再有存儲(chǔ)，所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。
• Queue支持存在多個(gè)消費(fèi)者，但是對(duì)一個(gè)消息而言，只會(huì)有一個(gè)消費(fèi)者可以消費(fèi)。 

發(fā)布/訂閱

• 消息生產(chǎn)者（發(fā)布）將消息發(fā)布到topic中，同時(shí)有多個(gè)消息消費(fèi)者（訂閱）消費(fèi)該消息。
• 和點(diǎn)對(duì)點(diǎn)方式不同，發(fā)布到topic的消息會(huì)被所有訂閱者消費(fèi)。

2.二者分析與區(qū)別

2.1 點(diǎn)對(duì)點(diǎn)模式

生產(chǎn)者發(fā)送一條消息到queue，只有一個(gè)消費(fèi)者能收到。

2.2 發(fā)布訂閱模式

發(fā)布者發(fā)送到topic的消息，只有訂閱了topic的訂閱者才會(huì)收到消息。

小結(jié)

• queue實(shí)現(xiàn)了負(fù)載均衡，一個(gè)消息只能被一個(gè)消費(fèi)者接受，當(dāng)沒(méi)有消費(fèi)者可用時(shí)，這個(gè)消息會(huì)被保存直到有 一個(gè)可用的消費(fèi)者，一個(gè)queue可以有很多消費(fèi)者，他們之間實(shí)現(xiàn)了負(fù)載均衡，所以Queue實(shí)現(xiàn)了一個(gè)可靠的負(fù)載均衡。
• topic實(shí)現(xiàn)了發(fā)布和訂閱，當(dāng)你發(fā)布一個(gè)消息，所有訂閱這個(gè)topic的服務(wù)都能得到這個(gè)消息，所以從1到N個(gè)訂閱者都能得到一個(gè)消息的拷貝，只有在消息代理收到消息時(shí)有一個(gè)有效訂閱時(shí)的訂閱者才能得到這個(gè)消息的拷貝。

疑問(wèn)

• 發(fā)布訂閱模式下，能否實(shí)現(xiàn)訂閱者負(fù)載均衡消費(fèi)呢？當(dāng)發(fā)布者消息量很大時(shí)，顯然單個(gè)訂閱者的處理能力是不足的。實(shí)際上現(xiàn)實(shí)場(chǎng)景中是多個(gè)訂閱者節(jié)點(diǎn)組成一個(gè)訂閱組負(fù)載均衡消費(fèi)topic消息，即分組訂閱（如下圖所示），這樣訂閱者很容易實(shí)現(xiàn)消費(fèi)能力線(xiàn)性擴(kuò)展。

3.流行的消息隊(duì)列模型比較

傳統(tǒng)企業(yè)型消息隊(duì)列ActiveMQ遵循了JMS規(guī)范，實(shí)現(xiàn)了點(diǎn)對(duì)點(diǎn)和發(fā)布訂閱模型，但其他流行的消息隊(duì)列RabbitMQ、Kafka并沒(méi)有遵循老態(tài)龍鐘的JMS規(guī)范，是通過(guò)什么方式實(shí)現(xiàn)消費(fèi)負(fù)載均衡、多訂閱呢？

3.1 RabbitMQ

RabbitMQ實(shí)現(xiàn)了AQMP協(xié)議，AQMP協(xié)議定義了消息路由規(guī)則和方式。生產(chǎn)端通過(guò)路由規(guī)則發(fā)送消息到不同queue，消費(fèi)端根據(jù)queue名稱(chēng)消費(fèi)消息。此外RabbitMQ是向消費(fèi)端推送消息，訂閱關(guān)系和消費(fèi)狀態(tài)保存在服務(wù)端。

生產(chǎn)端發(fā)送一條消息通過(guò)路由投遞到Queue，只有一個(gè)消費(fèi)者能消費(fèi)到。

當(dāng)RabbitMQ需要支持多訂閱時(shí)，發(fā)布者發(fā)送的消息通過(guò)路由同時(shí)寫(xiě)到多個(gè)Queue，不同訂閱組消費(fèi)此消息。 

RabbitMQ既支持內(nèi)存隊(duì)列也支持持久化隊(duì)列，消費(fèi)端為推（push）模型，消費(fèi)狀態(tài)和訂閱關(guān)系由服務(wù)端負(fù)責(zé)維護(hù)，消息消費(fèi)完后立即刪除，不保留歷史消息。所以支持多訂閱時(shí)，消息會(huì)多個(gè)拷貝。

3.2 Kafka

Kafka只支持消息持久化，消費(fèi)端為拉（pull）模型，消費(fèi)狀態(tài)和訂閱關(guān)系由客戶(hù)端端負(fù)責(zé)維護(hù)，消息消費(fèi)完后不會(huì)立即刪除，會(huì)保留歷史消息。因此支持多訂閱時(shí)，消息只會(huì)存儲(chǔ)一份就可以了。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論