作者回复: hmm.... 哈哈哈,不知道。。。。
作者回复: 它会去寻找其Coordinator Leader副本对应的broker去拿。根据group.id找到对应Coordinator的分区数
作者回复: topic过多其实是指分区数过多。会有两个可能的问题:1. controller无法管理这么多分区;2. 分区数过多导致broker物理随机IO增加,减少吞吐量。
第一个问题社区算是修复了吧,目前单controller能够支持20w的分区数,况且社区也在考虑做多controller方案;第二个问题目前没有太多直接的修复举措,只能说具体问题具体分析吧
作者回复: ZooKeeper本身只是一个分布式协调框架,znode中保存的数据多是那些不怎么频繁修改的元数据,本身不适合频繁更新。
是的,旧版本consumer就是这么使用ZooKeeper来保存位移的
作者回复: 最新的
作者回复: 每个client都有自己的member id和client id用于区分彼此
作者回复: 如果是多个分区,即使是但consumer线程,也没法保证全局的顺序性。这是无法规避的
作者回复: 如果使用使用老版本consumer,还是会记录在ZooKeeper中的
作者回复: 1. 没什么区别。你可以简单认为就是换个地方保存:)
2. 这个其实是个bug,不过现在已经修复了。如果reassign hang住了,手动删除Zk下对应的znode就能恢复
作者回复: “每个主题也会记录位移,跟主题位移有啥区别” 这是什么意思呢?没看懂。。。。
“我线上主题位置没有副本” 这又是什么意思呢。。。
作者回复: 需要自己写代码实现,Kafka没有天然提供这个功能
作者回复: 现在自动提交位移的设计就是不管你有没有消费,就是阶段性地提交位移,即使是提交相同的位移
作者回复: 比较老的版本中offsets.topic.replication.factor参数值并不会被严格遵守,你可以手动将__consumer_offsets的rf值调高
作者回复: 对的,要消费的位移是通过从位移主题获取的
作者回复: Kafka自己管理的,其实和普通主题原理是类似的
作者回复: 位移主题也是主题,也要遵循Kafka底层的日志设计思路,即append-only log