最基礎(chǔ)的分布式隊列編程抽象模型是點對點模型，其他抽象構(gòu)架模型居于改基本模型上各角色的數(shù)量和交互變化所導(dǎo)致的不同拓?fù)鋱D。具體而言，不同數(shù)量的發(fā)送者、分布式隊列以及接收者組合形成了不同的分布式隊列編程模型。消息中間件的主要功能是**消息的路由(Routing)和緩存(Buffering)**。Java Message Service，**JMS**，指的是面向消息中間件（MOM），用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。JMS中定義了兩種消息模型：**點對點**（point to point， queue）和**發(fā)布/訂閱**（publish/subscribe，topic），主要區(qū)別就是是否能重復(fù)消費(fèi)。

1、點對點：Queue，不可重復(fù)消費(fèi)

1、消息生產(chǎn)者生產(chǎn)消息發(fā)送到queue中，然后消息消費(fèi)者從queue中取出并且消費(fèi)消息。
2、消息被消費(fèi)以后，queue中不再有存儲，所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。
Queue支持存在多個消費(fèi)者，但是對一個消息而言，只會有一個消費(fèi)者可以消費(fèi)。
注：Kafka不遵守JMS協(xié)議，所以Kafka實際應(yīng)用中，很可能會需要ack，然后多個消費(fèi)者能夠會同時消費(fèi)。。需要具體看。

2、發(fā)布/訂閱：Topic，可以重復(fù)消費(fèi)

消息生產(chǎn)者（發(fā)布）將消息發(fā)布到topic中，同時有多個消息消費(fèi)者（訂閱）消費(fèi)該消息。

和點對點方式不同，發(fā)布到topic的消息會被所有訂閱者消費(fèi)。

基于訂閱組的發(fā)布訂閱模式

發(fā)布訂閱模式下，當(dāng)發(fā)布者消息量很大時，顯然單個訂閱者的處理能力是不足的。

實際上現(xiàn)實場景中是多個訂閱者節(jié)點組成一個訂閱組負(fù)載均衡消費(fèi)topic消息即分組訂閱，這樣訂閱者很容易實現(xiàn)消費(fèi)能力線性擴(kuò)展。

3、推、拉模型

對于消費(fèi)者而言有兩種方式從消息中間件獲取消息：

• Push方式：由消息中間件主動地將消息推送給消費(fèi)者；
• **Pull方式：**由消費(fèi)者主動向消息中間件拉取消息。

兩種方式比較：

• 采用Push方式，可以盡可能快地將消息發(fā)送給消費(fèi)者，缺點是如果消費(fèi)者的處理消息的能力很弱(一條消息需要很長的時間處理)，而消息中間件不斷地向消費(fèi)者Push消息，消費(fèi)者的緩沖區(qū)可能會溢出。
• 而采用Pull方式，雖然能解決Push方式的缺點，但會增加消息的延遲，即消息到達(dá)消費(fèi)者的時間有點長。

例如：Kafka的消費(fèi)端就是采用Pull方式，而RabbitMQ的消費(fèi)端采用的是Push模式。

參考：https://www.cnblogs.com/charlesblc/p/6045238.html

總結(jié)

以上是生活随笔為你收集整理的Kafka：分布式消息队列的抽象模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。