首頁 > 軟體

Redis實現延遲佇列的全流程詳解

2023-03-15 06:02:16

1、前言

1.1、什麼是延遲佇列

延時佇列相比於普通佇列最大的區別就體現在其延時的屬性上,普通佇列的元素是先進先出,按入隊順序進行處理,而延時佇列中的元素在入隊時會指定一個延遲時間,表示其希望能夠在經過該指定時間後處理。從某種意義上來講,延遲佇列的結構並不像一個佇列,而更像是一種以時間為權重的有序堆結構。

1.2、應用場景

我們在一些業務場景中,經常會遇到一些需要經歷一段時間後,或者到達某個時間節點才會執行的功能。就比如以下這些場景:

新建一個訂單,在規定時間內未支付需要自動取消 外賣或者打車在預計時間到達的前十分鐘提醒騎手或者司機即將超時 快遞收貨後在規定時間內使用者沒有確認收貨會自動確認收貨 預定的會議在會議開始前十分鐘會去提醒你儘快加入會議 每日週報在截止半小時前會提醒你儘快提交

1.3、為什麼要使用延遲佇列

對於一些資料量小並且對資料的時效性不怎麼要求的專案來說,最簡單有效的方法就是寫一個定時任務去掃描資料庫以達到業務的實現。當然,如果在資料達到數百萬或者千萬級別的時候,如果去定時掃描資料庫,容易捱揍哈。想信大家也有所瞭解,當資料達到這種地步的時候,還去定時掃表會非常低效,甚至對於那些定時間隔比較小的情景來說,這一遍還沒掃完下一遍就要開始了。這時候如果用延遲佇列的話或許會很有效。

實現延遲佇列的幾種途徑

  • Quartz 定時任務
  • DelayQueue 延遲佇列
  • Redis sorted set Redis
  • 過期鍵監聽回撥
  • RabbitMQ死信佇列
  • RabbitMQ基於外掛實現延遲佇列
  • wheel時間輪演演算法

2、Redis sorted set

在Redis中,zet作為有序集合,可以利用其有序的特性,將任務新增到zset中,將任務的到期時間作為score,利用zset的預設有序特性,獲取score值最小的元素(也就是最近到期的任務),判斷系統時間與該任務的到期時間大小,如果達到到期時間,就執行業務,並刪除該到期任務,繼續判斷下一個元素,如果沒有到期,就sleep一段時間(比如1秒),如果集合為空,也sleep一段時間。

通過zadd命令向佇列delayqueue中新增元素,並設定score值表示元素過期的時間;向delayqueue新增三個order1、order2、order3,分別是10秒、20秒、30秒後過期。

zadd delayqueue 3 order3

消費端輪詢佇列delayqueue,將元素排序後取最小時間與當前時間比對,如小於當前時間代表已經過期移除key。

/**
 * 消費訊息
 */
public void pollOrderQueue() {
    while (true) {
        Set<Tuple> set = jedis.zrangeWithScores(DELAY_QUEUE, 0, 0);
        String value = ((Tuple) set.toArray()[0]).getElement();
        int score = (int) ((Tuple) set.toArray()[0]).getScore();
        Calendar cal = Calendar.getInstance();
        int nowSecond = (int) (cal.getTimeInMillis() / 1000);
        if (nowSecond >= score) {
            jedis.zrem(DELAY_QUEUE, value);
            System.out.println(sdf.format(new Date()) + " removed key:" + value);
        }
        if (jedis.zcard(DELAY_QUEUE) <= 0) {
            System.out.println(sdf.format(new Date()) + " zset empty ");
            return;
        }
        Thread.sleep(1000);
    }
} 

我們看到執行結果符合預期:

2020-05-07 13:24:09 add finished.
2020-05-07 13:24:19 removed key:order1
2020-05-07 13:24:29 removed key:order2
2020-05-07 13:24:39 removed key:order3
2020-05-07 13:24:39 zset empty 

3、Redis 過期鍵監聽回撥

Redis的key過期回撥事件,也能達到延遲佇列的效果,簡單來說我們開啟監聽key是否過期的事件,一旦key過期會觸發一個callback事件。

修改redis.conf檔案開啟notify-keyspace-events Ex。 notify-keyspace-events Ex

Redis監聽設定,注入Bean RedisMessageListenerContainer。

