JAVA 實(shí)現(xiàn)延遲隊(duì)列的方法
延遲隊(duì)列的需求各位應(yīng)該在日常開(kāi)發(fā)的場(chǎng)景中經(jīng)常碰到。比如:
- 用戶登錄之后5分鐘給用戶做分類推送;
- 用戶多少天未登錄給用戶做召回推送;
- 定期檢查用戶當(dāng)前退款賬單是否被商家處理等等場(chǎng)景。
一般這種場(chǎng)景和定時(shí)任務(wù)還是有很大的區(qū)別,定時(shí)任務(wù)是你知道任務(wù)多久該跑一次或者什么時(shí)候只跑一次,這個(gè)時(shí)間是確定的。延遲隊(duì)列是當(dāng)某個(gè)事件發(fā)生的時(shí)候需要延遲多久觸發(fā)配套事件,引子事件發(fā)生的時(shí)間不是固定的。
業(yè)界目前也有很多實(shí)現(xiàn)方案,單機(jī)版的方案就不說(shuō)了,現(xiàn)在也沒(méi)有哪個(gè)公司還是單機(jī)版的服務(wù),今天我們一一探討各種方案的大致實(shí)現(xiàn)。
1. Redis zset
這個(gè)方案比較常用,簡(jiǎn)單有效。利用 Redis 的 sorted set 結(jié)構(gòu),使用 timeStamp 作為 score,比如你的任務(wù)是要延遲5分鐘,那么就在當(dāng)前時(shí)間上加5分鐘作為 score ,輪詢?nèi)蝿?wù)每秒只輪詢 score 大于當(dāng)前時(shí)間的 key即可,如果任務(wù)支持有誤差,那么當(dāng)沒(méi)有掃描到有效數(shù)據(jù)的時(shí)候可以休眠對(duì)應(yīng)時(shí)間再繼續(xù)輪詢。
方案優(yōu)劣:
優(yōu)點(diǎn):
簡(jiǎn)單實(shí)用,一針見(jiàn)血。
缺點(diǎn):
- 單個(gè) zset 肯定支持不了太大的數(shù)據(jù)量,如果你有幾百萬(wàn)的延遲任務(wù)需求,大哥我還是勸你換一個(gè)方案;
- 定時(shí)器輪詢方案可能會(huì)有異常終止的情況需要自己處理,同時(shí)消息處理失敗的回滾方案,您也要自己處理。
所以,sorted set 的方案并不是一個(gè)成熟的方案,他只是一個(gè)快速可供落地的方案。
2. RabbitMQ隊(duì)列
下面說(shuō)一個(gè)可以落地的方案,這個(gè)方案也被大多數(shù)目前在架構(gòu)中使用了 RabbitMQ 的項(xiàng)目組使用。不好的一點(diǎn)就是,捆綁 RabbitMQ,當(dāng)你的架構(gòu)方案是要用別的 MQ 替換 RabbitMQ 的時(shí)候,你就蛋疼了(我現(xiàn)在正在經(jīng)歷)。
RabbitMQ 有兩個(gè)特性,一個(gè)是 Time-To-Live Extensions,另一個(gè)是 Dead Letter Exchanges。
Time-To-Live Extensions
RabbitMQ允許我們?yōu)橄⒒蛘哧?duì)列設(shè)置TTL(time to live),也就是過(guò)期時(shí)間。TTL表明了一條消息可在隊(duì)列中存活的最大時(shí)間,單位為毫秒。也就是說(shuō),當(dāng)某條消息被設(shè)置了TTL或者當(dāng)某條消息進(jìn)入了設(shè)置了TTL的隊(duì)列時(shí),這條消息會(huì)在經(jīng)過(guò)TTL秒后 “死亡”,成為Dead Letter。如果既配置了消息的TTL,又配置了隊(duì)列的TTL,那么較小的那個(gè)值會(huì)被取用。
Dead Letter Exchanges
在 RabbitMQ 中,一共有三種消息的 “死亡” 形式:
- 消息被拒絕。通過(guò)調(diào)用 basic.reject 或者 basic.nack 并且設(shè)置的 requeue 參數(shù)為 false;
- 消息因?yàn)樵O(shè)置了TTL而過(guò)期;
- 隊(duì)列達(dá)到最大長(zhǎng)度。
DLX同一般的 Exchange 沒(méi)有區(qū)別,它能在任何的隊(duì)列上被指定,實(shí)際上就是設(shè)置某個(gè)隊(duì)列的屬性。當(dāng)隊(duì)列中有 DLX 消息時(shí),RabbitMQ就會(huì)自動(dòng)的將 DLX 消息重新發(fā)布到設(shè)置的 Exchange 中去,進(jìn)而被路由到另一個(gè)隊(duì)列,publish 可以監(jiān)聽(tīng)這個(gè)隊(duì)列中消息做相應(yīng)的處理。
由上簡(jiǎn)介大家可以看出,RabbitMQ本身是不支持延遲隊(duì)列的,只是他的特性讓勤勞的 中國(guó)脫發(fā)群體 急中生智(為了完成任務(wù))弄出了這么一套可用的方案。
可用的方案就是:
- 如果有事件需要延遲那么將該事件發(fā)送到MQ 隊(duì)列中,為需要延遲的消息設(shè)置一個(gè)TTL;
- TTL到期后就會(huì)自動(dòng)進(jìn)入設(shè)置好的DLX,然后由DLX轉(zhuǎn)發(fā)到配置好的實(shí)際消費(fèi)隊(duì)列;
- 消費(fèi)該隊(duì)列的延遲消息,處理事件。
方案優(yōu)劣:
優(yōu)點(diǎn):
大品牌組件,用的放心。如果面臨大數(shù)據(jù)量需求可以很容易的橫向擴(kuò)展,同時(shí)消息支持持久化,有問(wèn)題可回滾。
缺點(diǎn):
- 配置麻煩,額外增加一個(gè)死信交換機(jī)和一個(gè)死信隊(duì)列的配置;
- RabbitMQ 是一個(gè)消息中間件,TTL 和 DLX 只是他的一個(gè)特性,將延遲隊(duì)列綁定在一個(gè)功能軟件的某一個(gè)特性上,可能會(huì)有風(fēng)險(xiǎn)。不要杠,當(dāng)你們組不用 RabbitMQ 的時(shí)候遷移很痛苦;
- 消息隊(duì)列具有先進(jìn)先出的特點(diǎn),如果第一個(gè)進(jìn)入隊(duì)列的消息 A 的延遲是10分鐘,第二個(gè)進(jìn)入隊(duì)列的消息B 的延遲是5分鐘,期望的是誰(shuí)先到 TTL誰(shuí)先出,但是事實(shí)是B已經(jīng)到期了,而還要等到 A 的延遲10分鐘結(jié)束A先出之后,B 才能出。所以在設(shè)計(jì)的時(shí)候需要考慮不同延遲的消息要放到不同的隊(duì)列。另外該問(wèn)題官方已經(jīng)給出了插件來(lái)支持:插件地址。
3. 基于 Netty#HashedWheelTimer類方法的實(shí)現(xiàn)
HashedWheelTimer
是 Netty 中 的一個(gè)基礎(chǔ)工具類,主要用來(lái)高效處理大量定時(shí)任務(wù),且任務(wù)對(duì)時(shí)間精度要求相對(duì)不高, 在Netty 中的應(yīng)用場(chǎng)景就是連接超時(shí)或者任務(wù)處理超時(shí),一般都是操作比較快速的任務(wù),缺點(diǎn)是內(nèi)存占用相對(duì)較高。
算法思想
HashedWheelTimer
主要還是一個(gè) DelayQueue
和一個(gè)時(shí)間輪算法組合。
Hash Wheel Timer
是一個(gè)環(huán)形結(jié)構(gòu),可以想象成時(shí)鐘,分為很多格子,一個(gè)格子代表一段時(shí)間(越短Timer精度越高),并用一個(gè)List保存在該格子上到期的所有任務(wù)。同時(shí)一個(gè)指針隨著時(shí)間流逝一格一格轉(zhuǎn)動(dòng),并執(zhí)行對(duì)應(yīng)List中所有到期的任務(wù)。
以上圖為例,假設(shè)一個(gè)格子是1s,則整個(gè)時(shí)間輪能表示的時(shí)間段16s。當(dāng)前任務(wù)指向格子2,表明在第2s的時(shí)候有任務(wù)需要執(zhí)行。任務(wù)列表中有兩個(gè)任務(wù),每個(gè)任務(wù)前面的數(shù)字表示圈數(shù)。2表示當(dāng)走到第2圈的時(shí)候才會(huì)執(zhí)行,那么整個(gè)任務(wù)的真正執(zhí)行時(shí)間其實(shí)是在12s之后執(zhí)行,即第二圈走到2的時(shí)候。每推進(jìn)一格,對(duì)應(yīng)的每一個(gè) slot 中的round數(shù)都要減一。整體算法就是這么個(gè)邏輯。
時(shí)間輪設(shè)計(jì)要點(diǎn):
- tick,一次時(shí)間推進(jìn),每次推進(jìn)會(huì)檢查/執(zhí)行超時(shí)任務(wù);
- tickDuration,時(shí)間輪推進(jìn)的最小單元,每隔 tickDuration 會(huì)有一次 tick,它決定了時(shí)間輪的精確程度;
- bucket(ticksPerWheel),上圖中的每一隔就是一個(gè)bucket,表示一個(gè)時(shí)間輪可以有多少個(gè)tick,它是存儲(chǔ)任務(wù)的最小單元;
- 上層時(shí)間輪的 tickDuration 是下層時(shí)間輪的表示時(shí)間的最大范圍,即:父 tickDuration = 子 tickDuration * 子 bucket 。
需要注意的是,這種方式任務(wù)是串行執(zhí)行的。意味著你如果在時(shí)間輪中執(zhí)行任務(wù)且任務(wù)耗時(shí)較長(zhǎng),將會(huì)出現(xiàn)調(diào)度超時(shí)或者任務(wù)堆積的情況。所以要將任務(wù)的執(zhí)行異步化。
算法的要點(diǎn):
- 任務(wù)并不是直接放在格子中的,而是維護(hù)了一個(gè)雙向鏈表,這種數(shù)據(jù)結(jié)構(gòu)非常便于插入和移除;
- 新添加的任務(wù)并不直接放入格子,而是先放入一個(gè)隊(duì)列中,這是為了避免多線程插入任務(wù)的沖突。在每個(gè)tick運(yùn)行任務(wù)之前由worker線程自動(dòng)對(duì)任務(wù)進(jìn)行歸集和分類,插入到對(duì)應(yīng)的槽位里面。
Netty 使用數(shù)組 + 雙向鏈表的方式來(lái)組織時(shí)間輪,對(duì)于添加/取消操作僅做了記錄,真正的操作實(shí)際發(fā)生在下一個(gè)tick。時(shí)間的推進(jìn)是獨(dú)立的線程在做,該線程同時(shí)也負(fù)責(zé)過(guò)期任務(wù)的執(zhí)行等操作,可簡(jiǎn)單認(rèn)為此步驟操作為O(n),因?yàn)橥七M(jìn)線程需要完全遍歷timeouts、cancelledTimeouts與bucket鏈表,在遍歷timeouts時(shí),Netty為了避免任務(wù)過(guò)多,所以限制每次最多遍歷10萬(wàn)個(gè),也就是說(shuō),一個(gè)tick只能規(guī)劃10萬(wàn)個(gè)任務(wù),當(dāng)任務(wù)量過(guò)大時(shí),會(huì)存在超時(shí)任務(wù)執(zhí)行時(shí)間延遲的現(xiàn)象。
方案優(yōu)劣:
優(yōu)點(diǎn):
實(shí)現(xiàn)比較優(yōu)雅。效率高。
缺點(diǎn):
無(wú)法實(shí)現(xiàn)HA和橫向擴(kuò)展,要么就使用多個(gè)時(shí)間輪。
最重要的是,實(shí)現(xiàn)也比較復(fù)雜,開(kāi)發(fā)者需要考慮所有可能的情況。
目前我了解到的延遲隊(duì)列在生產(chǎn)環(huán)境下有如上三種實(shí)現(xiàn)方式,每一種都有人在使用。當(dāng)然沒(méi)有最好的只有最適合的,你覺(jué)得 redis 能滿足需求,就按照最簡(jiǎn)單的來(lái),你要是有充足的開(kāi)發(fā)周期,你也可以實(shí)現(xiàn)時(shí)間輪展現(xiàn)實(shí)力。
需求千萬(wàn)種,變化就一種:給時(shí)間都能做。
以上就是JAVA 實(shí)現(xiàn)延遲隊(duì)列的方法的詳細(xì)內(nèi)容,更多關(guān)于JAVA 實(shí)現(xiàn)延遲隊(duì)列的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
SpringBoot整合Elasticsearch實(shí)現(xiàn)索引和文檔的操作方法
Elasticsearch 基于 Apache Lucene 構(gòu)建,采用 Java 編寫,并使用 Lucene 構(gòu)建索引、提供搜索功能,本文分步驟通過(guò)綜合案例給大家分享SpringBoot整合Elasticsearch的相關(guān)知識(shí),感興趣的朋友跟隨小編一起看看吧2021-05-05微服務(wù)中使用Maven BOM來(lái)管理你的版本依賴詳解
這篇文章主要介紹了微服務(wù)中使用Maven BOM來(lái)管理你的版本依賴,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-12-12Spring自動(dòng)裝配bean的方式總結(jié)
這篇主要介紹了Spring自動(dòng)裝配Bean的方式總結(jié),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2024-01-01如何將默認(rèn)的maven倉(cāng)庫(kù)改為阿里的maven倉(cāng)庫(kù)
這篇文章主要介紹了如何將默認(rèn)的maven倉(cāng)庫(kù)改為阿里的maven倉(cāng)庫(kù),本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-12-12SpringBoot使用@Validated處理校驗(yàn)的方法步驟
@Validated?注解的主要目的是啟用和利用?Spring?的驗(yàn)證框架,它可以用于類上也可以用于方法參數(shù)上,本文給大家介紹了SpringBoot使用@Validated優(yōu)雅的處理校驗(yàn)的方法步驟,通過(guò)代碼示例介紹的非常詳細(xì),需要的朋友可以參考下2024-08-08Hibernate實(shí)現(xiàn)批量添加數(shù)據(jù)的方法
這篇文章主要介紹了Hibernate實(shí)現(xiàn)批量添加數(shù)據(jù)的方法,詳細(xì)分析了基于Hibernate執(zhí)行批量添加操作的具體步驟與相關(guān)實(shí)現(xiàn)代碼,需要的朋友可以參考下2016-03-03Spring中@ConditionalOnProperty注解的作用詳解
這篇文章主要介紹了Spring中@ConditionalOnProperty注解的作用詳解,@ConditionalOnProperty注解主要是用來(lái)判斷配置文件中的內(nèi)容來(lái)決定配置類是否生效用的,如果條件不匹配,則配置類不生效,需要的朋友可以參考下2024-01-01