LinkedIn Kafka 生产事件分析与解决

LinkedIn 软件工程师 Joel Koshy 详细描述了如何与团队一起解决了两个由于多个 Bug、异常客户端行为和监控缺失导致的 Kafka 生产事件。

第一个 Bug：重复邮件问题

• 现象：LinkedIn 的变更请求跟踪器和部署平台出现重复发送邮件的现象。

• 根本原因：

  • 消息格式的变更导致缓存加载在偏移管理器上终止，且使用了陈旧的偏移量。
  • 由于部署主题分区中的数据量较低，日志压缩和清除触发器未触发。
  • 消费者从陈旧的偏移量开始读取，导致重复读取已消费的消息，从而触发重复邮件。

第二个 Bug：数据部署管道问题

• 现象：Hadoop 推送作业将数据发送到非生产 Kafka 环境，然后通过 Kafka 集群复制到生产集群，但复制过程卡住。

• 根本原因：

  • 偏移量获取返回时没有有效的检查点，导致之前检查点的偏移量丢失。
  • 日志压缩过程已停止，偏移量主题中仍保留了一些较旧的偏移量。
  • 偏移量缓存加载过程将这些旧偏移量加载到缓存中，而陈旧的偏移量清理过程在长时间偏移量加载期间启动，并清除旧条目并在日志末尾附加了墓碑标记。
  • 偏移量加载过程继续并将最新偏移量加载到缓存中，但在看到墓碑标记后移除了这些偏移量，导致偏移量有效丢失。

Kafka 偏移量管理问题

• 问题：Kafka 代理之间领导选举不明确，导致分区领导代理在完全复制滞后期间失败，从而出现偏移量回退。

• 消费者行为：

  • 消费者发出指定从哪个偏移量开始消费的获取请求。
  • 消费者检查其偏移量以确保在需要重新启动时可以从最后一个检查点恢复。
  • 如果消费者获取的偏移量超出代理主题日志的范围，将收到 OffsetOutOfRange 错误，并根据 auto.offset.reset 配置将偏移量重置为最新或最早的有效偏移量。
  • 重置为最早偏移量会导致重复消费，而重置为最新偏移量可能会丢失一些消息。

最佳实践

• 监控与警报：

  • 监控集群的 unclean leader election 率。
  • 监控并警报消费者滞后，避免误报。
  • 监控日志压缩指标，尤其是 max-dirty-ratio 传感器，以及偏移量管理指标如 offset-cache-size、commit-rate 和 group-count 传感器。

• 调试建议：

  • 在调试过程中尽早转储内部 __consumer_offsets 主题，以避免日志压缩删除潜在有用的数据。
  • 消费者和代理日志也可能有用。

通过这些分析和实践，Koshy 及其团队有效地解决了这些复杂的 Kafka 生产问题，并提出了改进监控和调试的建议。