「實踐總結」訂單逾時自動取消

在進行開發的過程中，在開發的時候，有遇到相關的延時支付相關的問題，在解決延時支付的相關的問題的時候，會有很多種的解決辦法，現在就講對應的解決辦法先進行相關的總結操作；

「引言」

在開發中，往往會遇到一些關于延時任務的需求。例如

• 生成訂單 30 分鐘未支付，則自動取消

• 生成訂單 60 秒後，給使用者發短信

對上述的任務，我們給一個專業的名字來形容，那就是延時任務。那麼這裡就會産生一個問題，這個延時任務和定時任務的差別究竟在哪裡呢？一共有如下幾點差別

1. 定時任務有明确的觸發時間，延時任務沒有

1. 定時任務有執行周期，而延時任務在某事件觸發後一段時間内執行，沒有執行周期

1. 定時任務一般執行的是批處理操作是多個任務，而延時任務一般是單個任務

下面，我們以判斷訂單是否逾時為例，進行方案分析！

大家對電商購物應該都比較熟悉了，我們應該注意到，在下單之後，通常會有一個倒計時，如果超過支付時間，訂單就會被自動取消

今天，我們來聊聊訂單逾時未支付自動取消的幾種方案。一般來說，在針對訂單延時支付，之後自動取消的主要是兩種功能要求，一個是本地定時任務，還有一個是分布式定時任務；

定時任務實作方式有很多種，大概可以分為兩類：本地定時任務和分布式定時任務。

針對具體的分布式定時任務，常用的主要有，xxl-job,elastic-job;

經常使用的本地定時任務，主要的還是用相關的Quartz，還有相關的SpringTask,以及延遲線程池，和對應的JDK Timer,還有永動機線程

本地定時任務，适用于單機版的業務系統，實作方式非常多樣：

• 永動機線程：開啟一個線程，通過sleep去完成定時，一些開源中間件的某些定時任務是通過這種方式實作的。

• JDK Timer：JDK提供了Timer API，也提供了很多周期性的方法。

• 延遲線程池：JDK還提供了延遲線程池ScheduledExecutorService，API和Timer類似。

• Spring Task：Sprig架構也提供了一些定時任務的實作，使用起來更加簡單。

• Quartz：Quartz架構更進一步，提供了可以動态配置的線程池。

分布式定時任務：适用于分布式的業務系統，主要的實作架構有兩種：

• xxl-job：大衆點評的許雪裡開源的，一款基于MySQL的輕量級分布式定時任務架構。

• elastic-job：當當開發的彈性分布式任務排程系統，功能很強大，相對重一些。

定時任務實作的優點是開發起來比較簡單，但是它也有一些缺點：

• 對資料庫的壓力很大，定時任務造成人為的波峰，執行的時刻資料庫的壓力會陡增

• 計時不準，定時任務做不到非常精确的時間控制，比如半小時訂單過期，但是定時任務很難卡準這個點

2.被動取消

在文章開頭的那個倒計時器，大家覺得是怎麼做的呢？一般是用戶端計時+服務端檢查。

什麼意思呢？就是這個倒計時由用戶端去做，但是用戶端定時去服務端檢查，修正倒計時的時間。

那麼，這個訂單逾時自動取消，也可以由用戶端去做：

• 使用者留在收銀台的時候，用戶端倒計時+主動查詢訂單狀态，服務端每次都去檢查一下訂單是否逾時、剩餘時間

• 使用者每次進入訂單相關的頁面，查詢訂單的時候，服務端也檢查一下訂單是否逾時

被動取消

這種方式實作起來也比較簡單，但是它也有缺點：

• 依賴用戶端，如果用戶端不發起請求，訂單可能永遠沒法過期，一直占用庫存

當然，也可以被動取消+定時任務，通過定時任務去做兜底的操作

3.延時消息

第三種方案，就是利用延時消息了，可以使用RocketMQ、RabbitMQ、Kafka的延時消息，消息發送後，有一定延時才會投遞。

我們用的就是這種，消息隊列采用的是RocketMQ，其實RocketMQ延時也是利用定時任務實作的。

