目錄
集群消費
廣播消費
使用集群消費模擬廣播消費
首先明確一點,rocketmq 是基於發布訂閱模型的訊息中介軟體。所謂的發布訂閱就是說,consumer 訂閱了 broker 上的某個 topic,當 producer 發布訊息到 broker 上的該 topic 時,consumer 就能收到該條訊息。
之前我們講過 consumer group 的概念,即消費同一類訊息的多個 consumer 例項組成乙個消費者組,也可以稱為乙個 consumer 集群,這些 consumer 例項使用同乙個 group name。需要注意一點,除了使用同乙個 group name,訂閱的 tag 也必須是一樣的,只有符合這兩個條件的 consumer 例項才能組成 consumer 集群。
當 consumer 使用集群消費時,每條訊息只會被 consumer 集群內的任意乙個 consumer 例項消費一次。舉個例子,當乙個 consumer 集群內有 3 個consumer 例項(假設為consumer 1、consumer 2、consumer 3)時,一條訊息投遞過來,只會被consumer 1、consumer 2、consumer 3中的乙個消費。
同時記住一點,使用集群消費的時候,consumer 的消費進度是儲存在 broker 上,consumer 自身是不儲存消費進度的。訊息進度儲存在 broker 上的好處在於,當你 consumer 集群是擴大或者縮小時,由於消費進度統一在broker上,訊息重複的概率會被大大降低了。
注意:在集群消費模式下,並不能保證每一次訊息失敗重投都投遞到同乙個 consumer 例項。
當 consumer 使用廣播消費時,每條訊息都會被 consumer 集群內所有的 consumer 例項消費一次,也就是說每條訊息至少被每乙個 consumer 例項消費一次。舉個例子,當乙個 consumer 集群內有 3 個 consumer 例項(假設為 consumer 1、consumer 2、consumer 3)時,一條訊息投遞過來,會被 consumer 1、consumer 2、consumer 3都消費一次。
與集群消費不同的是,consumer 的消費進度是儲存在各個 consumer 例項上,這就容易造成訊息重複。還有很重要的一點,對於廣播消費來說,是不會進行消費失敗重投的,所以在 consumer 端消費邏輯處理時,需要額外關注消費失敗的情況。
雖然廣播消費能保證集群內每個 consumer 例項都能消費訊息,但是消費進度的維護、不具備訊息重投的機制大大影響了實際的使用。因此,在實際使用中,更推薦使用集群消費,因為集群消費不僅擁有消費進度儲存的可靠性,還具有訊息重投的機制。而且,我們通過集群消費也可以達到廣播消費的效果。
如果業務上確實需要使用廣播消費,那麼我們可以通過建立多個 consumer 例項,每個 consumer 例項屬於不同的 consumer group,但是它們都訂閱同乙個 topic。舉個例子,我們建立 3 個 consumer 例項,consumer 1(屬於consumer group 1)、consumer 2(屬於 consumer group 2)、consumer 3(屬於consumer group 3),它們都訂閱了 topic a ,那麼當 producer 傳送一條訊息到 topic a 上時,由於 3 個consumer 屬於不同的 consumer group,所以 3 個consumer都能收到訊息,也就達到了廣播消費的效果了。 除此之外,每個 consumer 例項的消費邏輯可以一樣也可以不一樣,每個consumer group還可以根據需要增加 consumer 例項,比起廣播消費來說更加靈活。
RocketMQ 廣播消費模式與集群消費模式
rocketmq有兩種消費模式 broadcasting廣播模式,clustering集群模式,預設的是 集群消費模式。廣播消費指的是 一條訊息被多個consumer消費,即使這些consumer屬於同乙個consumergroup,訊息也會被consumergroup中的每個consumer都消費...
RocketMQ的兩種消費模式和重置消費位點
消費模式 第一種 消費者為同乙個組下的,訂閱的是同乙個topic和tag的情況 這樣的就是消費者組成了乙個集群,有多個例項,之後就是topic中的訊息只會被這些例項中的其中乙個消費 第二種 多個不同組的消費者訂閱同乙個topic和tag的情況 這樣的就是所謂的廣播模式,每個消費者都會接收到topic...
rocketmq 順序消費
org.apache.rocketmq rocketmq spring boot starter 2.0.3 有序訊息需要生產者,消費者一起配合,生產者要保證每次訊息都要投遞到broker的同乙個佇列裡,消費者需要設定 關鍵點 生產這傳送 同步訊息且指定佇列 syncsendorderly 消費者指...