1，啟動(dòng)的時(shí)候報(bào)錯(cuò)
2015-12-03 12:28:53.338 b.s.m.n.Client [ERROR] connection attempt 10 to Netty-Client-host1.grid.myco.com/10.1.2.3:6710 failed: java.net.ConnectException: Connection refused: host1.grid.myco.com/10.1.2.3:6710
開始的時(shí)候沒有注意到這個(gè)錯(cuò)誤信息，應(yīng)為拓?fù)浒l(fā)布后是正常使用的。只是在無(wú)意間看到日志中有error級(jí)別的錯(cuò)誤日志。
分析：
1，感覺不是致命的錯(cuò)誤，根據(jù)內(nèi)容查看了相應(yīng)端口是否可用。
2，考慮到官網(wǎng)中寫明不支持ip6，檢查機(jī)子將ip6關(guān)閉，但是還是有這樣的問題。
3，考慮到啟動(dòng)的順序問題，應(yīng)為查看到一個(gè)并行度為4的spout中，有3個(gè)worker日志中是有錯(cuò)誤信息的，另外一個(gè)是沒有的。
4，看到 http://stackoverflow.com/questions/36612557/aws-workers-cant-communicate-due-to-netty-client-hostname-resolution/39104515#39104515 有人已經(jīng)提出過這個(gè)。
2,拓?fù)涮峤缓?，?bào)錯(cuò)
Consumer has failed with exception: org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed due to group rebalance
storm ui 出現(xiàn)的錯(cuò)誤信息，但是消息還是可以消費(fèi)，看到spout中的消費(fèi)進(jìn)程確實(shí)有的時(shí)間不對(duì)了，證明有過balance。
分析：
1，錯(cuò)誤信息寫的明白，是應(yīng)為提交offset的時(shí)候做了rebalance過程，rebalance觸發(fā)的條件，在http://zqhxuyuan.github.io/2016/10/27/Kafka-Definitive-Guide-cn-04/ 這里寫的很明確，但是好端端的為什么要rebalance。
2，考慮重要是通信超時(shí)，consumer 在通kafka中某個(gè)broker通信的時(shí)候。需要增加超時(shí)時(shí)間。
3，http://stackoverflow.com/questions/35658171/kafka-commitfailedexception-consumer-exception
提到了這樣的錯(cuò)誤。也可以參考下 http://blog.csdn.net/weitry/article/details/53009134 ，但是參數(shù)max.poll.records （1.×）需要注意版本問題。
解決方式：
- 增加消費(fèi)超時(shí)時(shí)間。消費(fèi)超時(shí)時(shí)間通過heartbeat.interval.ms設(shè)置，heartbeat.interval.ms的大小不能超過session.timeout.ms，session.timeout.ms必須在[group.min.session.timeout.ms, group.max.session.timeout.ms]范圍內(nèi)。
- 減少消息處理時(shí)間；由后端處理決定。
- 減少一次消費(fèi)的消息量。max.partition.fetch.bytes決定容量，max.poll.records（1.×）決定數(shù)量。max.partition.fetch.bytes規(guī)定了一個(gè)partition一次pull獲取的獲取的數(shù)據(jù)大小。max.poll.records規(guī)定一次pull獲取的消息數(shù)量。
