最近的業務接觸了一下消息插件kafka ，其他客戶端負責發送，我方負責接收消費。功能很簡單，但是！！！！我們要求把消息入庫，而且數據量每天達到了千萬級別，這就日了苟啊！ 廢話不多說，上代碼！ 由於消息需要入庫，我使用的是手動提交消息，如果不入庫，不要求准確定，使用自動提交就ok ...

一、消費者和消費者群組 　　在 Kafka 中，消費者通常是消費者群組的一部分，多個消費者群組共同讀取同一個主題時，彼此之間互不影響。Kafka 之所以要引入消費者群組這個概念是因為 Kafka 消費者經常會做一些高延遲的操作，比如把數據寫到數據庫或 HDFS ，或者進行耗時的計算，在這些情況下 ...

消費者組 kafka 使用消費者組來控制消費組消費，每個消費組都可以消費 topic 的全量信息，消費組內部的消費者再各自進行引流，消費不同的分區信息。 消費者從屬於消費組，一個組里的消費者訂閱的是相同的主題，每個消費者接收主題一部分的分區的消息。 一個消費者組只有一個消費者的情況 ...

fetch.min.bytes 該屬性指定了消費者’從服務器獲取記錄的最小字節數。 broker 在收到消費者的數據請求時， 如果可用的數據量小於fetch.min.bytes 指定的大小，那么它會等到有足夠的可用數據時才把它返回給消費者。 作用:可以降低消費者和 broker 的工作負載 ...

消費者api，自動提交offset 手動提交offset，同步提交 手動提交offset，異步提交 ...

一個正常的消費邏輯需要具備以下幾個步驟： 1. 消息訂閱 1.1 subscribe訂閱主題 subscribe有如下重載方法： 如果消費則采用正則表達式的方式訂閱，如果新創建的新的主題並且符合正則表達式，那么該消費者就可以消費到新添加主題中的消息。如果應用程序需要消費 ...

消費方式： consumer 采用 pull(拉)模式從 broker 中讀取數據。 　　push(推)模式很難適應消費速率不同的消費者，因為消息發送速率是由 broker 決定的。 它的目標是盡可能以最快速度傳遞消息，但是這樣很容易造成 ...

1. 前言 我們知道，生產者發送消息到主題，消費者訂閱主題（以消費者組的名義訂閱），而主題下是分區，消息是存儲在分區中的，所以事實上生產者發送消息到分區，消費者則從分區讀取消息，那么，這里問題來了，生產者將消息投遞到哪個分區？消費者組中的消費者實例之間是怎么分配分區的呢？接下來，就圍繞着 ...