注意：對於多個partition和多個consumer1、如果consumer比partition多，是浪費，因為kafka的設計是在乙個partition上是不允許併發的，所以consumer數不要大於partition數 。
2、如果consumer比partition少，乙個consumer會對應於多個partitions，這裡主要合理分配consumer數和partition數，否則會導致partition裡面的資料被取的不均勻 ，最好partiton數目是consumer數目的整數倍，所以partition數目很重要，比如取12，就很容易設定consumer數目 4
3、如果consumer從多個partition讀到資料，不保證資料間的順序性，kafka只保證在乙個partition上資料是有序的，但多個partition，根據你讀的順序會有不同。
4、增減consumer，broker，partition會導致rebalance，所以rebalance後consumer對應的partition會發生變化 。
注意：資料的安全性
1、如果auto.commit.enable=true，當consumer fetch了一些資料但還沒有完全處理掉的時候，剛好到commit interval出發了提交offset操作，接著consumer crash掉了。這時已經fetch的資料還沒有處理完成但已經被commit掉，因此沒有機會再次被處理，資料丟失。
2、如果auto.commit.enable=false，假設consumer的兩個fetcher各自拿了一條資料，並且由兩個執行緒同時處理，這時執行緒t1處理完partition1的資料，手動提交offset，這裡需要著重說明的是，當手動執行commit的時候，實際上是對這個consumer程序所占有的所有partition進行commit，kafka暫時還沒有提供更細粒度的commit方式，也就是說，即使t2沒有處理完partition2的資料，offset也被t1提交掉了。如果這時consumer crash掉，t2正在處理的這條資料就丟失了。
解決方案：
1、手動commit offset，並針對partition_num啟同樣數目的consumer程序，這樣就能保證乙個consumer程序占有乙個partition，commit offset的時候不會影響別的partition的offset。但這個方法比較侷限，因為partition和consumer程序的數目必須嚴格對應。
2、另乙個方法同樣需要手動commit offset，另外在consumer端再將所有fetch到的資料快取到queue裡，當把queue裡所有的資料處理完之後，再批量提交offset，這樣就能保證只有處理完的資料才被commit。
kafka消費者無法消費異常
今天被乙個kafka消費異常折磨了一天，頭差點炸了，還好最後解決了它 異常 伺服器 record is corrupt 記錄損壞 不明原因 有可能磁碟空間不足導致 導致消費者無法正常消費訊息 卡在某乙個offset 不能繼續消費 解決辦法 先停掉消費者程式 殺掉程序 不可關閉kafka服務 然後手動...
kafka 主動消費 Kafka消費者的使用和原理
publicstaticvoidmain string args finally 前兩步和生產者類似，配置引數然後根據引數建立例項，區別在於消費者使用的是反序列化器，以及多了乙個必填引數 group.id，用於指定消費者所屬的消費組。關於消費組的概念在 kafka中的基本概念 中介紹過了，消費組使得...
kafka消費者低階API
實現使用低階api讀取指定topic，指定partition,指定offset的資料。1 消費者使用低階api 的主要步驟 步驟主要工作 1根據指定的分割槽從主題元資料中找到主副本 2獲取分割槽最新的消費進度 3從主副本拉取分割槽的訊息 4識別主副本的變化，重試 指定分割槽，指定offset 1 根...