線上是同事寫的flume-kafkaplugin來實現對kafka消費到其他終端的，不過最近遇到幾個莫名的case.
現象：flume消費延遲，因爲當時比較緊急，同事想把延遲的數據丟掉從新的點開始追，就清了offset，重啓就開始消費新的地方了，不過我記得0.7.2kafka的默認autooffset.reset是smallest應該沒用啊，後來才知道同事hard code的一些參數：
props.put("zk.sessiontimeout.ms","60000");
props.put("fetch.size",String.valueOf(Integer.parseInt((getBatchSize(context))) * 300 * 1024));
props.put("autocommit.enable","false");
props.put("queuedchunks.max","100000");
props.put("autooffset.reset","largest");
props.put("socket.buffersize","102400000");
props.put("socket.timeout.ms","60000");
怪不得設置了batchsize會報message too big的exception=.=
不過即使丟棄了消息還是沒解決問題，我們又把offset修改了回去.主要是flume的消費能力是平時的一半，必須要找到影響這個的因素.
因爲比較緊急，臨時增加了一倍consumer“解決了”消費能力的問題.
後來發現，當時這個consumergroup連接的zk connect string的zk fd超過了ulimit所設置的，不過連接數纔到3K而已，這是爲什麼呢？
查了一下issue list發現kafka 0.7.2依賴的zk 3.3.4（KAFKA-318）有file descriptor泄漏的bug：ZOOKEEPER-1309（3.3.4 bug太多了，還有升級回滾問題1149）
後來同事測試了一下3.4.5基本上是兼容了，升級解決.
最後再插一個kafka的bug，就是即使autocommit被關閉了，這個版本的kafka在rebalance時還是會flush offset，也多虧這個Bug（KAKFA-919）了,否則不知道有多少重複數據了=.=
PS：不過線上使用的話還是把autocommit打開吧，可以將interval調大一點否則會造成不少的麻煩.不過打開這個還要注意另外一個Bug（KAFKA-601），ZK對於KAFKA還是很關鍵的，而下一篇就是和ZK相關了.