僅供學習
這樣做的好處有：第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料；第二，資料緩衝，資料上報的速率是不可控的，取決於使用者使用頻率，採用該模式可以一定程度地緩衝資料；第三，易於擴充套件，在資料量大時，通過增加資料處理worker來擴充套件，提高處理速率。這便是典型的生產消費者模式，資料上報為生產者，資料處理為消費者。
事件分發
假設有乙個電商系統，那麼，使用者「收藏」、「下單」、「付款」等行為都是非常重要的事件，通常後端服務在完成相應的功能處理外，還需要在這些事件點上做很多其他處理動作，比如傳送簡訊通知、記錄使用者積分等等。我們可以將這些額外的處理動作放到每個模組中，但這並不是優雅的實現，不利於功能解耦和**維護。
我們需要的是乙個事件分發系統，在各個功能模組中將對應的事件發布出來，由對其感興趣的處理者進行處理。這裡涉及兩個角色：a對b感興趣，a是處理者，b是事件，由事件處理器完成二者的繫結，並向訊息中心訂閱事件。服務模組是後端的業務邏輯服務，在不同的事件點發布事件，事件經過訊息中心分發給事件處理器對應的處理者。整個流程如下圖所示。這邊是典型的訂閱發布模式。
partition，是kafka下資料儲存的基本單元，這個是物理上的概念。同乙個topic的資料，會被分散的儲存到多個partition中，這些partition可以在同一臺機器上，也可以是在多台機器上，比如下圖所示的topic就有4個partition，分散在兩台機器上。這種方式在大多數分布式儲存中都可以見到，比如mongodb、elasticsearch的分片技術，其優勢在於：有利於水平擴充套件，避免單台機器在磁碟空間和效能上的限制，同時可以通過複製來增加資料冗餘性，提高容災能力。為了做到均勻分布，通常partition的數量通常是broker server數量的整數倍。
consumer group，同樣是邏輯上的概念，是kafka實現單播和廣播兩種訊息模型的手段。同乙個topic的資料，會廣播給不同的group；同乙個group中的worker，只有乙個worker能拿到這個資料。換句話說，對於同乙個topic，每個group都可以拿到同樣的所有資料，但是資料進入group後只能被其中的乙個worker消費。group內的worker可以使用多執行緒或多程序來實現，也可以將程序分散在多台機器上，worker的數量通常不超過partition的數量，且二者最好保持整數倍關係，因為kafka在設計時假定了乙個partition只能被乙個worker消費（同一group內）。
方案二：把每個事件的資料推送到不同的topic中，即以事件名稱來作為topic分類，在consumer端，建立自己的group來消費自己感興趣的一組topic。這種方式適用於事件個數可以明確評估並且數量較少，如果事件種類很多，會導致topic的數量過多，建立過多的topic和partition則會影響到kafka的效能，因為kafka的每個topic、每個分割槽都會對應乙個物理檔案，當topic數量增加時，訊息分散的落盤策略會導致磁碟io競爭激烈成為瓶頸。
方案三：採用流處理方式對資料進行分類，即增加乙個中間資料流處理，將資料按照訂閱規則進行歸類，然後寫入不同的topic中，在consumer端，每個group可以拿到僅僅是自己感興趣的資料。這種方式適用於資料量較大、但是consumer端的消費group有限的情況，否則也會出現上述的topic碎片化的問題。
方案四：自己做partition的分配，但是不容易控制，應盡量避免。
Kafka下的生產消費者模式與訂閱發布模式
在rabbitmq下的生產消費者模式與訂閱發布模式一文中，筆者以 資料接入 和 事件分發 兩種場景為例，介紹了如何使用rabbitmq來設計 實現生產消費者模式與訂閱發布模式。生產消費者模式，指的是由生產者將資料源源不斷推送到訊息中心，由不同的消費者從訊息中心取出資料做自己的處理，在同一類別下，所有...
Kafka下的生產消費者模式與訂閱發布模式
在rabbitmq下的生產消費者模式與訂閱發布模式一文中，筆者以 資料接入 和 事件分發 兩種場景為例，介紹了如何使用rabbitmq來設計 實現生產消費者模式與訂閱發布模式。生產消費者模式，指的是由生產者將資料源源不斷推送到訊息中心，由不同的消費者從訊息中心取出資料做自己的處理，在同一類別下，所有...
Kafka下的生產消費者模式與訂閱發布模式
原文 在rabbitmq下的生產消費者模式與訂閱發布模式一文中，筆者以 資料接入 和 事件分發 兩種場景為例，介紹了如何使用rabbitmq來設計 實現生產消費者模式與訂閱發布模式。生產消費者模式，指的是由生產者將資料源源不斷推送到訊息中心，由不同的消費者從訊息中心取出資料做自己的處理，在同一類別下...