作者回复: 你所谓的处理是指业务上的处理逻辑。对于Kafka而言,从poll方法返回消息的那一刻开始这条消息已经算是“消费”完成了。
作者回复: consumer主动关闭会主动向Coordinator发送LeaveGroup请求,从而让Coordinator第一时间开启rebalance
作者回复: 是否是因为某个分区的数据量太多,造成了其他分区的“假饿死”?
作者回复: 不同的group id会被哈希到不同的分区上,从而不同的broker能充当不同group的Coordinator
作者回复: 去找Coordinator所在的broker日志,如果经常发生rebalance,会有类似于"(Re)join group" 之类的日志
作者回复: 取最大的
作者回复: 0.10.1之前是在调用poll方法时发送的,0.10.1之后consumer使用单独的心跳线程来发送
作者回复: 很多种原因而且如果我没记错的话,这是个INFO日志,你最好调整一下日志级别,看看能否打出真实的原因。从这个错误本身来看,这个异常就是表示consumer无法连接上Coordinator或Coordinator本身不可用了,可能的原因确实太多了
作者回复: 会讲到controller,如果有未涉及的部分, 也可以直接在这里留言提问 :)
作者回复: 别增加。目前源代码中内部topic的分区被hard code成50了,如果后面修改会造成各种问题。已经有对应的bug来解决此事了,但代码还没有merge
作者回复: 是的
作者回复: 针对整个group的。如果消费者组订阅信息发生变化也是会发生rebalance的。
作者回复: 0.9的确没有这个参数。你依然只能设置session.timeout.ms来规避
作者回复: broker挂了,分区数不会变啊
作者回复: 新版本已经推出来了