所谓的延时工作给大家举个例子：你买了一张火车票，必须在30分钟之内付款，否则该订单被主动勾销。订单30分钟不付款主动勾销，这个工作就是一个延时工作。 我之前曾经写过2篇对于延时工作的文章：
- 《残缺实现-通过DelayQueue实现延时工作》
- 《延时工作(二)-基于netty工夫轮算法实战》
这两种办法都有一个毛病：都是基于单体利用的内存的形式运行延时工作的，一旦呈现单点故障，可能呈现延时工作数据的失落。所以此篇文章给大家介绍实现延时工作的第三种形式，联合redis zset实现延时工作，能够解决单点故障的问题。给出实现原理、残缺实现代码，以及这种实现形式的优缺点。
一、实现原理
首先来介绍一下实现原理，咱们须要应用redis zset来实现延时工作的需要，所以咱们须要晓得zset的利用个性。zset作为redis的有序汇合数据结构存在，排序的根据就是score。
所以咱们能够利用zset score这个排序的这个个性，来实现延时工作
- 在用户下单的时候，同时生成延时工作放入redis，key是能够自定义的，比方：
delaytask:order - value的值分成两个局部，一个局部是score用于排序，一个局部是member，member的值咱们设置为订单对象（如：订单编号），因为后续延时工作时效达成的时候，咱们须要有一些必要的订单信息（如：订单编号），能力实现订单主动勾销敞开的动作。
- 延时工作实现的重点来了，score咱们设置为：订单生成工夫 + 延时时长。 这样redis会对zset依照score延时工夫进行排序。
- 开启redis扫描工作，获取"以后工夫 > score"的延时工作并执行。即： 以后工夫 > 订单生成工夫 + 延时时长的时候 ，执行延时工作。
二、筹备工作
应用 redis zset 这个计划来实现延时工作的需要，首先必定是须要redis，这一点毫无疑问。redis的搭建网上有很多的文章，我这里就不赘述了。
其次，笔者长期的java类利用零碎开发都是应用SpringBoot来实现，所以也是习惯应用SpringBoot的redis集成计划。首先通过maven坐标引入spring-boot-starter-data-redis
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId></dependency>其次须要在Spring Boot的application.yml配置文件中，配置redis数据库的链接信息。我这里配置的是redis的单例，如果大家的生产环境是哨兵模式、或者是集群模式的redis，这里的配置形式须要进行微调。其实这部分内容在我的集体博客外面都已经零碎的介绍过，感兴趣的敌人能够关注我的集体博客。
spring: redis: database: 0 # Redis 数据库索引（默认为 0） host: 192.168.161.3 # Redis 服务器地址 port: 6379 # Redis 服务器连贯端口 password: 123456 # Redis 服务器连贯明码（默认为空） timeout: 5000 # 连贯超时，单位ms lettuce: pool: max-active: 8 # 连接池最大连接数（应用负值示意没有限度） 默认 8 max-wait: -1 # 连接池最大阻塞等待时间（应用负值示意没有限度） 默认 -1 max-idle: 8 # 连接池中的最大闲暇连贯 默认 8 min-idle: 0 # 连接池中的最小闲暇连贯 默认 0三、代码实现
上面的这个类就是延时工作的外围实现了，一共蕴含三个外围办法，咱们来一一阐明一下：
- produce办法，用于生成订单-order为订单信息，能够是订单流水号，用于延时工作达到时效后敞开订单
- afterPropertiesSet办法是InitializingBean接口的办法，之所以实现这个接口，是因为咱们须要在利用启动的时候开启redis扫描工作。即：当OrderDelayService bean初始化的时候，开启redis扫描工作循环获取延时工作数据。
consuming函数，用于从redis获取延时工作数据，生产延时工作，执行超时订单敞开等操作。为了防止阻塞for循环，影响前面延时工作的执行，所以这个consuming函数肯定要做成异步的，参考Spring Boot异步工作及
Async注解的应用办法。我之前写过一个SpringBoot的可观测、易配置的异步工作线程池开源我的项目，源代码地址：https://gitee.com/hanxt/zimug... 。我的这个zimug-monitor-threadpool开源我的项目，能够做到对线程池应用状况的监控，我本人平时用的成果还不错，向大家举荐一下！@Componentpublic class OrderDelayService implements InitializingBean {//redis zset keypublic static final String ORDER_DELAY_TASK_KEY = "delaytask:order";@Resourceprivate StringRedisTemplate stringRedisTemplate;//生成订单-order为订单信息，能够是订单流水号，用于延时工作达到时效后敞开订单public void produce(String orderSerialNo){ stringRedisTemplate.opsForZSet().add( ORDER_DELAY_TASK_KEY, // redis key orderSerialNo, // zset member //30分钟延时 System.currentTimeMillis() + (30 * 60 * 1000) //zset score );}//延时工作，也是异步工作，延时工作达到时效之后敞开订单，并将延时工作从redis zset删除@Async("test")public void consuming(){ Set<ZSetOperations.TypedTuple<String>> orderSerialNos = stringRedisTemplate.opsForZSet().rangeByScoreWithScores( ORDER_DELAY_TASK_KEY, 0, //延时工作score最小值 System.currentTimeMillis() //延时工作score最大值（以后工夫） ); if (!CollectionUtils.isEmpty(orderSerialNos)) { for (ZSetOperations.TypedTuple<String> orderSerialNo : orderSerialNos) { //这里依据orderSerialNo去检查用户是否实现了订单领取 //如果用户没有领取订单，去执行订单敞开的操作 System.out.println("订单" + orderSerialNo.getValue() + "超时被主动敞开"); //订单敞开之后，将订单延时工作从队列中删除 stringRedisTemplate.opsForZSet().remove(ORDER_DELAY_TASK_KEY, orderSerialNo.getValue()); } }}//该类对象Bean实例化之后，就开启while扫描工作@Overridepublic void afterPropertiesSet() throws Exception { new Thread(() -> { //开启新的线程，否则SpringBoot利用初始化无奈启动 while(true){ try { Thread.sleep(5 * 1000); //每5秒扫描一次redis库获取延时数据，不必太频繁没必要 } catch (InterruptedException e) { e.printStackTrace(); //本文只是示例，生产环境请做好相干的异样解决 } consuming(); } }).start();}}更多的内容参考代码中的正文，须要关注的点是：
- 上文中的rangeByScoreWithScores办法用于从redis中获取延时工作，score大于0小于以后工夫的所有延时工作，都将被从redis外面取出来。每5秒执行一次，所以延时工作的误差不会超过5秒。
- 上文中的订单信息，我只保留了订单惟一流水号，用于敞开订单。如果你的业务须要传递更多的订单信息，请应用RedisTemplate操作订单类对象，而不是StringRedisTemplate操作订单流水号字符串。
订单下单的时候，应用如下的办法，将订单序列号放入redis zset中即可实现延时工作
orderDelayService.produce("这里填写订单编号");四、优缺点
应用redis zset来实现延时工作的长处是：绝对于本文结尾介绍的两种办法，咱们的延时工作是保留在redis外面的，redis具备数据长久化的机制，能够无效的防止延时工作数据的失落。另外，redis还能够通过哨兵模式、集群模式无效的防止单点故障造成的服务中断。
至于毛病嘛，我感觉没什么毛病。如果非要勉强的说一个毛病的话，那就是咱们须要额定保护redis服务，减少了硬件资源的需要和运维老本。然而当初随着微服务的衰亡，redis简直曾经成了利用零碎的标配，redis复用即可，所以我感觉这也算不上什么毛病吧！
码文不易，如果您感觉有帮忙，请帮忙点击在看或者分享，没有您的反对我可能无奈坚持下去！
欢送关注我的布告号：字母哥杂谈，回复003赠送作者专栏《docker修炼之道》的PDF版本，30余篇精品docker文章。字母哥博客：zimug.com