Kafka源码分析(五) - Server端 - 基于时间轮的延时组件

最新推荐文章于 2025-11-20 19:48:39 发布
原创 最新推荐文章于 2025-11-20 19:48:39 发布 · 1.9k 阅读 · 15
标签
#kafka #中间件 #java #架构 #后端
#消息队列

系列文章目录

Kafka源码分析-目录

一. 背景

Kafka内部涉及大量的"延时"操作，比如收到PRODUCE请求后可为副本等待一个timeout的时间后再响应客户端。

那我们讨论一个问题：Kafka为什么自己实现了一个延时任务组件，而不直接使用java的java.util.concurrent.DelayQueue？

可以按如下两点来分析这个事：

  1. DelayQueue提供了哪些能力？

  2. Kafka所面对的场景是怎样的，为什么DelayQueue不适用？

1.1 DelayQueue的能力

DelayQueue相关的接口/类如下图：
在这里插入图片描述
对应地，DelayQueue所提供的能力如下：

  1. 为任务指定延时时间
    DelayQueue所维护的任务都要实现Delayed接口；其中的getDelay方法返回了距离该任务所设定执行时间有多远；

  2. 任务存取的时间复杂度为O(log n)
    DelayQueue内部使用"优先级队列"来保存任务，该数据结构存取的时间复杂度为对数复杂度；

1.2 Kafka的业务场景

Kafka的业务背景有如下特点：

  1. 延时任务不一定非得等到超时后才执行，有一些事件会触发其提前执行；
    比如PRODUCE请求处理过程中，若副本的响应比较快，那收到了预期数量的副本响应后就可以开始给客户端发响应，不一定非得等满一个timeout的时间；

  2. 延时任务的"入队"操作QPS很高；
    Kafka就是为高QPS而生，内部会产生大量的延时任务；

对应地，Kafka对延时任务组件有如下两点要求：

  1. 要求有提前执行任务的能力；

  2. 要求尽可能降低延时任务入队操作的时间复杂度；
    (借助一个名为"时间轮"的数据结构，Kafka将时间复杂度实际降到了O(1))

这两点要求都无法通过直接应用DelayQueue的方式得到满足。

二. 组件接口

我们来看看Kafka的延时任务组件对外提供的接口，进而搞清楚其提供的能力和使用方式。

如下图：
在这里插入图片描述
左边两个类定义了"延时操作"：

  1. TimerTask
    描述了一个最基本的延时Task；定义了超时时间(delayMs属性)、提供了一个取消操作(cancel方法)；

  2. DelayedOperation
    描述了一个可被外部事件提前触发的TimerTask；其在TimerTask基础上提供了检查是否满足提前触发条件的方法(tryComplete)、并定义被外部事件提前触发后的行为(onComplete)和无事件触发直到超时后的行为(onExpiration)；这几个方法都需要DelayedOperation的子类进行实现；

右边的DelayedOperationPurgatory类定义了一个维护DelayOperaton的容器，其核心操作如下：

  1. tryCompleteElseWatch
    添加延时任务；该方法有两个入参：operation和watchkeys；前者是要添加的延时任务，后者是该任务要监听的事件类型(可以同时监听多个事件类型)；可以在kafka.server.DelayedOperationKey所在scala文件中查看目前可选的watchkeys类型；一个watchkey对应一个延时任务队列；

  2. checkAndComplete
    检查各任务是否以满足提前触发的条件；该方法在某个事件发生之后，逻辑是遍历watchkey对应的任务队列，逐个判断是否满足了触发条件；

  3. cancelForKey
    取消watchkey下的所有延时任务；

三. 实现

下文主要关注"延时"的实现方式。

3.1 业务模型