使用延時消息的優點是比較高效、好擴充，缺點是引入了新的技術元件，增加了複雜度。

除了上面的三種，其實還有一些其它的方式，例如本地延遲隊列、時間輪算法、Redis過期監聽……

但是我覺得，應該不會有人真考慮過在生産上使用這些方法。

「方案分析」

「資料庫輪詢」

思路

該方案通常是在小型項目中使用，即通過一個線程定時的去掃描資料庫，通過訂單時間來判斷是否有逾時的訂單，然後進行 update 或 delete 等操作。

實作

部落客當年早期是用 quartz 來實作的(實習那會的事)，簡單介紹一下

maven 項目引入一個依賴如下所示

<dependency>
 <groupId>org.quartz-scheduler</groupId>
 <artifactId>quartz</artifactId>
 <version>2.2.2</version>
</dependency>
           

調用 Demo 類 MyJob 如下所示

public class MyJob implements Job {
    public void execute(JobExecutionContext context)
            throws JobExecutionException {
        System.out.println("要去資料庫掃描啦。。。");
    }

    public static void main(String[] args) throws Exception {
        // 建立任務
        JobDetail jobDetail = JobBuilder.newJob(MyJob.class)
                .withIdentity("job1", "group1").build();

        // 建立觸發器 每3秒鐘執行一次
        Trigger trigger = TriggerBuilder
                .newTrigger()
                .withIdentity("trigger1", "group3")
                .withSchedule(
                        SimpleScheduleBuilder.simpleSchedule()
                                .withIntervalInSeconds(3).repeatForever())
                .build();

        Scheduler scheduler = new StdSchedulerFactory().getScheduler();
        // 将任務及其觸發器放入排程器
        scheduler.scheduleJob(jobDetail, trigger);
        // 排程器開始排程任務
        scheduler.start();
    }
}
           

運作代碼，可發現每隔 3 秒，輸出如下

要去資料庫掃描啦。。。
           

優缺點

優點：簡單易行，支援叢集操作

缺點:

• (1)對伺服器記憶體消耗大

• (2)存在延遲，比如你每隔 3 分鐘掃描一次，那最壞的延遲時間就是 3 分鐘

• (3)假設你的訂單有幾千萬條，每隔幾分鐘這樣掃描一次，資料庫損耗極大

JDK 的延遲隊列

思路

該方案是利用 JDK 自帶的 DelayQueue 來實作，這是一個無界阻塞隊列，該隊列隻有在延遲期滿的時候才能從中擷取元素，放入 DelayQueue 中的對象，是必須實作 Delayed 接口的。

DelayedQueue 實作工作流程如下圖所示

其中Poll()：擷取并移除隊列的逾時元素，沒有則傳回空

take()：擷取并移除隊列的逾時元素，如果沒有則 wait 目前線程，直到有元素滿足逾時條件，傳回結果。

實作

定義一個類 OrderDelay 實作 Delayed，代碼如下：

import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;

public class OrderDelay implements Delayed {

    private String orderId;
    private long timeout;

    OrderDelay(String orderId, long timeout) {
        this.orderId = orderId;
        this.timeout = timeout + System.nanoTime();
    }

    public int compareTo(Delayed other) {
        if (other == this)
            return 0;

        OrderDelay t = (OrderDelay) other;
        long d = (getDelay(TimeUnit.NANOSECONDS) - t
                .getDelay(TimeUnit.NANOSECONDS));

        return (d == 0) ? 0 : ((d < 0) ? -1 : 1);

    }

    // 傳回距離你自定義的逾時時間還有多少
    public long getDelay(TimeUnit unit) {
        return unit.convert(timeout - System.nanoTime(),TimeUnit.NANOSECONDS);
    }

    void print() {
        System.out.println(orderId + "編号的訂單要删除啦。。。。");
    }
}
           

運作的測試 Demo 為，我們設定延遲時間為 3 秒。

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.DelayQueue;
import java.util.concurrent.TimeUnit;

public class DelayQueueDemo {

