Kafka下的生產消費者模式與訂閱發布模式

2022-02-06 11:38:45 字數 1928 閱讀 5823

原文:

在rabbitmq下的生產消費者模式與訂閱發布模式一文中,筆者以「資料接入」和「事件分發」兩種場景為例,介紹了如何使用rabbitmq來設計、實現生產消費者模式與訂閱發布模式。生產消費者模式,指的是由生產者將資料源源不斷推送到訊息中心,由不同的消費者從訊息中心取出資料做自己的處理,在同一類別下,所有消費者拿到的都是同樣的資料;訂閱發布模式,本質上也是一種生產消費者模式,不同的是,由訂閱者首先向訊息中心指定自己對哪些資料感興趣,發布者推送的資料經過訊息中心後,每個訂閱者拿到的僅僅是自己感興趣的一組資料。這兩種模式是使用訊息中介軟體時最常用的,用於功能解耦和分布式系統間的訊息通訊。 

本文將繼續以「資料接入」和「事件分發」這兩個場景為例,來**kafka作為訊息系統的應用方法(high level)。搞清楚kafka的基本概念和應用方法是進行系統方案設計的前提,編寫**只是具體落地實施,而解決bug和效能調優是系統跑起來之後的事情了。需要指出的是,本文重點是**應用方法,具體應用時需要根據自身需求來做調整,沒有任何技術方案是萬能的。 

為了方便閱讀,筆者首先重複一下這兩種場景:

這樣做的好處有:第一,功能分離,上報的api介面不關心資料處理功能,只負責接入資料;第二,資料緩衝,資料上報的速率是不可控的,取決於使用者使用頻率,採用該模式可以一定程度地緩衝資料;第三,易於擴充套件,在資料量大時,通過增加資料處理worker來擴充套件,提高處理速率。這便是典型的生產消費者模式,資料上報為生產者,資料處理為消費者。

事件分發 

假設有乙個電商系統,那麼,使用者「收藏」、「下單」、「付款」等行為都是非常重要的事件,通常後端服務在完成相應的功能處理外,還需要在這些事件點上做很多其他處理動作,比如傳送簡訊通知、記錄使用者積分等等。我們可以將這些額外的處理動作放到每個模組中,但這並不是優雅的實現,不利於功能解耦和**維護。 

我們需要的是乙個事件分發系統,在各個功能模組中將對應的事件發布出來,由對其感興趣的處理者進行處理。這裡涉及兩個角色:a對b感興趣,a是處理者,b是事件,由事件處理器完成二者的繫結,並向訊息中心訂閱事件。服務模組是後端的業務邏輯服務,在不同的事件點發布事件,事件經過訊息中心分發給事件處理器對應的處理者。整個流程如下圖所示。這邊是典型的訂閱發布模式。

kafka基本概念

kafka是乙個分布式流資料系統,使用zookeeper進行集群的管理。與其他訊息系統類似,整個系統由生產者、broker server和消費者三部分組成,生產者和消費者由開發人員編寫,通過api連線到broker server進行資料操作。我們重點關注三個概念:

生產消費者模式

搞清楚了kafka的基本概念後,我們來看如何設計生產消費者模式來實現上述的「資料接入」場景。在下圖中,由producer負責接收前端上報的資料,投遞到對應的topic中(這裡忽略了broker server的細節),在consumer端,所有對該資料感興趣的業務都可以建立自己的group來消費資料,至於group內部開多少個worke來消費完全取決於資料量和業務的實時性要求了。 

訂閱發布模式

再來看「事件分發」的場景,假如我們有「收藏」、「下單」、「付款」三個事件,業務一對「收藏」和「下單」事件感興趣,而業務二對「下單」和「付款」事件感興趣,那麼我們如何進行事件訂閱?不同於rabbitmq中有資料路由機制(routing key),可以將感興趣的事件繫結到自己的queue上,kafka只提供了單播和廣播的訊息模型,無法直接進行消費物件的繫結,所以理論上kafka是不適合做此種場景下的訂閱發布模式的,如果一定要做,有這麼幾個方案:

Kafka下的生產消費者模式與訂閱發布模式

在rabbitmq下的生產消費者模式與訂閱發布模式一文中,筆者以 資料接入 和 事件分發 兩種場景為例,介紹了如何使用rabbitmq來設計 實現生產消費者模式與訂閱發布模式。生產消費者模式,指的是由生產者將資料源源不斷推送到訊息中心,由不同的消費者從訊息中心取出資料做自己的處理,在同一類別下,所有...

Kafka下的生產消費者模式與訂閱發布模式

在rabbitmq下的生產消費者模式與訂閱發布模式一文中,筆者以 資料接入 和 事件分發 兩種場景為例,介紹了如何使用rabbitmq來設計 實現生產消費者模式與訂閱發布模式。生產消費者模式,指的是由生產者將資料源源不斷推送到訊息中心,由不同的消費者從訊息中心取出資料做自己的處理,在同一類別下,所有...

Kafka下的生產消費者模式與訂閱發布模式

僅供學習 這樣做的好處有 第一,功能分離,上報的api介面不關心資料處理功能,只負責接入資料 第二,資料緩衝,資料上報的速率是不可控的,取決於使用者使用頻率,採用該模式可以一定程度地緩衝資料 第三,易於擴充套件,在資料量大時,通過增加資料處理worker來擴充套件,提高處理速率。這便是典型的生產消費...