时间轮延时组件的思路如下：

  1. 仍然使用java的DelayQueue存储延时任务；
    但为了降低延时任务入队的事件复杂度，Kafka并不直接将单个延时任务直接存储于DelayQueue，而是先将延时任务列表(TimerTaskList)加入DelayQueue，然后再向对应的列表中添加延时任务 (TimerTaskList也有超时时间的概念，等于其中最快超时的任务的超时时间)。这样任务的入队就由向优先级队列添加元素变为了向TimerTaskList中添加元素；前者时间复杂度为O(logn)，后者时间复杂度为O(1)。

  2. 如何判断一个新的延时任务应该加到哪个TimerTaskList中？时间轮(TimingWheel)！
    delayQueue中存储了多个TimerTaskList，当拿到一个新的延时任务时，Kafka会使用TimingWheel来计算该延时任务应插入到哪个TimerTaskList。其实，TimingWheel的本质就是TimerTask和TimerTaskList之间的映射函数。

接下来通过一个具体的例子来说明这种映射逻辑：
在这里插入图片描述
先关注上图中①号时间轮。圆环中每一个单元格表示一个TimerTaskList。单元格有其关联的时间跨度；下方的"1s x 12"表示时间轮上共12个单元格，每个单元格的时间跨度为1秒。有一个指针指向了"当前时间"所对应的单元格。顺时针方向为时间流动方向。

当收到一个延迟时间在0-1s的TimerTask时，会将其追加到①号时间轮的橙色单元格中。当收到一个延时时间在3-4s的TimerTask时，会将其追加到①号时间轮的黄色单元格中。以此类推。

现在有个问题：①号时间轮能表示的最大延迟时间是12秒，那如果收到了延迟13秒的任务该怎么办？这时该用到②号时间轮了，我们称②号为①号的"溢出时间轮"。②号时间轮