     public static void main(String[] args) {  

        // TODO Auto-generated method stub  

        List<String> list = new ArrayList<String>();  
        list.add("00000001");  
        list.add("00000002");  
        list.add("00000003");  
        list.add("00000004");  
        list.add("00000005");  

        DelayQueue<OrderDelay> queue = newDelayQueue<OrderDelay>();  
        long start = System.currentTimeMillis();  
        for(int i = 0;i<5;i++){  
            //延遲三秒取出
            queue.put(new OrderDelay(list.get(i),  
                    TimeUnit.NANOSECONDS.convert(3,TimeUnit.SECONDS)));  
                try {  
                     queue.take().print();  
                     System.out.println("After " +  
                             (System.currentTimeMillis()-start) + " MilliSeconds");  

            } catch (InterruptedException e) {  
                // TODO Auto-generated catch block  
                e.printStackTrace();  
            }  
        }  
    }   
}
           

輸出如下

00000001編号的訂單要删除啦。。。。After 3003 MilliSeconds 00000002編号的訂單要删除啦。。。。After 6006 MilliSeconds 00000003編号的訂單要删除啦。。。。After 9006 MilliSeconds 00000004編号的訂單要删除啦。。。。After 12008 MilliSeconds 00000005編号的訂單要删除啦。。。。After 15009 MilliSeconds
           

可以看到都是延遲 3 秒，訂單被删除。

優缺點

優點：效率高，任務觸發時間延遲低。

缺點：

• (1)伺服器重新開機後，資料全部消失，怕當機

• (2)叢集擴充相當麻煩

• (3)因為記憶體條件限制的原因，比如下單未付款的訂單數太多，那麼很容易就出現 OOM 異常

• (4)代碼複雜度較高

「時間輪算法」

思路

先上一張時間輪的圖(這圖到處都是啦)

時間輪算法可以類比于時鐘，如上圖箭頭（指針）按某一個方向按固定頻率輪動，每一次跳動稱為一個 tick。這樣可以看出定時輪由個 3 個重要的屬性參數，ticksPerWheel（一輪的tick數），tickDuration（一個 tick 的持續時間）以及 timeUnit（時間機關），例如當ticksPerWheel=60，tickDuration=1，timeUnit=秒，這就和現實中的始終的秒針走動完全類似了。

如果目前指針指在 1 上面，我有一個任務需要 4 秒以後執行，那麼這個執行的線程回調或者消息将會被放在 5 上。那如果需要在 20 秒之後執行怎麼辦，由于這個環形結構槽數隻到 8，如果要 20 秒，指針需要多轉 2 圈。位置是在 2 圈之後的 5 上面（20 % 8 + 1）。

實作

我們用 Netty 的 HashedWheelTimer 來實作

給 pom.xml 加上下面的依賴：

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

測試代碼 HashedWheelTimerTest 如下所示：

import io.netty.util.HashedWheelTimer;
import io.netty.util.Timeout;
import io.netty.util.Timer;
import io.netty.util.TimerTask;
import java.util.concurrent.TimeUnit;

public class HashedWheelTimerTest {
    static class MyTimerTask implements TimerTask{
        boolean flag;
        public MyTimerTask(boolean flag){
            this.flag = flag;
        }

        public void run(Timeout timeout) throws Exception {
            // TODO Auto-generated method stub
             System.out.println("要去資料庫删除訂單了。。。。");
             this.flag =false;
        }
    }

    public static void main(String[] argv) {
        MyTimerTask timerTask = new MyTimerTask(true);
        Timer timer = new HashedWheelTimer();
        timer.newTimeout(timerTask, 5, TimeUnit.SECONDS);
        int i = 1;

        while(timerTask.flag){
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }

            System.out.println(i+"秒過去了");
            i++;
        }
    }
}
           

優缺點

優點：效率高，任務觸發時間延遲時間比 delayQueue 低，代碼複雜度比 delayQueue 低。

缺點：

• (1)伺服器重新開機後，資料全部消失，怕當機

• (2)叢集擴充相當麻煩

• (3)因為記憶體條件限制的原因，比如下單未付款的訂單數太多，那麼很容易就出現 OOM 異常

redis 緩存

思路一：

利用 redis 的 zset，zset 是一個有序集合，每一個元素(member)都關聯了一個 score，通過 score 排序來取集合中的值

