flink：版本1.4
flink-kafka-connector：0.10.x
kafka-brokers:3個
topic-partitoins:3個
topic-replication:2個
flink通過kafka-connector連線kafka消費資料，當kafka異常，broker節點不可用時，kafka的consumer執行緒會把flink程序的cpu打爆至100%其中：
cpu持續高，首先想到是flink在消費資料時沒有對異常進行處理，頻繁異常打爆了cpu，我們去檢查flink的輸出日誌，輸出日誌並沒有找到有價值的資訊，初次分析宣告失敗。
沒辦法，只能用動用大殺器，分析下程序的cpu占用了執行緒以及堆疊
1、檢視占用cpu高的程序，確認無誤這些程序全是flink的jop
2、列印程序堆疊
jstack 10348>> 10348.txt 得到程序的所有執行緒堆疊資訊。
3、查詢占用cpu高的執行緒
ps -mp pid -o thread,tid,time 查詢占用cpu搞的執行緒
4、檢視執行緒堆疊，發現大部分錯誤集中在kafkaconsumer.poll方法上。
到這基本可以定位原因了，應該是kafka的consumerpoll方法導致cpu高。
圍繞kafkaconsumer需要指定排查計畫，主要是兩個方向
1、kafka和flink跟poll相關的引數調整。
2、kafka和flink對kafka消費時是否有bug。
中間確實嘗試了好多條路，其中
1、驗證調整了kafkaconsumer的max.poll.interval.ms引數，不起作用。
2、kafka的相關jop並沒有進行重啟，所以不需要調整flink重試相關的引數。
3、調整flink的flink.poll-timeout引數，不起作用。
最終發現，原來是kafka-consumer0.10版本的乙個bug。
詳細的bug描述如下：
有了bug解決起來就迅速多了，根據bug制定解決驗證方案：
1、公升級flink的kafka-connnectorapi。
2、調整reconnect.backoff.ms引數。
此時公升級flink的kafka-connector就解決了該問題。
中間還出現乙個小插曲：因為我們的複製因子是2，當其中兩個節點宕機後，cpu也暴增到100%。增加了不少彎路。後分析，只有兩個複製因子，1個parition分布在兩個broker上，假如兩個broker宕機，其實是和三個集群宕機影響是一樣的。
1、kafka-topic的複製因子和分割槽要根據實際需要需求設定。假如有三個節點，重要的業務topic建議分割槽3個，複製因子3個，用效能換穩定。
2、kafka的0.10版的consumer消費時，有bug，broder節點異常關閉時，client會打爆cpu，0.11及以上修復。
3、flink版本的kafka-connector，0.11可以消費0.10的kafka.
kafka consumer深度剖析
producer通過主動push的方式將訊息發布到broker consumer通過pull從broker消費資料，pull的好處 每個partition有乙個leader 和若干個follower replica kafka資料的讀寫都是找leader來完成的，那leader 的負載怎麼解決呢？l...
kafka consumer防止資料丟失
kafka最初是被linkedin設計用來處理log的分布式訊息系統，因此它的著眼點不在資料的安全性 log偶爾丟幾條無所謂 換句話說kafka並不能完全保證資料不丟失。儘管kafka官網聲稱能夠保證at least once，但如果consumer程序數小於partition num 這個結論不一...
kafka consumer防止資料丟失
kafka最初是被linkedin設計用來處理log的分布式訊息系統，因此它的著眼點不在資料的安全性 log偶爾丟幾條無所謂 換句話說kafka並不能完全保證資料不丟失。儘管kafka官網聲稱能夠保證at least once，但如果consumer程序數小於partition num，這個結論不一...