最低0.47元/天 解锁文章
Kafka-时间轮和延迟操作-源码流程
qq_35040959的博客
07-01 2119
DelayedProduce通过DelayedOperationPurgatory.tryCompleteElseWatch()被放入Watchers和SystemTimer中。Watchers的tryCompleteWatched()方法会尝试完成DelayedProduce（调用DelayedProduce的tryComplete()方法），那么tryCompleteWatched()是怎么被调用的呢？分区的HW发生了变动（acks = -1时）
Kafka中时间轮分析与Java实现
justlpf的专栏
04-19 1658
https://www.cnblogs.com/softlin/p/7426083.html在Kafka中应用了大量的延迟操作但在Kafka中 并没用使用JDK自带的Timer或是DelayQueue用于延迟操作，而是使用自己开发的DelayedOperationPurgatory组件用于管理延迟操作，Kafka这类分布式框架有大量延迟操作并且对性能要求及其高，而java.util.Timer与java.util.concurrent.DelayQueue的插入和删除时间复杂度都为对数阶O(log n)并不
Kafka 核心源码解读【五】--延迟操作模块
桑凯旋的博客
01-02 1774
在开始介绍时间轮之前，我想先请你思考这样一个问题：“如果是你，你会怎么实现 Kafka 中的延时请求呢？”针对这个问题，我的第一反应是使用 Java 的 DelayQueue。毕竟，这个类是 Java 天然提供的延时队列，非常适合建模延时对象处理。实际上，Kafka 的第一版延时请求就是使用 DelayQueue 做的。但是，DelayQueue 有一个弊端：它插入和删除队列元素的时间复杂度是 O(logN)。对于 Kafka 这种非常容易积攒几十万个延时请求的场景来说，该数据结构的性能是瓶颈。
Kafka 核心源码解读
justlpf的专栏
04-20 1985
在开始介绍时间轮之前，思考这样一个问题：“怎么实现 Kafka 中的延时请求呢？”针对这个问题，第一反应是使用Java的DelayQueue。毕竟，这个类是 Java 天然提供的延时队列，非常适合建模延时对象处理。实际上，Kafka 的第一版延时请求就是使用 DelayQueue 做的。但是，DelayQueue 有一个弊端：它插入和删除队列元素的时间复杂度是 O(logN)。对于 Kafka 这种非常容易积攒几十万个延时请求的场景来说，该数据结构的性能是瓶颈。
Kafka消息延迟处理技巧，降低错误率
BXA
06-14 4166
在评估Kafka消息延迟处理技巧的效果时，我们需要定义合理的实验场景和测试用例。确定实验数据的发送和接收方。设定实验场景，包括动作、触发条件和结果预期等。设定测试用例，包括性能验证、负载测试和容错测试等。
Kafka源码分析-目录(收藏关注不迷路)
村口老张头的专栏
04-22 496
Kafka源码分析目录
kafka的消息持久化文件
hncscwc的博客
01-03 797
最近排查kafka的问题，涉及到了kafka的消息存储，本文就相关内容进行总结。我们都知道，topic是有分区（partition）的概念的， 生产者往同一个topic发送的消息最终是发送到了不同的分区里面。也就是说，一个topic里的消息是由该topic下所有分区里的消息组成的。在同一个分区里，消息是有序的，而不同分区中，消息是不能保证有序的。有了这个简单认识后，自然可以知道，每个分区仅会存储该...
Kafka的TimingWheel(时间轮)算法
打酱油的葫芦娃
01-18 8474
Kafka中存在大量的延迟操作，比如延迟生产、延迟拉取和延迟删除等，Kafka并没有使用JDK自带的Timer或DelayQueue来实现延时的功能，而是基于时间轮算法自定义实现了一个用于延迟功能的定时器(SystemTimer)。 JDK中的Timer和DelayQueue单个任务的插入和删除的平均时间复杂度为O(logN),并不能满足Kafka的高性能要求，而基于时间轮可以将任务的插入和删除操作的时间复杂度降为O(1)。 下图即为Kafka的时间轮结构: Kafka的时间轮(TimingWheel)是
kafka TimingWheel(时间轮)
weixin_40757126的博客
05-09 561
上篇文章说到HashedWheelTimer结构是个数组+链表，而kafka TimingWheel结构也是个数组+链表，区别呢HashedWheelTimer只有一个轮（一个数组），而TimingWheel是多轮（多数组）。TimingWheel结构是由DelayQueue（这个实质上是object数组，最外层的轮）+buckets（数组+TimerTaskList）组成，如下图 kafka TimingWheel源码解析也是一坨，不多说这个了，想说下kafka和netty时间轮的一些区别，kafka的
springboot kafka 实现延时队列
热门推荐
qq_41889508的博客
04-21 6万+
延时队列的技术实现方案有：redis延时队列，Kafka延时队列，rabbit延时队列，Kafka延时队列等 本文章springboot kafka 实现延时队列，使用Kafka消费者的pause函数（暂停）和resume函数（恢复）+定时任务+事件监听机制+工厂。 延时任务的应用场景： 1，订单超时自动取消：用户下单后，如果在指定时间（半小时）内超时未完成支付，系统会自动取消订单，释放库存。 2，定时推送：比如消息通知，用户预约某个服务，系统会在服务开始前一定时间发送提醒短信。 3，定时任务 4，限时抢购
定时/延时任务-Kafka时间轮源码分析
Jwasx的博客
12-14 2129
Netty 的时间轮是不断执行的，不管有没有任务过期都会去遍历当前 tick 的链表下面的所有任务，同时推进时间轮，看看有没有任务需要执行，所以如果 Netty 时间轮中有一个很长时间都不会执行的任务，在遍历的时候就做了很多。在添加任务任务的时候，如果任务已经过期了或者任务被取消了，那么就会判断，如果不是任务取消，就会把任务丢到线程池里面去执行。所谓刷新链表，就是把这个链表上面的所有任务都删掉，然后执行传入的函数，这个方法是当链表过期的时候，就把上面的所有任务都删掉，然后一个一个任务执行具体逻辑。
Kafka中时间轮算法的使用
大叶子不小的博客
05-16 1064
Kafka心跳包的处理流程如下图所示：KafkaConsume主动发送心跳包 消费者会以3s的频率向服务端发送心跳包，服务端对应的入口为 KafkaApis的handleHeartbeatRequest方法。消费者加入消费组 在消费端重平衡过程中，客户端主动向其组协调器发起Join_Group(加入消费组)时，组协调器会认为收到一个有效的心跳包，服务端对应的处理入口：KafkaApis的handleJoinGroup方法。
kafka 延时消息处理
afeiqiang的专栏
08-10 1万+
你一定遇到过这种情况，接收到消息时并不符合马上处理的条件（例如频率限制），但是又不能丢掉，于是先存起来，过一阵子再来处理。系统应该怎么设计呢？可能你会想到数据库，用一个字段来标记执行的状态，或者设置一个等待的时间戳，不管是哪种都需要反复地从数据库存取，还要考虑出异常情况状态的维护。 作为一款优秀的消息处理服务，kafka 具有完善的事务管理，状态管理和灾难恢复功能。只要我们稍加变通一下，kafka 也能作为延迟消息处理的解决方案，而且实现上比用数据库简单得多。 以下代码均在 sp...
Kafka系列之：延时队列
zhengzaifeidelushang的博客
09-09 4016
Kafka系列之：延时队列
springboot kafka 实现延时队列_kafka延迟队列(1)
2401_84166965的博客
04-08 3719
3.1 优点： ①RabbitMQ的延迟队列是通过RabbitMQ的插件实现的，易于部署和使用。 ②RabbitMQ的延迟队列支持消息重试和消息顺序处理，可靠性较高。 ③支持消息持久化和分布式。 ④支持优先级队列和死信队列。 ⑤提供了丰富的插件和工具。3.2 缺点： ①RabbitMQ的延迟队列性能较低，不适用于高吞吐量的场景。 ②性能较低，不适合高并发场景。 ③实现延迟队列需要额外的配置，但是配置就很简单了。3.3应用场景： 适用于中小型的任务调度和消息通知，对可靠性要求高的场景。4.1 优点： ①Roc
Kafka消息延迟和时序性详解（文末送书）
weixin_44837153的博客
03-05 1474
一、概括1.1 介绍 Kafka 消息延迟和时序性Kafka 消息延迟和时序性对于大多数实时数据流应用程序至关重要。本章将深入介绍这两个核心概念，它们是了解 Kafka 数据流处理的关键要素。1.1.1 什么是 Kafka 消息延迟？Kafka 消息延迟是指消息从生产者发送到消息被消费者接收之间的时间差。这是一个关键的概念，因为它直接影响到数据流应用程序的实时性和性能。在理想情况下，消息应该以最小的延迟被传递，但在实际情况中，延迟可能会受到多种因素的影响。1.1.2 为什么消息延迟很重要。
springboot kafka 实现延时队列_kafka延迟队列
2401_86400247的博客
09-08 2244
②适用于轻量级的任务调度和消息通知场景，适合短期延迟任务，不适合长期任务，例如订单超时未支付等。①没有原生的延迟队列功能，需要使用topic和消费者组来实现，实现延迟队列需要额外的开发工作。①RabbitMQ的延迟队列是通过RabbitMQ的插件实现的，易于部署和使用。例如电商平台、社交软件等。①RocketMQ的延迟队列是RocketMQ原生支持的，易于使用和部署。②RocketMQ的延迟队列需要保证消息的顺序，可能会导致消息延迟。适用于大规模的数据处理，实时性要求较高的，高吞吐量的消息处理场景。
时间轮算法理解、Kafka实现
lonelymanontheway的博客
07-13 1855
时间轮、环形队列、Kafka实现
Kafka分层时间轮：百万级延迟任务的高效调度
最新发布
m0_37607945的博客
11-20 1094
设计要素说明解耦任务逻辑（TimerTask）与调度结构（）分离一致性双向绑定 + 同步保护，防止状态不一致并发安全volatile + 循环重试，处理并发移动场景性能O(1) 插入/删除，适合高频操作健壮性取消检测 + 防重复执行。
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值