記住，永遠不要使用 Redis 過期監(jiān)聽實現(xiàn)定時任務(wù)！
閱讀本文大概需要 3.5 分鐘。
來自：cnblogs.com/Finley/p/16395466.html
使用 rocketmq、rabbitmq、pulsar 等消息隊列的延時投遞功能
使用 redisson 提供的 DelayedQueue
使用 redis 的過期監(jiān)聽
使用 rabbitmq 的死信隊列
使用非持久化的時間輪
redis 過期監(jiān)聽
keyspace-notifications: timing-of-expired-events中明確指出：Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero
fire and forget)策略，并不像消息隊列一樣保證送達。當(dāng)訂閱事件的客戶端會丟失所有在斷線期間所有分發(fā)給它的事件。rabbitmq 死信
Dead Letter) 是 rabbitmq 提供的一種機制。當(dāng)一條消息滿足下列條件之一那么它會成為死信：消息被否定確認(rèn)（如
channel.basicNack) 并且此時requeue 屬性被設(shè)置為false。消息在隊列的存活時間超過設(shè)置的TTL時間
消息隊列的消息數(shù)量已經(jīng)超過最大隊列長度
創(chuàng)建一個交換機作為死信交換機
在業(yè)務(wù)隊列中配置
x-dead-letter-exchange和x-dead-letter-routing-key，將第一步的交換機設(shè)為業(yè)務(wù)隊列的死信交換機在死信交換機上創(chuàng)建隊列，并監(jiān)聽此隊列
rabbitmq-delayed-message-exchange ，推薦使用官方插件來做延時消息。這里說點題外話，使用 redis 過期監(jiān)聽或者 rabbitmq 死信隊列做延時任務(wù)都是以設(shè)計者預(yù)想之外的方式使用中間件，這種出其不意必自斃的行為通常會存在某些隱患，比如缺乏一致性和可靠性保證，吞吐量較低、資源泄漏等。比較出名的一個事例是很多人使用 redis 的 list 作為消息隊列，以致于最后作者看不下去寫了 disque 并最后演變?yōu)?nbsp; redis stream。工作中還是盡量不要濫用中間件，用專業(yè)的組件做專業(yè)的事
時間輪
redisson delayqueue
redisson delayqueue 是一種基于 redis zset 結(jié)構(gòu)的延時隊列實現(xiàn)。delayqueue 中有一個名為 timeoutSetName 的有序集合，其中元素的 score 為投遞時間戳。delayqueue 會定時使用 zrangebyscore 掃描已到投遞時間的消息，然后把它們移動到就緒消息列表中。delayqueue 保證 redis 不崩潰的情況下不會丟失消息，在沒有更好的解決方案時不妨一試。redisson delayqueue 等定時任務(wù)中間件時可以同時使用掃描數(shù)據(jù)庫的方法作為補償機制，避免中間件故障造成任務(wù)丟失。結(jié)論
首先推薦使用
rocketmq、pulsar等擁有定時投遞功能的消息隊列。在不方便獲得專業(yè)消息隊列時可以考慮使用
redisson delayqueue等基于 redis 的延時隊列方案，但要為 redis 崩潰等情況設(shè)計補償保護機制。在無法使用
redisson delayqueue等方案時可以考慮使用時間輪。由于時間輪重啟遠比 redis 重啟要頻繁，定時掃庫等保護機制更為重要。永遠不要使用 redis 過期監(jiān)聽實現(xiàn)定時任務(wù)。
互聯(lián)網(wǎng)初中高級大廠面試題(9個G) 內(nèi)容包含Java基礎(chǔ)、JavaWeb、MySQL性能優(yōu)化、JVM、鎖、百萬并發(fā)、消息隊列、高性能緩存、反射、Spring全家桶原理、微服務(wù)、Zookeeper......等技術(shù)棧！
?戳閱讀原文領(lǐng)?。?/span> 朕已閱