添加元素:

ZADD key score member [[score member] [score member] …]
           

按順序查詢元素：

ZRANGE key start stop [WITHSCORES]
           

查詢元素 score：

ZSCORE key member
           

移除元素：

ZREM key member [member …]
           

測試如下

# 添加單個元素
redis> ZADD page_rank 10 google.com
(integer) 1

# 添加多個元素
redis> ZADD page_rank 9 baidu.com 8 bing.com
(integer) 2
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"
5) "google.com"
6) "10"

# 查詢元素的score值
redis> ZSCORE page_rank bing.com
"8"

# 移除單個元素
redis> ZREM page_rank google.com
(integer) 1
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"
           

那麼如何實作呢？我們将訂單逾時時間戳與訂單号分别設定為 score 和 member，系統掃描第一個元素判斷是否逾時，具體如下圖所示：

實作一

import java.util.Calendar;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Tuple;

public class AppTest {
    private static final String ADDR = "127.0.0.1";
    private static final int PORT = 6379;
    private static JedisPool jedisPool = new JedisPool(ADDR, PORT);
    public static Jedis getJedis() {
       return jedisPool.getResource();
    }

    //生産者,生成5個訂單放進去
    public void productionDelayMessage(){
        for(int i=0;i<5;i++){
            //延遲3秒
            Calendar cal1 = Calendar.getInstance();
            cal1.add(Calendar.SECOND, 3);
            int second3later = (int) (cal1.getTimeInMillis() / 1000);
            AppTest.getJedis().zadd("OrderId",second3later,"OID0000001"+i);
            System.out.println(System.currentTimeMillis()+"ms:redis生成了一個訂單任務：訂單ID為"+"OID0000001"+i);
        }
    }

    //消費者，取訂單
    public void consumerDelayMessage(){
        Jedis jedis = AppTest.getJedis();
        while(true){
            Set<Tuple> items = jedis.zrangeWithScores("OrderId", 0, 1);
            if(items == null || items.isEmpty()){
                System.out.println("目前沒有等待的任務");
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
                continue;
            }

            int  score = (int) ((Tuple)items.toArray()[0]).getScore();
            Calendar cal = Calendar.getInstance();
            int nowSecond = (int) (cal.getTimeInMillis() / 1000);
            if(nowSecond >= score){
                String orderId = ((Tuple)items.toArray()[0]).getElement();
                jedis.zrem("OrderId", orderId);
                System.out.println(System.currentTimeMillis() +"ms:redis消費了一個任務：消費的訂單OrderId為"+orderId);
            }
        }
    }

    public static void main(String[] args) {
        AppTest appTest =new AppTest();
        appTest.productionDelayMessage();
        appTest.consumerDelayMessage();
    }
}
           

此時對應輸出如下：

可以看到，幾乎都是 3 秒之後，消費訂單。

然而，這一版存在一個緻命的硬傷，在高并發條件下，多消費者會取到同一個訂單号，我們上測試代碼 ThreadTest。

import java.util.concurrent.CountDownLatch;
public class ThreadTest {
    private static final int threadNum = 10;
    private static CountDownLatch cdl = newCountDownLatch(threadNum);
    static class DelayMessage implements Runnable{
        public void run() {
            try {
                cdl.await();
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }

            AppTest appTest =new AppTest();
            appTest.consumerDelayMessage();
        }
    }

    public static void main(String[] args) {
        AppTest appTest =new AppTest();
        appTest.productionDelayMessage();
        for(int i=0;i<threadNum;i++){
            new Thread(new DelayMessage()).start();
            cdl.countDown();
        }
    }
}
           

輸出如下所示：

顯然，出現了多個線程消費同一個資源的情況。

解決方案：

• (1)用分布式鎖，但是用分布式鎖，性能下降了，該方案不細說。

• (2)對 ZREM 的傳回值進行判斷，隻有大于 0 的時候，才消費資料，于是将consumerDelayMessage()方法中的如下代碼：

if(nowSecond >= score){
    String orderId = ((Tuple)items.toArray()[0]).getElement();
    jedis.zrem("OrderId", orderId);
    System.out.println(System.currentTimeMillis()+"ms:redis消費了一個任務：消費的訂單OrderId為"+orderId);
}
           

