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

6 /

7 偏移量管理者发生移动,偏移量缓存加载了17分钟.偏移量topic是非常小的,正常只需要几 秒钟就可以处理完.这很明显的说明日志压缩过程因为某种原因发生中断,造成未checkpoint的 偏移量topic一直在增长.这种情况发生不会导致已经checkpoint的偏移量信息丢失.在加载过程 中偏移量"fetch"收到错误代码意味着加载过程有问题,consumer只是重试偏移量"fetch".在这个 故障中,偏移量"fetch"实际返回的意思是"没有有效的偏移被找到". 这证明了日志压缩过程时间太久,有些旧偏移量仍然在偏移量topic中.偏移量缓存加载过程 会把这些旧偏移量加载进缓存.然而它自己认为在日志里有更多最近的偏移量最终会覆盖旧偏移 量项,所以没啥问题.问题就在这里,在长时间的偏移量加载中旧偏移量的清除任务被杀掉,并 且在清除掉旧偏移量项后会在日志尾部添加通知.偏移量加载过程继续加载最近的偏移量到缓存 中,但是只有当它发现追加的通知才会移除这些旧偏移量.这也旧解释了为什么偏移量总是丢失 . 结论 基于Kafka的偏移量管理是Kafka consumer默认的偏移量管理机制.很好的理解偏移量管理 是如何工作的对使用Kafka是非常有用的. 简单总结如下: Consumer延迟警报对监控consumer健康和探测偏移量"倒回"是非常必要的.Burrow会很好 的帮助你做好每个consumer的延迟监控服务.激活监控日志压缩度量也是非常重要的,特别是m ax-dirty-ratio.其它的度量offset-cache-size, commit-rate和group-count sensors也会对偏移量 管理有帮助.当出现偏移量"倒回",就要对topic(__consumer_offsets)进行dump.你也需要检 查未知leader选举以及偏移量管理者和consumer打印日志. 英文原文:Kafkaesque Days at LinkedIn C Part

1 转载自:LinkedIn的Kafka分布式消息系统实践(Part 1) 本博客文章除特别声明,全部都是原创! 转载本文请加上:转载自过往记忆(https://www.iteblog.com/) 本文链接: 【】() Powered by TCPDF (www.tcpdf.org)

7 / 7