在本文中，LinkedIn的软件工程师Joel Koshy详细阐述了他和一个工程师团队是如何解决生产环境下Kafka的两次事故的。这两次事故是由于多个产品缺陷、特殊的客户行为以及监控缺失的交错影响导致的。
第一个缺陷是在LinkedIn的变更请求跟踪系统中观察到的，部署平台认为这是从服务发出的重复邮件。Koshy指出，其根本原因是由于消息格式的改变，和随后缓存加载在偏移管理器的终止，而这个偏移管理器已经被设置了一个旧的偏移量。由于这个主题分区上的低数据容量，日志压缩和清除触发器在部署的主题上从来没有被触发过。这导致一个旧的偏移量被当作消费者的起点，同时也使得以前已经消费过的消息被重新读取，并触发了重复的电子邮件。
第二个缺陷是在一个数据部署管道中，它里面的Hadoop推送作业器会发送数据到Kafka的非生产环境，然后通过Kafka集群复制到生产集群。在发现取回的偏移量没有有效检查点的时候，复制就被卡住了。它表明前一个检查的偏移量被丢掉了。Koshy是这样描述根本原因的：
......由于日志压缩进程已经停止一段时间了，有几个较旧的偏移量仍然还在主题中。偏移缓存加载进程已经将它们加载到了缓存中。这本身是没有问题的，因为日志中更多的最新偏移量最终会覆盖那些旧的条目。问题出在旧偏移量的清除进程是在偏移加载的过程中开始的，偏移加载的过程需要较长的时间。旧条目清除之后会在日志末尾追加标记。而与此同时，偏移量的加载过程仍在进行，并会加载最近的偏移量到缓存中，但它只会在看到标记之后才会去除那些条目。这就解释了为什么偏移量实际上被丢失的原因。
Kafka代理之间不清楚首席代理选举的规则，这会导致处于分区的首席代理在完成复制延迟过程中的失败会引起偏移量倒转。Kafka消息的消费者发出读取指定偏移量的请求。消费者会对主题分区检查它们的偏移量，因此它们可以从最后一次检查点（消费者需要重启的点）重新开始。检查可以发生在很多时候，包括消费者失败、重启或者分区被加到主题里以及在消费者实例之间的分区分发规则需要改变的时候。如果一个消费者获取这个代理的主题日志之外的偏移关键字，它会收到OffsetOutOfRange的错误。消费者需要根据它们auto.offset.reset配置，来重新设置它们的偏移为最新或最早的有效偏移。
Koshy指出，
重置为最早的偏移会引起重复消费，而重置为最新的偏移意味着可能会丢失在偏移复位和下一次读取之间已经到达的消息。
Koshy还着重指出一些尽早发现偏移倒回的最佳实践，包括：通过监控集群中模糊不清的首席选举率，基于消费者延迟的监控和告警从而避免误报。监控日志压缩的指标（特别是最大脏读率传感器的），以及偏移管理的指标（如偏移缓存大小、提交率、组数传感器等）。偏移量自己被存在一个可复制、可分区、可压缩的日志中，它们与内部的_consmer_offsets主题相关联。Koshy推荐在调试进程中尽早导出内部主题，从而避免日志压缩删除那些潜在有用的数据。特定的主题由消息组成，任何的时间偏移提交请求都会被发送到偏移管理代理中。在这种情况下，消费者和代理的日志也是可能有用的。
本文转自d1net（转载）