修改為：

if(nowSecond >= score){
    String orderId = ((Tuple)items.toArray()[0]).getElement();
    Long num = jedis.zrem("OrderId", orderId);
    if( num != null && num>0){
        System.out.println(System.currentTimeMillis()+"ms:redis消費了一個任務：消費的訂單OrderId為"+orderId);
    }
}
           

在這種修改後，重新運作 ThreadTest 類，發現輸出正常了。

思路二：

該方案使用 redis 的 Keyspace Notifications，中文翻譯就是鍵空間機制，就是利用該機制可以在 key 失效之後，提供一個回調，實際上是 redis 會給用戶端發送一個消息。是需要 redis 版本 2.8 以上。

實作二：

在 redis.conf 中，加入一條配置：

❝ notify-keyspace-events Ex

❞

運作代碼如下

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPubSub;

public class RedisTest {
    private static final String ADDR = "127.0.0.1";
    private static final int PORT = 6379;
    private static JedisPool jedis = new JedisPool(ADDR, PORT);
    private static RedisSub sub = new RedisSub();

    public static void init() {
        new Thread(new Runnable() {
            public void run() {
                jedis.getResource().subscribe(sub, "[email protected]__:expired");
            }
        }).start();
    }

    public static void main(String[] args) throws InterruptedException {
        init();

        for(int i =0;i<10;i++){
            String orderId = "OID000000"+i;
            jedis.getResource().setex(orderId, 3, orderId);
            System.out.println(System.currentTimeMillis()+"ms:"+orderId+"訂單生成");
        }
    }

    static class RedisSub extends JedisPubSub {
        @Override
        public void onMessage(String channel, String message) {
            System.out.println(System.currentTimeMillis()+"ms:"+message+"訂單取消");
        }
    }
}
           

輸出如下：

可以明顯看到 3 秒過後，訂單取消了。

ps：redis 的pub/sub機制存在一個硬傷，官網内容如下

❝ 原:Because Redis Pub/Sub is fire and forget currently there is no way to use this feature if your application demands reliable notification of events, that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.

翻: Redis的釋出/訂閱目前是即發即棄(fire and forget)模式的，是以無法實作事件的可靠通知。也就是說，如果釋出/訂閱的用戶端斷鍊之後又重連，則在用戶端斷鍊期間的所有事件都丢失了。

是以，方案二不是太推薦。當然，如果你對可靠性要求不高，可以使用。

❞

優缺點

優點：

• (1)由于使用 Redis 作為消息通道，消息都存儲在 Redis 中。如果發送程式或者任務處理程式挂了，重新開機之後，還有重新處理資料的可能性。

• (2)做叢集擴充相當友善

• (3)時間準确度高

缺點:

• (1)需要額外進行 redis 維護

使用消息隊列

我們可以采用 rabbitMQ 的延時隊列。RabbitMQ 具有以下兩個特性，可以實作延遲隊列：

• RabbitMQ 可以針對 Queue 和 Message 設定 x-message-tt，來控制消息的生存時間，如果逾時，則消息變為 dead letter。

• lRabbitMQ 的 Queue 可以配置 x-dead-letter-exchange 和 x-dead-letter-routing-key（可選）兩個參數，用來控制隊列内出現了 deadletter，則按照這兩個參數重新路由。

優缺點

優點: 高效，可以利用 rabbitmq 的分布式特性輕易的進行橫向擴充，消息支援持久化增加了可靠性。

缺點：本身的易用度要依賴于 rabbitMq 的運維。因為要引用 rabbitMq，是以複雜度和成本變高。

總結：

那麼如何實作延遲任務呢？

第一反應是利用cron方案來實作

啟動一個cron定時任務，每隔一段時間執行一次，比如30分鐘，找到那些逾時的資料，直接更新狀态，或者拿出來執行一些操作。如果資料量比較大，需要分頁查詢，分頁update，這将是一個for循環更新操作。

cron方案是很常見的一種方案，但是常見的不一定是最好的，主要有以下幾個問題：

• 當資料量大的時候輪詢效率低；