其次,設定redis監聽器 最後,編寫redis key過期監聽回撥方法

@Configuration
public class RedisListenerConfig {
@Bean
RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) {
        RedisMessageListenerContainer container = new RedisMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
         return container;
    }
} 

編寫Redis過期回撥監聽方法,必須繼承KeyExpirationEventMessageListener ,有點類似於MQ的訊息監聽。

@Component
public class RedisKeyExpirationListener extends KeyExpirationEventMessageListener {
public RedisKeyExpirationListener(RedisMessageListenerContainer listenerContainer) {
    super(listenerContainer);
}
@Override
public void onMessage(Message message, byte[] pattern) {
      String expiredKey = message.toString();
      System.out.println("監聽到key:" + expiredKey + "已過期");
    }
} 

到這程式碼就編寫完成,非常的簡單,接下來測試一下效果,在redis-cli使用者端新增一個key並給定3s的過期時間。

set xiaofu 123 ex 3

在控制檯成功監聽到了這個過期的key。

監聽到過期的key為:xiaofu

4、Quartz定時任務

Quartz一款非常經典任務排程框架,在Redis、RabbitMQ還未廣泛應用時,超時未支付取消訂單功能都是由定時任務實現的。

匯入Quartz依賴

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-quartz</artifactId>
</dependency>
>在啟動類中使用@EnableScheduling註解開啟定時任務功能。
```java
@SpringBootApplication
@EnableScheduling
public class DelayQueueApplication {
    public static void main(String[] args) {
        SpringApplication.run(DelayQueueApplication.class, args);
    }
}

編寫定時任務

@Slf4j
@Component
public class QuartzDemo {
    /**
     * 每隔五秒開啟一次任務
     */
    @Scheduled(cron = "0/5 * * * * ? ")
    public void process(){
        log.info("--------------定時任務測試--------------");
    }
}

5、DelayQueue 延遲佇列

JDK中提供了一組實現延遲佇列的API,位於Java.util.concurrent包下DelayQueue。

DelayQueue是一個BlockingQueue(無界阻塞)佇列,它本質就是封裝了一個PriorityQueue(優先佇列),PriorityQueue內部使用完全二元堆積(不知道的自行了解哈)來實現佇列元素排序,我們在向DelayQueue佇列中新增元素時,會給元素一個Delay(延遲時間)作為排序條件,佇列中最小的元素會優先放在隊首。佇列中的元素只有到了Delay時間才允許從佇列中取出。佇列中可以放基本資料型別或自定義實體類,在存放基本資料型別時,優先佇列中元素預設升序排列,自定義實體類就需要我們根據類屬性值比較計算了。 先簡單實現一下看看效果,新增三個order入隊DelayQueue,分別設定訂單在當前時間的5秒、10秒、15秒後取消。

要實現DelayQueue延時佇列,隊中元素要implements Delayed 介面,這哥介面裡只有一個getDelay方法,用於設定延期時間。Order類中compareTo方法負責對佇列中的元素進行排序。

public class Order implements Delayed {
/**
 * 延遲時間
 */
@JsonFormat(locale = "zh", timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss")
private long time;
String name;
public Order(String name, long time, TimeUnit unit) {
    this.name = name;
    this.time = System.currentTimeMillis() + (time > 0 ? unit.toMillis(time) : 0);
}
@Override
public long getDelay(TimeUnit unit) {
    return time - System.currentTimeMillis();
}
@Override
public int compareTo(Delayed o) {
    Order Order = (Order) o;
    long diff = this.time - Order.time;
    if (diff <= 0) {
        return -1;
    } else {
        return 1;
    }
}
} 

DelayQueue的put方法是執行緒安全的,因為put方法內部使用了ReentrantLock鎖進行執行緒同步。DelayQueue還提供了兩種出隊的方法poll()和take() , poll()為非阻塞獲取,沒有到期的元素直接返回null;take()阻塞方式獲取,沒有到期的元素執行緒將會等待。

public class DelayQueueDemo {
public static void main(String[] args) throws InterruptedException {
    Order Order1 = new Order("Order1", 5, TimeUnit.SECONDS);
    Order Order2 = new Order("Order2", 10, TimeUnit.SECONDS);
    Order Order3 = new Order("Order3", 15, TimeUnit.SECONDS);
    DelayQueue<Order> delayQueue = new DelayQueue<>();
    delayQueue.put(Order1);
    delayQueue.put(Order2);
    delayQueue.put(Order3);
    System.out.println("訂單延遲佇列開始時間:" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
    while (delayQueue.size() != 0) {
        /**
         * 取佇列頭部元素是否過期
         */
        Order task = delayQueue.poll();
        if (task != null) {
            System.out.format("訂單:{%s}被取消, 取消時間:{%s}n", task.name,  
            LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
        }
        Thread.sleep(1000);
    }
}
} 

上邊只是簡單的實現入隊與出隊的操作,實際開發中會有專門的執行緒,負責訊息的入隊與消費。

執行後看到結果如下,Order1、Order2、Order3 分別在 5秒、10秒、15秒後被執行,至此就用DelayQueue實現了延時佇列。

訂單延遲佇列開始時間:2020-05-06 14:59:09

訂單:{Order1}被取消, 取消時間:{2020-05-06 14:59:14}

訂單:{Order2}被取消, 取消時間:{2020-05-06 14:59:19}

訂單:{Order3}被取消, 取消時間:{2020-05-06 14:59:24}

6、RabbitMQ 延時佇列

利用 RabbitMQ 做延時佇列是比較常見的一種方式,而實際上RabbitMQ 自身並沒有直接支援提供延遲佇列功能,而是通過 RabbitMQ 訊息佇列的 TTL和 DXL這兩個屬性間接實現的。

先來認識一下 TTL和 DXL兩個概念:

Time To Live(TTL) :

TTL 顧名思義:指的是訊息的存活時間,RabbitMQ可以通過x-message-tt引數來設定指定Queue(佇列)和 Message(訊息)上訊息的存活時間,它的值是一個非負整數,單位為微秒。

RabbitMQ 可以從兩種維度設定訊息過期時間,分別是佇列和訊息本身

設定佇列過期時間,那麼佇列中所有訊息都具有相同的過期時間。 設定訊息過期時間,對佇列中的某一條訊息設定過期時間,每條訊息TTL都可以不同。 如果同時設定佇列和佇列中訊息的TTL,則TTL值以兩者中較小的值為準。而佇列中的訊息存在佇列中的時間,一旦超過TTL過期時間則成為Dead Letter(死信)。

Dead Letter Exchanges(DLX)

DLX即死信交換機,繫結在死信交換機上的即死信佇列。RabbitMQ的 Queue(佇列)可以設定兩個引數x-dead-letter-exchange 和 x-dead-letter-routing-key(可選),一旦佇列內出現了Dead Letter(死信),則按照這兩個引數可以將訊息重新路由到另一個Exchange(交換機),讓訊息重新被消費。

x-dead-letter-exchange:佇列中出現Dead Letter後將Dead Letter重新路由轉發到指定 exchange(交換機)。

x-dead-letter-routing-key:指定routing-key傳送,一般為要指定轉發的佇列。

佇列出現Dead Letter的情況有:

訊息或者佇列的TTL過期

佇列達到最大長度

訊息被消費端拒絕(basic.reject or basic.nack)

下邊結合一張圖看看如何實現超30分鐘未支付關單功能,我們將訂單訊息A0001傳送到延遲佇列order.delay.queue,並設定x-message-tt訊息存活時間為30分鐘,當到達30分鐘後訂單訊息A0001成為了Dead Letter(死信),延遲佇列檢測到有死信,通過設定x-dead-letter-exchange,將死信重新轉發到能正常消費的關單佇列,直接監聽關單佇列處理關單邏輯即可。

傳送訊息時指定訊息延遲的時間

public void send(String delayTimes) {
    amqpTemplate.convertAndSend("order.pay.exchange", "order.pay.queue","大家好我是延遲資料", message -> {
      // 設定延遲毫秒值
      message.getMessageProperties().setExpiration(String.valueOf(delayTimes));
      return message;
    });
  }
}

設定延遲佇列出現死信後的轉發規則

/**
   * 延時佇列
   */
  @Bean(name = "order.delay.queue")
  public Queue getMessageQueue() {
    return QueueBuilder
        .durable(RabbitConstant.DEAD_LETTER_QUEUE)
        // 設定到期後轉發的交換
        .withArgument("x-dead-letter-exchange", "order.close.exchange")
        // 設定到期後轉發的路由鍵
        .withArgument("x-dead-letter-routing-key", "order.close.queue")
        .build();
  }

7、時間輪

前邊幾種延時佇列的實現方法相對簡單,比較容易理解,時間輪演演算法就稍微有點抽象了。kafka、netty都有基於時間輪演演算法實現延時佇列,下邊主要實踐Netty的延時佇列講一下時間輪是什麼原理。

先來看一張時間輪的原理圖,解讀一下時間輪的幾個基本概念

wheel :時間輪,圖中的圓盤可以看作是鐘錶的刻度。比如一圈round 長度為24秒,刻度數為 8,那麼每一個刻度表示 3秒。那麼時間精度就是 3秒。時間長度 / 刻度數值越大,精度越大。

當新增一個定時、延時任務A,假如會延遲25秒後才會執行,可時間輪一圈round 的長度才24秒,那麼此時會根據時間輪長度和刻度得到一個圈數 round和對應的指標位置 index,也是就任務A會繞一圈指向0格子上,此時時間輪會記錄該任務的round和 index資訊。當round=0,index=0 ,指標指向0格子 任務A並不會執行,因為 round=0不滿足要求。

所以每一個格子代表的是一些時間,比如1秒和25秒 都會指向0格子上,而任務則放在每個格子對應的連結串列中,這點和HashMap的資料有些類似。

Netty構建延時佇列主要用HashedWheelTimer,HashedWheelTimer底層資料結構依然是使用DelayedQueue,只是採用時間輪的演演算法來實現。

下面我們用Netty 簡單實現延時佇列,HashedWheelTimer建構函式比較多,解釋一下各引數的含義。

ThreadFactory :表示用於生成工作執行緒,一般採用執行緒池;

tickDuration和unit:每格的時間間隔,預設100ms;

ticksPerWheel:一圈下來有幾格,預設512,而如果傳入數值的不是2的N次方,則會調整為大於等於該引數的一個2的N次方數值,有利於優化hash值的計算。

public HashedWheelTimer(ThreadFactory threadFactory, long tickDuration, TimeUnit unit, int ticksPerWheel) {
    this(threadFactory, tickDuration, unit, ticksPerWheel, true);
  }

TimerTask:一個定時任務的實現介面,其中run方法包裝了定時任務的邏輯。

Timeout:一個定時任務提交到Timer之後返回的控制程式碼,通過這個控制程式碼外部可以取消這個定時任務,並對定時任務的狀態進行一些基本的判斷。 Timer:是HashedWheelTimer實現的父介面,僅定義瞭如何提交定時任務和如何停止整個定時機制。

public class NettyDelayQueue {
  public static void main(String[] args) {
    final Timer timer = new HashedWheelTimer(Executors.defaultThreadFactory(), 5, TimeUnit.SECONDS, 2);
    //定時任務
    TimerTask task1 = new TimerTask() {
      public void run(Timeout timeout) throws Exception {
        System.out.println("order1 5s 後執行 ");
        timer.newTimeout(this, 5, TimeUnit.SECONDS);//結束時候再次註冊
      }
    };
    timer.newTimeout(task1, 5, TimeUnit.SECONDS);
    TimerTask task2 = new TimerTask() {
      public void run(Timeout timeout) throws Exception {
        System.out.println("order2 10s 後執行");
        timer.newTimeout(this, 10, TimeUnit.SECONDS);//結束時候再註冊
      }
    };
    timer.newTimeout(task2, 10, TimeUnit.SECONDS);
    //延遲任務
    timer.newTimeout(new TimerTask() {
      public void run(Timeout timeout) throws Exception {
        System.out.println("order3 15s 後執行一次");
      }
    }, 15, TimeUnit.SECONDS);
  }
}

從執行的結果看,order3、order3延時任務只執行了一次,而order2、order1為定時任務,按照不同的週期重複執行。

order1 5s 後執行
order2 10s 後執行
order3 15s 後執行一次
order1 5s 後執行
order2 10s 後執行

到此這篇關於Redis實現延遲佇列的全流程詳解的文章就介紹到這了,更多相關Redis延遲佇列內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!


IT145.com E-mail:sddin#qq.com