本文详细介绍了Kafka的延时队列机制，包括如何处理follower副本的拉取请求，以及延时操作的工作原理。此外，还讨论了Kafka中消息重复的常见场景，如生产者阶段的重复消息，分析了其原因并提出了启用幂等性的解决方案。同时，文章提到了Kafka不支持内置的重试和死信队列，建议用户自定义实现。最后，针对消费者阶段的数据重复问题，提出了取消自动提交offset和在下游实现幂等性等解决策略。
Kafka的延时队列与消息重复解决方案
延时队列
设想一下，两个follower副本都已经拉取到了leader副本的最新位置，此时又向leader副本发送拉取请求，而leader副本并没有新的消息写入，那么此时leader副本该如何处理呢？
可以直接返回空的拉取结果给follower副本，不过在leader副本一直没有新消息写入的情况下，follower副本会一直发送拉取请求，并且总收到空的拉取结果，消耗资源。
Kafka在处理拉取请求时，会先读取一次日志文件，如果收集不到足够多（fetchMinBytes，由参数fetch.min.bytes配置，默认值为1）的消息，那么就会创建一个延时拉取操作（DelayedFetch）以等待拉取到足够数量的消息。当延时拉取操作执行时，会再读取一次日志文件，然后将拉取结果返回给follower副本。
延迟操作不只是拉取消息时的特有操作，在Kafka中有多种延时操作，比如延时数据删除、延时生产等。
对于延时生产（消息）而言，如果在使用生产者客户端发送消息的时候将acks参数设置为-1，那么就意味着需要等待ISR集合中的所有副本都确认收到消息之后才能正确地收到响应的结果，或者捕获超时异常。
假设某个分区有3个副本：leader、follower1和follower2，它们都在分区的ISR集合中。不考虑ISR变动的情况，Kafka在收到客户端的生产请求后，将消息3和消息4写入leader副本的本地日志文件。
由于客户端设置了acks为-1，那么需要等到follower1和follower2两个副本都收到消息3和消息4后才能告知客户端正确地接收了所发送的消息。如果在一定的时间内，follower1副本或follower2副本没能够完全拉取到消息3和消息4，那么就需要返回超时异常给客户端。生产请求的超时时间由参数request.timeout.ms配置，默认值为30000，即30s。
那么这里等待消息3和消
最低0.47元/天 解锁文章
扫一扫
1429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