• 時效性不夠好，如果每小時輪詢一次，最差的情況時間誤差會達到1小時；

• 如果通過增加cron輪詢頻率來減少時間誤差，則會出現輪詢低效和重複計算的問題；

既然cron方案不是很理想，那就請出我們今天的主角，使用RocketMQ的延時消息解決。在建立訂單的時候發送一條延時消息到RocketMQ，30分鐘後消費者消費消息去檢查訂單的狀态，如果發現訂單未支付則取消訂單釋放庫存。

實作

RocketMQ延遲隊列的核心思路是：所有的延遲消息由producer發出之後，都會存放到同一個topic（SCHEDULE_TOPIC_XXXX）下，不同的延遲級别會對應不同的隊列序号，當延遲時間到之後，由定時線程讀取轉換為普通的消息存的真實指定的topic下，此時對于consumer端此消息才可見，進而被consumer消費。

注意：RocketMQ不支援任意時間的延時，隻支援以下幾個固定的延時等級

private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

下面我們結合SprintBoot利用RocketMQ發送延時消息

• 引入RocketMQ元件

<dependency>
 <groupId>org.apache.rocketmq</groupId>
 <artifactId>rocketmq-spring-boot-starter</artifactId>
</dependency>
           

• 增加RocketMQ的配置

rocketmq:  name-server: 172.31.0.44:9876  producer:    group: delay-group
           

• 編寫生産者

@[email protected] class DelayProduce {    @Autowired    private RocketMQTemplate rocketMQTemplatet;    public void sendDelayMessage(String topic,String message,int delayLevel){       SendResult sendResult = rocketMQTemplatet.syncSend(topic, MessageBuilder.withPayload(message).build(), 2000, delayLevel);        log.info("sendtime is {}", DateTimeFormatter.ofPattern("yyyy年MM月dd日 HH:mm:ss").format(LocalDateTime.now()));        log.info("sendResult is{}",sendResult);    }}
           

• 編寫消費者

@Slf4j
@Component
@RocketMQMessageListener(
        topic = "delay-topic",
        consumerGroup = "delay-group"
)
public class DelayConsumer implements RocketMQListener<String> {
    @Override
    public void onMessage(String message) {
        log.info("received message time is {}", DateTimeFormatter.ofPattern("yyyy年MM月dd日 HH:mm:ss").format(LocalDateTime.now()));
        log.info("received message is {}",message);
    }
}
           

• 測試

@RunWith(SpringRunner.class)
@SpringBootTest
public class DelayProduceTest {
    @Autowired
    private DelayProduce delayProduce;
 
    @Test
    public void sendDelayMessage() {
        delayProduce.sendDelayMessage("delay-topic","Hello,JAVA日知錄",5);
    }
}
           

這裡delayLevel設定成5，對應RocketMQ的延時等級就是1分鐘後投遞消息。

運作結果

發送時間

消費時間

修改延時級别

RocketMQ的延遲等級可以進行修改，以滿足自己的業務需求，可以修改/添加新的level。例如：你想支援1天的延遲，修改最後一個level的值為1d，這個時候依然是18個level；也可以增加一個1d，這個時候總共就有19個level。

• 打開RocketMQ的配置檔案，修改 messageDelayLevel 屬性

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
storePathRootDir = /app/rocketmq/data
messageDelayLevel=90s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
           

這次将延時等級1修改成了90s，生産者發送消息後需要90s後再進行消息投遞。修改完成後重新開機RocketMQ。nohup sh mqbroker -n localhost:9876 -c ../conf/broker.conf &

• 使用延時等級1發送消息

public void sendDelayMessage() {
 delayProduce.sendDelayMessage("delay-topic","Hello,JAVA日知錄",1);
}
           

測試

發送時間

消費時間

過比對發送時間與消費時間證明延時等級修改生效。

好了，各位朋友們，本期的内容到此就全部結束啦，能看到這裡的同學都是優秀的同學，下一個升職加薪的就是你了！

如果覺得這篇文章對你有所幫助的話請掃描下面二維碼加個關注。"轉發" 加 "在看"，養成好習慣！咱們下期再見！