基于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),但是不斷代碼不斷的輪詢,勢必會(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í)間可以無限期延長 (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)中。這里很簡單,就是調(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);
}
});
}
測試代碼
@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)文章
Redis 使用跳表實(shí)現(xiàn)有序集合的方法
Redis有序集合底層為什么使用跳表而非其他數(shù)據(jù)結(jié)構(gòu)如平衡樹、紅黑樹或B+樹的原因在于其特殊的設(shè)計(jì)和應(yīng)用場景,跳表提供了與平衡樹類似的效率,同時(shí)實(shí)現(xiàn)更簡單,調(diào)試和修改也更加容易,感興趣的朋友一起看看吧2024-09-09
一文搞懂阿里云服務(wù)器部署Redis并整合Spring?Boot
這篇文章主要介紹了一文搞懂阿里云服務(wù)器部署Redis并整合Spring?Boot,文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-09-09
Redis優(yōu)化token校驗(yàn)主動(dòng)失效的實(shí)現(xiàn)方案
在普通的token頒發(fā)和校驗(yàn)中 當(dāng)用戶發(fā)現(xiàn)自己賬號(hào)和密碼被暴露了時(shí)修改了登錄密碼后舊的token仍然可以通過系統(tǒng)校驗(yàn)直至token到達(dá)失效時(shí)間,所以系統(tǒng)需要token主動(dòng)失效的一種能力,所以本文給大家介紹了Redis優(yōu)化token校驗(yàn)主動(dòng)失效的實(shí)現(xiàn)方案,需要的朋友可以參考下2024-03-03
Redis Cluster Pipeline導(dǎo)致的死鎖問題解決
本文主要介紹了Redis Cluster Pipeline導(dǎo)致的死鎖問題解決,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-10-10
Redis的Zset類型及相關(guān)命令詳細(xì)講解
這篇文章主要介紹了Redis的Zset類型及相關(guān)命令的相關(guān)資料,有序集合Zset是一種Redis數(shù)據(jù)結(jié)構(gòu),它類似于集合Set,但每個(gè)元素都有一個(gè)關(guān)聯(lián)的分?jǐn)?shù)score,并且可以根據(jù)分?jǐn)?shù)對(duì)元素進(jìn)行排序,需要的朋友可以參考下2025-01-01
Redis快速實(shí)現(xiàn)分布式session的方法詳解
Session是客戶端與服務(wù)器通訊會(huì)話跟蹤技術(shù),服務(wù)器與客戶端保持整個(gè)通訊的會(huì)話基本信息。本文主要介紹了Redis快速實(shí)現(xiàn)分布式session的方法,感興趣的可以學(xué)習(xí)一下2022-01-01
Redis中主鍵失效的原理及實(shí)現(xiàn)機(jī)制剖析
這篇文章主要介紹了Redis中主鍵失效的原理及實(shí)現(xiàn)機(jī)制剖析,本文講解了失效時(shí)間的控制、失效的內(nèi)部實(shí)現(xiàn)、Memcached 刪除失效主鍵的方法與 Redis 有何異同、Redis 的主鍵失效機(jī)制會(huì)不會(huì)影響系統(tǒng)性能等內(nèi)容,需要的朋友可以參考下2015-06-06

