PDF《Kafka在LinkedIn公司的使用及维护实战》

2 /

7 然而,consumer的日志很明显的显示好几个分区有偏移量重置的情况.为了debug这个故障,我 们需要懂得consumer偏移量管理是如何工作的. Consumer偏移量管理 Consumer通过发送OffsetCommitRequest请求到指定broker(偏移量管理者)提交偏移量 .这个请求中包含一系列分区以及在这些分区中的消费位置(偏移量).偏移量管理者会追加键 值(key-value)形式的消息到一个指定的topic(__consumer_offsets).key是由consumerGr oup-topic-partition组成的,而value是偏移量,如下图所示.内存中也会维护一份最近的记录, 为了在指定key的情况下能快速的给出OffsetFetchRequests而不用扫描全部偏移量topic日志.如 果偏移量管理者因某种原因失败,新的broker将会成为偏移量管理者并且通过扫描偏移量topic来 重新生成偏移量缓存.在下面的例子中,mirror- maker消费topic(PageViewEvent)到分区0的位置321. 偏移量topic是会日志压缩的,这意味着旧的冗余项最终会被清除.因为有些瞬时consumer(比如,控制台consumer)来来回回的,偏移量管理者会周期地扫描偏移量缓存,并移除死亡consu mer group的偏移量项(比如,在配置指定周期内未进行更新).这个过程也会在偏移量topic日 志中追加一个公告来通知下次进行日志压缩的时候就从持久化的日志中移除.

3 /

7 调试故障 下面是偏移量重置时间周围的消费日志摘要: 在偏移量发生重置之前出现了几个consumer的rebalance.Rebalance一般发生在consumer 离开或者加入consumer group,或者新的topic或分区变成可以消费的情况.在rebalance期间, consumer依次经过:停止消费数据;

提交它们的偏移量;

跨group重新分配分区;

从新所属的分 区获取偏移量;

重新消费数据.在前面的打印日志中,initOffset所在行会指出consumer将会从 哪个位置开始消费.前两个rebalance从有效的偏移量开始重新消费,而第三个rebalance试图从 明显是旧偏移量消费.当调试这些故障时,最好能在消费者控制台使用以下命令dump偏移量的t opic(因为日志压缩会随时发生):

4 /

7 记住在配置中设置exclude.internal.topics值为false,因为偏移量topic是一个内部的topic. 进一步深入的研究下偏移量topic的dump发生了什么: 无效偏移量(6811737)被checkpoint是在这次故障一个月之前.但是最近也有有效的checkpoin t返回了偏移量.那为什么偏移量管理者会返回一个很长时间的旧偏移量? 偏移量管理者打印的日志清晰的指出:在加载偏移量到偏移量缓存中时,偏移量管理者发生了移 动,随之发生了问题. 这是偏移量topic消息的格式发生改变时的一个bug.在缓存中加入过期的偏移量之后,偏移量管 理者会短暂移动.这也是为什么偏移量获取会返回过期的偏移量. 重复邮件的缘由 在这个故障中,mirror maker设置的auto.offset.reset为"latest",按理来说应该不会出现重复 消费数据.所以需要进一步的看看包含发布事件的topic到底发生了什么?

5 /

7 虽然这个topic展示了雷同的错误――i.e.,在早期的rebalance之后偏移量"fetch"到当前的偏 移量,而最近的rebalance之后偏移量"fetch"到了过期的偏移量,虽然过期的偏移量是一个月之前 的,但它仍然是有效的.最开始大家对这个问题比较吃惊,因为作者在Kafka集群设置的topic保 留时间为四天.最后发现,发布记录的topic数据量太小,没有触发基于数据量大小的阈值.基于 时间的保留依赖于最后的修改时间,但是在小数据量topic时无效. 偏移量管理bug最近修复了. 第二次故障 这次的故障发生在数据发布管道中:Hadoop的push-jobs发送数据到CORP环境的(比如, 非生产环境)Kafka中,然后镜像到PROD来为线上服务来消费.作者收到了延迟警报,mirror maker因为某种原因卡住了.许多重复的消息发送到下游,也就意味着出现偏移量"倒回". consumer打印的日志显示偏移量"fetch"返回 -1 (这意味着没有偏移量被checkpoint).换句话 说,偏移量管理者丢失了以前的一些checkpoint偏移量: 偏移量管理者打印的日志提供了一些帮助: