卡夫卡 INVALID_FETCH_SESSION_EPOCH答案

【问题标题】：Kafka INVALID_FETCH_SESSION_EPOCH卡夫卡 INVALID_FETCH_SESSION_EPOCH
【发布时间】：2021-12-22 18:28:23
【问题描述】：

我们正在使用带有 kafka 流应用程序的 kafka 代理设置，该应用程序使用 Spring 云流 kafka 运行。虽然它看起来运行良好，但我们确实在日志中收到以下错误语句：

2019-02-21 22:37:20,253 INFO kafka-coordinator-heartbeat-thread | anomaly-timeline org.apache.kafka.clients.FetchSessionHandler [Consumer clientId=anomaly-timeline-56dc4481-3086-4359-a8e8-d2dae12272a2-StreamThread-1-consumer, groupId=anomaly-timeline] Node 2 was unable to process the fetch request with (sessionId=1290440723, epoch=2089): INVALID_FETCH_SESSION_EPOCH.

我搜索了互联网，但没有太多关于此错误的信息。我猜这可能与代理和消费者之间的时间设置不同有关，但两台机器的时间服务器设置相同。

知道如何解决这个问题吗？

【问题讨论】：

标签： apache-kafka apache-kafka-streams spring-cloud-stream

【解决方案1】：

从 1.1.0 版本开始，在 KIP-227 中引入了 fetch session 的概念：https://cwiki.apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests+to+Increase+Partition+Scalability

作为副本追随者的 Kafka 代理从领导者那里获取消息。为了避免每次都为所有分区发送完整的元数据，只有那些发生变化的分区才会在同一个提取会话中发送。

当我们查看 Kafka 的代码时，我们可以看到一个示例，当它返回时：

if (session.epoch != expectedEpoch) {
        info(s"Incremental fetch session ${session.id} expected epoch $expectedEpoch, but " +
          s"got ${session.epoch}.  Possible duplicate request.")
        new FetchResponse(Errors.INVALID_FETCH_SESSION_EPOCH, new FetchSession.RESP_MAP, 0, session.id)
      } else {

src：https://github.com/axbaretto/kafka/blob/ab2212c45daa841c2f16e9b1697187eb0e3aec8c/core/src/main/scala/kafka/server/FetchSession.scala#L493

一般来说，如果您没有数千个分区，同时这种情况并不经常发生，那么您不必担心。

【讨论】：

不幸的是，我认为这与网络问题无关，因为我在本地 docker 设置中也遇到了这些问题：anomaly-timeline-2 | 2019-02-22 14:45:39,593 INFO anomaly-timeline-db8558f2-cb17-4a87-b4ba-fe0fd1c47ec0-StreamThread-1 org.apache.kafka.clients.FetchSessionHandler [消费者clientId=anomaly-timeline-db8558f2-cb17-4a87 -b4ba-fe0fd1c47ec0-StreamThread-1-consumer, groupId=anomaly-timeline] 节点 1001 无法使用（sessionId=593140062, epoch=65）处理获取请求：INVALID_FETCH_SESSION_EPOCH。
你使用哪个 Kafka 版本？
Kafka 版本：2.0.1 Kafka commitId：fa14705e51bd2ce5
您知道是什么原因造成的吗？发布我的消费者设置会有所帮助吗？？
在根据保留计划轮换日志期间，您可能有一些客户端正在从代理读取；这也会导致您收到 INVALID_FETCH_SESSION_EPOCH，因为相关分区恰好不再存在于日志段中。

【解决方案2】：

这似乎是由Kafka-8052 问题引起的，该问题已针对 Kafka 2.3.0 修复

【讨论】：

我最近升级了我的 kafka 客户端以匹配至少 2.3.0 的代理。确实解决了这个问题，谢谢！

【解决方案3】：

确实，正如 zen 在 cmets 中指出的那样，当滚动或基于保留的删除发生时，您可以收到此消息。如果它不是一直发生，这不是问题。如果是，请检查您的 log.roll 和 log.retention 配置。

【讨论】：

检查它们到底是什么？
检查滚动/保留事件发生的时间和频率。

【解决方案4】：

将客户端版本更新到 2.3（来自代理的相同版本）为我修复它。

【讨论】：

这对我有用。我们正在运行服务器代理版本2.3.0，但我们的客户使用的是2.2.1。将客户端升级到版本 2.3.1 使这些 INVALID_FETCH_SESSION_EPOCH 日志停止。

【解决方案5】：

在我们的案例中，根本原因是 kafka Broker - 客户端不兼容。如果您的集群落后于客户端版本，您可能会看到诸如此类的各种奇怪问题。

我们的 kafka 代理在 1.x.x 上，我们的 kafka-consumer 在 2.x.x 上。一旦我们将spring-cloud-dependencies 降级为Finchley.RELEASE，我们的问题就解决了。

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:Finchley.RELEASE"
    }
}

【讨论】：