消息總線和消息隊列區(qū)別？消息總線包含多個消息隊列，即接收到所有消息，內(nèi)部邏輯決定推送到哪個消息隊列。消息隊列的發(fā)布訂閱原理？訂閱的原理是不同系統(tǒng)之間的重合。Java消息服務(wù)(JMS)應(yīng)用程序接口是Ja

消息總線和消息隊列區(qū)別？

消息總線包含多個消息隊列，即接收到所有消息，內(nèi)部邏輯決定推送到哪個消息隊列。

消息隊列的發(fā)布訂閱原理？

訂閱的原理是不同系統(tǒng)之間的重合。Java消息服務(wù)(JMS)應(yīng)用程序接口是Java平臺上關(guān)于消息中間件(MOM)的API，用于在兩個應(yīng)用程序之間或分布式系統(tǒng)中發(fā)送消息以進行異步通信。

對等訂閱和發(fā)布訂閱最初是由JMS定義的。兩種模式的主要區(qū)別或者說要解決的問題是，發(fā)送到隊列的消息是否可以重復(fù)消費(多訂閱)。

1.定義

JMS規(guī)范目前支持兩種消息模型:點對點(隊列)和發(fā)布/訂閱(主題)。

1.1.點對點:隊列，不能重復(fù)消費。

消息生產(chǎn)者產(chǎn)生消息并將其發(fā)送到隊列，然后消息消費者將消息從隊列中取出并使用它們。

消息被消費后，隊列中沒有存儲，所以消息消費者不可能消費已經(jīng)消費的消息。隊列支持多個使用者的存在，但是只有一個使用者可以使用一條消息。

1.2.發(fā)布/訂閱:話題，可以反復(fù)消費。

消息生產(chǎn)者(發(fā)布者)將消息發(fā)布到主題，同時，多個消息消費者(訂閱者)消費該消息。與對等模式不同，發(fā)布到主題的消息將由所有訂閱者使用。

支持訂閱組的發(fā)布-訂閱模式:

在發(fā)布-訂閱模式下，當(dāng)發(fā)布者的消息量較大時，單個訂閱者的處理能力明顯不足。實際上，在真實場景中，多個訂閱者節(jié)點組成一個訂閱群來負載均衡話題消息的消費，即群訂閱，這樣訂閱者就可以輕松實現(xiàn)消費力的線性膨脹?？梢钥吹?，一個主題下有多個隊列，每個隊列都是點對點的，隊列都是發(fā)布訂閱的。

2.差異

2.1.點對點模式

生產(chǎn)者向隊列發(fā)送消息。一個隊列可以有許多消費者，但是一條消息只能被一個消費者接受。當(dāng)沒有可用的消費者時，消息將被保存直到有可用的消費者，因此隊列實現(xiàn)了可靠的負載平衡。

2.2.發(fā)布-訂閱模式

發(fā)布者向主題發(fā)送的消息將僅由訂閱主題的訂閱者接收。話題實現(xiàn)發(fā)布和訂閱。當(dāng)您發(fā)布消息時，訂閱該主題的所有服務(wù)都可以獲得該消息，因此1到n個訂閱者可以獲得該消息的副本。

3.熱門車型對比

傳統(tǒng)的企業(yè)消息隊列ActiveMQ遵循JMS規(guī)范，實現(xiàn)點對點。點和發(fā)布訂閱模型，但是其他流行的消息隊列RabbitMQ和Kafka不遵循JMS規(guī)范。

3.1、RabbitMQ

RabbitMQ實現(xiàn)了AQMP協(xié)議，該協(xié)議定義了消息路由的規(guī)則和方法。生產(chǎn)者通過路由規(guī)則將消息發(fā)送到不同的隊列，消費者根據(jù)隊列名稱消費消息。

RabbitMQ支持內(nèi)存隊列和持久隊列，消費者是一個推模型。服務(wù)器負責(zé)維護消費狀態(tài)和訂閱關(guān)系，消費后立即刪除消息，不保留歷史消息。

(1)點對點

生產(chǎn)者通過路由向隊列發(fā)送消息，只有一個消費者可以消費它。

(2)更多訂閱

當(dāng)RabbitMQ需要支持多個訂閱時，發(fā)布者發(fā)送的消息通過路由同時寫入多個隊列，不同的訂閱組消耗不同的隊列。因此，當(dāng)支持多個訂閱時，消息將被復(fù)制多次。

3.2、卡夫卡

Kafka只支持消息持久化，消費者是拉模型，客戶端負責(zé)維護消費狀態(tài)和訂閱關(guān)系。消息消費后，不會立即刪除，但會保留歷史消息。因此，當(dāng)支持多個訂閱時，將只存儲一條消息。但是可能會有重復(fù)消費。

(1)點對點amp多訂閱

發(fā)布者在主題中生成一條消息，不同的訂閱組使用這條消息。