所謂的延時任務給大家舉個例子：你買了一張火車票，必須在30分鐘之內付款，否則該訂單被自動取消。訂單30分鐘不付款自動取消，這個任務就是一個延時任務。 我之前已經寫過2篇關於延時任務的文章：
這兩種方法都有一個缺點：都是基於單體應用的內存的方式運行延時任務的，一旦出現單點故障，可能出現延時任務數據的丟失。所以此篇文章給大家介紹實現延時任務的第三種方式，結合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-monitor-threadpool 。我的這個zimug-monitor-threadpool開源項目，可以做到對線程池使用情況的監控，我自己平時用的效果還不錯，向大家推薦一下！
@Component
public class OrderDelayService implements InitializingBean {
//redis zset key
public static final String ORDER_DELAY_TASK_KEY = "delaytask:order";
@Resource
private 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掃描任務
@Override
public 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