16 | 揭开神秘的“位移主题”面纱
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Kafka位移主题__consumer_offsets在Kafka中扮演着重要的角色，用于保存消费者的位移信息。该主题通过将位移数据作为普通的Kafka消息提交到__consumer_offsets中，实现了高持久性和支持高频的写操作。位移主题的消息格式包括保存Consumer Group信息的消息、用于删除Group过期位移的消息以及用于删除Group信息的tombstone消息。位移主题通常在Kafka集群中第一个Consumer程序启动时自动创建，分区数和副本数由相应的Broker端参数控制。Kafka Consumer提交位移的方式有自动提交和手动提交两种，其中手动提交位移需要开发者承担位移提交的责任。此外，Kafka使用Compact策略来删除位移主题中的过期消息，避免该主题无限期膨胀。对于同一个Key的两条消息，如果早于后一条消息，则被视为过期消息。Kafka提供了专门的后台线程Log Cleaner来定期巡检待Compact的主题，以删除满足条件的可删除数据。这些技术特点使得位移主题在Kafka中具有重要意义，对于理解Kafka的位移管理机制和消费者位移信息的保存具有重要意义。文章总结了Kafka位移主题__consumer_offsets的重要性和作用，以及其消息格式、提交方式和管理策略。通过将元数据以消息的方式存入Kafka内部主题，Kafka实现了高持久性和高吞吐量，满足了子服务的需求，避免了对外部系统的依赖。与ZooKeeper方案相比，位移主题可能存在的劣势需要进一步思考和讨论。
《Kafka 核心技术与实战》，新⼈⾸单¥68
全部留言(126)
- 最新
- 精选
此方彼方Francis之前遇到过的一个问题跟大家分享一下，原因描述不正确的地方还请大佬指正： log cleaner线程挂掉还有可能导致消费端出现：Marking Coordinator Dead！ 原因大概如下： log cleaner线程挂掉之后会导致磁盘上位移主题的文件越来越多（当然，大部分是过期数据，只是依旧存在），broker内存中会维护offsetMap，从名字上看这个map就是维护消费进度的，而这个map和位移主题的文件有关联，文件越来越多会导致offsetMap越来越大，甚至导致offsetMap构建失败（为什么会失败没有搞明白），offsetMap构建失败之后broker不会承认自己是coordinator。 消费者组找coordinator的逻辑很简单：abs(consumer_groupName.hashCode) % __consumer_offset.partition.num对应的partition所在的broker就是这个group的coordinate，一旦这个broker的offsetMap构建失败，那么这个broker就不承认自己是这个group的coordinate，这个group的消费就无法继续进行，会出现Marking Coordinator Dead错误。 此时需要删除过期的位移主题的文件（根据文件名很容易确定哪个是最新的），重启broker。重启过程中需要关注log cleaner是否会再次挂掉。 PS：上述问题在broker重启和正常运行中都有可能遇到。作者回复: 是个很好的梳理思路~
2020-02-14759- Eco有个问题想请教一下，这个位移主题，Consumer是像消费其他主题的分区的内容一样去获取数据的话，那么这本身不也得有个位移，那这个位移又保存到哪里的呢？这样下去不就陷入了一个死循环了吗？要么就不是像正常的消费消息那样去从位移主题获取当前消费者对于某个主题的分区的位移？
作者回复: 好问题！其实Kafka并不太关注__consumer_offsets消费的情况，不过Coordinator的确会在JVM中把所有分区当前已提交的最新位移缓存起来，并且通过这个缓存来决定哪个consumer当前消费到了哪个位移。
2020-01-15728 
mellow老师能讲一下，同一个group下的consumer启动之后是怎么去offset topic 拿到该group上次消费topic每个partition的最新offset呢？是根据key来定位offset topic的partition吗，然后拿到所有消息得到最新的offset吗作者回复: 它会去寻找其Coordinator Leader副本对应的broker去拿。根据group.id找到对应Coordinator的分区数
2019-07-09523
王藝明老师好！ 为什么位移主题写入消息时，不直接替换掉原来的数据，像 HashMap 一样呢？而是要堆积起来，另起线程来维护位移主题作者回复: 位移主题也是主题，也要遵循Kafka底层的日志设计思路，即append-only log
2019-10-14321
sharpdeep有个困惑: 位移主题用来记住位移，那么这个位移主题的位移由谁来记住呢?作者回复: 位移主题的位移由Kafka内部的Coordinator自行管理
2020-03-26215
🤡对GroupId 还有疑惑，假设一个Group下有 3 个Consumer , 那这三个Consumer 对应的groupid 应该是一样的。这样的话怎么做key做唯一区分呢作者回复: 每个client都有自己的member id和client id用于区分彼此
2019-08-12314
HZ老师 有两点不太清楚 1. 位移主题里面，对于同一个consumer group的位移提交记录，是分布在50个partitions中吗？ 2. 如果把位移主题当作kafka里面的一个普通主题，那么写入这个主题的数据可以保证不丢失吗？ 写入是ack=all？ 同时，broker端的min.insync.replicas的设置有影响吗？作者回复: 1. 同一个group的位移记录只保存在一个partition上 2. 没错，写入就是acks=all的设置 3. min.insync.replicas对位移主题依然适用
2020-02-24413
西边一抹残阳胡老师，消费者提交的位移消息，保存到位移主题分区是随机的吗？就是某一个消费者的提交第一个位移数据保存在位移主题的A分区里面，第二个位移数据保存在位移主题的B分区里面 还有消费者是怎样获取已消费的位移数据作者回复: 不是随机的。通常来说，同一个group下的所有消费者提交的位移数据保存在位移主题的同一个分区下
2020-01-0412
谦寻consumer端 日常业务发版呢，那每次发版需要重启consumer不是也会导致Rebalance，这个如何规避作者回复: 可以考虑使用standalone consumer，否则group机制无法避免
2019-07-15212- Coder4老师好，前几年一直有个说法，说kafka不适合创建过多topic，请问现在的新版还有这个问题么？
作者回复: topic过多其实是指分区数过多。会有两个可能的问题：1. controller无法管理这么多分区；2. 分区数过多导致broker物理随机IO增加，减少吞吐量。 第一个问题社区算是修复了吧，目前单controller能够支持20w的分区数，况且社区也在考虑做多controller方案；第二个问题目前没有太多直接的修复举措，只能说具体问题具体分析吧
2019-07-1149
