作者回复: hmm.... 哈哈哈,不知道。。。。
作者回复: 它会去寻找其Coordinator Leader副本对应的broker去拿。根据group.id找到对应Coordinator的分区数
作者回复: 每个client都有自己的member id和client id用于区分彼此
作者回复: topic过多其实是指分区数过多。会有两个可能的问题:1. controller无法管理这么多分区;2. 分区数过多导致broker物理随机IO增加,减少吞吐量。
第一个问题社区算是修复了吧,目前单controller能够支持20w的分区数,况且社区也在考虑做多controller方案;第二个问题目前没有太多直接的修复举措,只能说具体问题具体分析吧
作者回复: ZooKeeper本身只是一个分布式协调框架,znode中保存的数据多是那些不怎么频繁修改的元数据,本身不适合频繁更新。
是的,旧版本consumer就是这么使用ZooKeeper来保存位移的
作者回复: 最新的
作者回复: 好问题!其实Kafka并不太关注__consumer_offsets消费的情况,不过Coordinator的确会在JVM中把所有分区当前已提交的最新位移缓存起来,并且通过这个缓存来决定哪个consumer当前消费到了哪个位移。
作者回复: 1. 同一个线程
2. 是的,但通常还会与Coordinator建立TCP连接,另外获取元数据请求时也可能建立新的TCP连接。总之,当正常消费时,与broker创建一个TCP连接即可消费
作者回复: 现在自动提交位移的设计就是不管你有没有消费,就是阶段性地提交位移,即使是提交相同的位移
作者回复: 如果是多个分区,即使是但consumer线程,也没法保证全局的顺序性。这是无法规避的
作者回复: 如果使用使用老版本consumer,还是会记录在ZooKeeper中的
作者回复: 1. 没什么区别。你可以简单认为就是换个地方保存:)
2. 这个其实是个bug,不过现在已经修复了。如果reassign hang住了,手动删除Zk下对应的znode就能恢复
作者回复: “每个主题也会记录位移,跟主题位移有啥区别” 这是什么意思呢?没看懂。。。。
“我线上主题位置没有副本” 这又是什么意思呢。。。
作者回复: 需要自己写代码实现,Kafka没有天然提供这个功能
作者回复: 不是随机的。通常来说,同一个group下的所有消费者提交的位移数据保存在位移主题的同一个分区下