與生產者對應的是消費者，應用程式可以通過 kafkaconsumer 來訂閱主題，並從訂閱的主題中拉取訊息。不過在使用 kafkaconsumer 消費訊息之前需要先了解消費者和消費組的概念，否則無法理解如何使用kafkaconsumer。
今天先講解消費者與消費組之間的關係，後續再結合案例再細緻地講解如何使用。
消費者負責訂閱 kafka 中的主題（topic），並且從訂閱的主題上拉取訊息。與其他一些訊息中介軟體不同的是：在 kafka 的消費理念中還有一層消費組的概念，每個消費者都有乙個對應的消費組。當訊息發布到主題後，只會被投遞給訂閱它的每個消費組中的乙個消費者。
如上圖所示，某個主題中共有4個分割槽（partition）：p0、p1、p2、p3。有兩個消費組a和b都訂閱了這個主題，消費組a中有4個消費者（c0、c1、c2和c3），消費組b中有2個消費者（c4和c5）。按照 kafka 預設的規則，最後的分配結果是消費組a中的每乙個消費者分配到1個分割槽，消費組b中的每乙個消費者分配到2個分割槽，兩個消費組之間互不影響。每個消費者只能消費所分配到的分割槽中的訊息。換言之，每乙個分割槽只能被乙個消費組中的乙個消費者所消費。
我們再來看一下消費組內的消費者個數變化時所對應的分割槽分配的演變。假設目前某消費組內只有乙個消費者c0，訂閱了乙個主題，這個主題包含7個分割槽：p0、p1、p2、p3、p4、p5、p6。也就是說，這個消費者c0訂閱了7個分割槽，具體分配情形參考上圖。
此時消費組內又加入了乙個新的消費者c1，按照既定的邏輯，需要將原來消費者c0的部分分割槽分配給消費者c1消費，如上圖所示。消費者c0和c1各自負責消費所分配到的分割槽，彼此之間並無邏輯上的干擾。
消費者與消費組這種模型可以讓整體的消費能力具備橫向伸縮性，我們可以增加（或減少）消費者的個數來提高（或降低）整體的消費能力。對於分割槽數固定的情況，一味地增加消費者並不會讓消費能力一直得到提公升，如果消費者過多，出現了消費者的個數大於分割槽個數的情況，就會有消費者分配不到任何分割槽。參考下圖，一共有8個消費者，7個分割槽，那麼最後的消費者c7由於分配不到任何分割槽而無法消費任何訊息。
以上分配邏輯都是基於預設的分割槽分配策略進行分析的，可以通過消費者客戶端引數 partition.assignment.strategy 來設定消費者與訂閱主題之間的分割槽分配策略。
對於訊息中介軟體而言，一般有兩種訊息投遞模式：點對點（p2p，point-to-point）模式和發布/訂閱（pub/sub）模式。點對點模式是基於佇列的，訊息生產者傳送訊息到佇列，訊息消費者從佇列中接收訊息。
發布訂閱模式定義了如何向乙個內容節點發布和訂閱訊息，這個內容節點稱為主題（topic），主題可以認為是訊息傳遞的中介，訊息發布者將訊息發布到某個主題，而訊息訂閱者從主題中訂閱訊息。主題使得訊息的訂閱者和發布者互相保持獨立，不需要進行接觸即可保證訊息的傳遞，發布/訂閱模式在訊息的一對多廣播時採用。kafka 同時支援兩種訊息投遞模式，而這正是得益於消費者與消費組模型的契合：
消費組是乙個邏輯上的概念，它將旗下的消費者歸為一類，每乙個消費者只隸屬於乙個消費組。每乙個消費組都會有乙個固定的名稱，消費者在進行消費前需要指定其所屬消費組的名稱，這個可以通過消費者客戶端引數 group.id 來配置，預設值為空字串。
消費者並非邏輯上的概念，它是實際的應用例項，它可以是乙個執行緒，也可以是乙個程序。同乙個消費組內的消費者既可以部署在同一臺機器上，也可以部署在不同的機器上。
kafka消費者無法消費異常
今天被乙個kafka消費異常折磨了一天，頭差點炸了，還好最後解決了它 異常 伺服器 record is corrupt 記錄損壞 不明原因 有可能磁碟空間不足導致 導致消費者無法正常消費訊息 卡在某乙個offset 不能繼續消費 解決辦法 先停掉消費者程式 殺掉程序 不可關閉kafka服務 然後手動...
kafka 主動消費 Kafka消費者的使用和原理
publicstaticvoidmain string args finally 前兩步和生產者類似，配置引數然後根據引數建立例項，區別在於消費者使用的是反序列化器，以及多了乙個必填引數 group.id，用於指定消費者所屬的消費組。關於消費組的概念在 kafka中的基本概念 中介紹過了，消費組使得...
kafka學習十三 消費者消費資料
由於自動提交是每隔一段時間提交一次，假如消費者拉到一批資料，剛處理一部分就提交了，然後掛掉了，這個時候未消費的那批資料就徹底丟失了，因為offset已經提交了，不會重新消費。同樣的，消費者拉到一批資料，剛處理一部分沒有提交，然後掛掉了，這個時候已經消費的那批訊息會被再次消費。手動消費只會造成訊息重複...