延时任务 - 基于 netty 时间轮算法实现

• 一、时间轮算法简介

• 二、时间轮 hello-world

• 三、异步任务线程池

• 四、时间轮优缺点

一、时间轮算法简介

为了大家能够理解下文中的代码，我们先来简单了解一下 netty 时间轮算法的核心原理

时间轮算法名副其实，时间轮就是一个环形的数据结构，类似于表盘，将时间轮分成多个 bucket(比如：0-8)。假设每个时间轮轮片的分隔时间段 tickDuration=1s（即：指针经过每个格子花费时间是 1 s），当前的时间 bucket=3，那么在 18 秒后需要被执行的任务需要落到（（3+18）%8=5 取余运算）的 5 号 bucket 上。假如有多个需要在该时间段内执行的任务，就会组成一个双向链表。另外针对时间轮我们要有下面的几个认知：

• 时间轮指针是一个 Worker 线程，在时间轮整点的时候执行双向链表中的任务。

• 时间轮算法的并不是精准的延时，它的执行精度取决于每个时间轮轮片的分隔时间段 tickDuration

• Worker 线程是单线程，一个 bucket、一个 bucket 的顺序处理任务。「所以我们的延时任务一定要做成异步任务，否则会影响时间轮后续任务的执行时间。」

二、时间轮 hello-world

实现一个延时任务的例子，需求仍然十分的简单：你买了一张火车票，必须在 30 分钟之内付款，否则该订单被自动取消。「订单 30 分钟不付款自动取消，这个任务就是一个延时任务。」 我们的火车票订单取消任务，从需求上看并不需要非常精准的延时，所以是可以使用时间轮算法来完成这个任务的。

首先通过 maven 坐标引入 netty

<dependency>    <groupId>io.netty</groupId>    <artifactId>netty-all</artifactId>    <version>4.1.45.Final</version></dependency>

然后我们创建一个时间轮，如果是 Spring 的开发环境，我们可以这么做。下文中我们 new 了一个包含 512 个 bucket 的时间轮，每个时间轮的轮片时间间隔是 100 毫秒。

@Bean("hashedWheelTimer")public HashedWheelTimer hashedWheelTimer(){    return new HashedWheelTimer(100, TimeUnit.MILLISECONDS, 512);}

举例：当用户买火车票下单的时候，向时间轮中添加一个 30 分钟的延时任务。延时任务将在 30 分钟之后被执行，下文的 lambda 表达式部分实现了一个 TimerTask(task)延时任务。这个延时任务的函数体内，请一定使用异步任务，即：单独起一个线程或者使用 SpringBoot 异步任务线程池。因为 Worker 线程是单线程的，你的任务处理时间长于 tickDuration 会妨碍后续时间轮轮片上的任务的执行。

//订单下单操作void order(String orderInfo) {  //下单的时候，向时间轮中添加一个30分钟的延时任务  hashedWheelTimer.newTimeout(task -> {    //注意这里使用异步任务线程池或者开启线程进行订单取消任务的处理    cancelOrder(orderInfo);  }, 30, TimeUnit.MINUTES);}

三、异步任务线程池

我们在上文中已经多次强调，时间轮的任务 TimerTask 的执行内容要做成异步的。最简单的做法就是接到一个任务之后启动一个线程处理该任务。在 Spring 环境下其实我们有更好的选择，就是使用 Spring 的线程池，这个线程池是可以自定义的。比如：下文中的用法是我事先定义了一个名字为 test 的线程池，然后通过 @Async 使用即可。

@Async("test")public void cancelOrder(String orderInfo){  //查询订单支付信息，如果用户未支付，关闭订单}

可能有的朋友，还不知道该如何自定义一个 Spring 线程池，可以参考：我之前写过一个 SpringBoot 的「可观测、易配置」的线程池开源项目，源代码地址：https://gitee.com/hanxt/zimug-monitor-threadpool 。我的这个 zimug-monitor-threadpool 开源项目，可以做到对线程池使用情况的监控，我自己平时用的效果还不错，向大家推荐一下！

四、时间轮优缺点

时间轮算法实现延时任务的优点就是，相对于使用 JDK 的 DelayQueue，其算法上具有优势，执行性能相对好一些。其缺点就是所有的延时任务以及延时触发的管理，都是在单个应用服务的内存中进行的，一旦该应用服务发生故障重启服务，时间轮任务数据将全部丢失。这一缺点和 DelayQueue 是一样的。为了解决这个问题，我们可以使用 redis、RocketMQ 等分布式中间件来管理延时任务消息的方式来实现延时任务，这个我会在后续的文章中为大家介绍。

更多精彩内容，可以通过我的主页关注我哦，期待您的关注，您的支持是我不竭的创作动力！