基于Redis實(shí)現(xiàn)阻塞隊(duì)列的方式
日常需求開發(fā)過程中,不免會(huì)遇到需要通過代碼進(jìn)行異步處理的情況,比如批量發(fā)送郵件,批量發(fā)送短信,數(shù)據(jù)導(dǎo)入,為了減少用戶的等待,不希望一直菊花轉(zhuǎn)啊轉(zhuǎn),因此需要進(jìn)行異步處理,做法就是講要處理的數(shù)據(jù)添加到隊(duì)列當(dāng)中,然后按照排隊(duì)的先后順序進(jìn)行異步處理。
這個(gè)隊(duì)列,可以是專業(yè)的消息隊(duì)列,如 RocketMQ/RabbitMQ 等,一般項(xiàng)目中,如果只是為了進(jìn)行異步,未免有點(diǎn)殺雞用牛刀的意味。
也可以使用基于 JVM 內(nèi)存實(shí)現(xiàn)隊(duì)列,但是如果項(xiàng)目進(jìn)行了重啟,就會(huì)造成隊(duì)列數(shù)據(jù)丟失。
大部分的項(xiàng)目都會(huì)用到 Redis 中間件作為緩存使用,此時(shí)使用 Redis 的 list 結(jié)構(gòu)來實(shí)現(xiàn)隊(duì)列則是非常合適的選擇。
因此,本文主要講解基于 Redis 的方式實(shí)現(xiàn)異步隊(duì)列。
本文首發(fā)個(gè)人技術(shù)博客: https://nullpointer.pw/redis-block-queue.html
基于 Redis 的 list 實(shí)現(xiàn)隊(duì)列的方式也有多種,先說第一種不推薦的方式,即使用LPUSH
生產(chǎn)消息,然后 while(true) 中通過RPOP
消費(fèi)消息,這種方式的確可以實(shí)現(xiàn),但是不斷代碼不斷的輪詢,勢(shì)必會(huì)消耗一些系統(tǒng)的資源。
第二種方式也是不推薦的方式,也是通過 LPUSH
生產(chǎn)消息,然后通過 BRPOP
進(jìn)行阻塞地等待并消費(fèi)消息,這種方式較第一種方式減少了無用的輪詢,降低系統(tǒng)資源的消耗,但是可能會(huì)存在隊(duì)列消息丟失的情況,如果取出了消息然后處理失敗,這個(gè)被取出的消息就將丟失。
第二種方式就是下文要介紹的方式,首先也是通過 LPUSH
生產(chǎn)消息,然后通過 BRPOPLPUSH
阻塞地等待 list 新消息到來,有了新消息才開始消費(fèi),同時(shí)將消息備份到另外一個(gè) list 當(dāng)中,這種方式具備了第二種方式的優(yōu)點(diǎn),即減少了無用的輪詢,同時(shí)也對(duì)消息進(jìn)行了備份不會(huì)丟失數(shù)據(jù),如果處理成功,可以通過 LREM
對(duì)備份的 list 中當(dāng)前的這條消息進(jìn)行刪除處理。這種方式實(shí)現(xiàn)方式可以參考 模式: 安全的隊(duì)列 .
Redis 基礎(chǔ)
# 將一個(gè)或多個(gè)值 value 插入到列表 key 的表頭 LPUSH key value [value …] # 阻塞式等待,將列表 source 中的最后一個(gè)元素 (尾元素) 彈出,并返回給客戶端。將 source 彈出的元素插入到列表 destination ,作為 destination 列表的的頭元素。超時(shí)參數(shù) timeout 接受一個(gè)以秒為單位的數(shù)字作為值。超時(shí)參數(shù)設(shè)為 0 表示阻塞時(shí)間可以無限期延長(zhǎng) (block indefinitely) 。 BRPOPLPUSH source destination timeout # 根據(jù)參數(shù) count 的值,移除列表中與參數(shù) value 相等的元素。 LREM key count value
代碼實(shí)現(xiàn)隊(duì)列消息生產(chǎn)者
筆者使用的是 Spring 相關(guān) API 實(shí)現(xiàn)對(duì) Redis 指令的調(diào)用。首先實(shí)現(xiàn)消息的生產(chǎn)代碼,封裝到一個(gè)工具類方法當(dāng)中。這里很簡(jiǎn)單,就是調(diào)用了 lpush 方法,將序列化的 key 和 value 添加到列表當(dāng)中去。
@Resource private RedisConnectionFactory connectionFactory; public void lPush(@Nonnull String key, @Nonnull String value) { RedisConnection connection = RedisConnectionUtils.getConnection(connectionFactory); try { byte[] byteKey = RedisSerializer.string().serialize(getKey(key)); byte[] byteValue = RedisSerializer.string().serialize(value); assert byteKey != null; connection.lPush(byteKey, byteValue); } finally { RedisConnectionUtils.releaseConnection(connection, connectionFactory); } }
代碼實(shí)現(xiàn)隊(duì)列消息消費(fèi)者
因?yàn)閷?shí)現(xiàn)隊(duì)列消費(fèi)消息的代碼比較多,不可能每個(gè)需要阻塞消費(fèi)的地方,對(duì)需要寫這一坨代碼,因此使用 Java8 的函數(shù)式接口實(shí)現(xiàn)方法的傳遞,同時(shí)阻塞式獲取消息代碼使用新線程去執(zhí)行。
有人看到以下代碼要吐槽了,不是說不用 while(true) 嗎,怎么你這里面還是有,這里稍微解釋一下,因?yàn)?SpringBoot 一般會(huì)指定 timeout 的全局超時(shí)時(shí)間,即使 BRPOPLPUSH
設(shè)置了 0,即無限期,當(dāng)超出了 timeout 設(shè)置的值時(shí),就會(huì)拋出 QueryTimeoutException 異常導(dǎo)致線程退出,因此添加了 try/catch 對(duì)異常進(jìn)行捕獲并忽略,同時(shí)使用 while(true) 保證線程可以繼續(xù)執(zhí)行。
代碼中記錄了當(dāng)前消息處理結(jié)果,如果處理結(jié)果為成功,需要對(duì)備份隊(duì)列的當(dāng)前消息進(jìn)行刪除。
public void bRPopLPush(@Nonnull String key, Consumer<String> consumer) { CompletableFuture.runAsync(() -> { RedisConnection connection = RedisConnectionUtils.getConnection(connectionFactory); try { byte[] srcKey = RedisSerializer.string().serialize(getKey(key)); byte[] dstKey = RedisSerializer.string().serialize(getBackupKey(key)); assert srcKey != null; assert dstKey != null; while (true) { byte[] byteValue = new byte[0]; boolean success = false; try { byteValue = connection.bRPopLPush(0, srcKey, dstKey); if (byteValue != null && byteValue.length != 0) { consumer.accept(new String(byteValue)); success = true; } } catch (Exception ignored) { // 防止獲取 key 達(dá)到超時(shí)時(shí)間拋出 QueryTimeoutException 異常退出 } finally { if (success) { // 處理成功才刪除備份隊(duì)列的 key connection.lRem(dstKey, 1, byteValue); } } } } finally { RedisConnectionUtils.releaseConnection(connection, connectionFactory); } }); }
測(cè)試代碼
@Test public void testLPush() throws InterruptedException { String queueA = "queueA"; int i = 0; while (true) { String msg = "Hello-" + i++; redisBlockQueue.lPush(queueA, msg); System.out.println("lPush: " + msg); Thread.sleep(3000); } } @Test public void testBRPopLPush() { String queueA = "queueA"; redisBlockQueue.bRPopLPush(queueA, (val) -> { // 在這里處理具體的業(yè)務(wù)邏輯 System.out.println("val: " + val); }); // 防止 Junit 進(jìn)程退出 LockSupport.park(); }
項(xiàng)目使用方式
為了方便使用,我將其抽取為了一個(gè)工具類,使用時(shí)通過 Spring 注入使用即可,
隊(duì)列消費(fèi)可以使用如下方式在項(xiàng)目啟動(dòng)的時(shí)候就進(jìn)行阻塞監(jiān)聽隊(duì)列,等待消費(fèi)
@Resource private RedisBlockQueue redisBlockQueue; @PostConstruct public void init() { redisBlockQueue.bRPopLPush(xx, (value) -> { //... }); }
本文完整代碼下載github 地址
到此這篇關(guān)于基于Redis實(shí)現(xiàn)阻塞隊(duì)列的文章就介紹到這了,更多相關(guān)Redis阻塞隊(duì)列內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
redis5.0以上基于密碼認(rèn)證的集群cluster方式
這篇文章主要介紹了redis5.0以上基于密碼認(rèn)證的集群cluster方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-11-11解析Redis未授權(quán)訪問漏洞復(fù)現(xiàn)與利用危害
這篇文章主要介紹了Redis未授權(quán)訪問漏洞復(fù)現(xiàn)與利用,介紹了redis未授權(quán)訪問漏洞的基本概念及漏洞的危害,本文給大家介紹的非常詳細(xì),需要的朋友可以參考下2022-01-01redis 替代php文件存儲(chǔ)session的實(shí)例
這篇文章主要介紹了redis 替代php文件存儲(chǔ)session的實(shí)例的相關(guān)資料,希望通過本文能幫助到大家,讓大家掌握這樣的方法,需要的朋友可以參考下2017-10-10