前言

Redis 的 list 數(shù)據(jù)結(jié)構(gòu)常用來做消息隊列，通常使用的命令有 lpop/rpop ，還有帶阻塞版的 blpop/brpop 等。Laravel 5.3 消息隊列也是用的 lpop 取消息，為什么不用阻塞版的 blpop 呢？

blpop 不用一直輪詢，還可以同時取多個隊列，blpop high low 30，更方便實現(xiàn)隊列的優(yōu)先級。

安全隊列和不安全隊列

什么是不安全的隊列？比如客戶端 lpop（統(tǒng)一以 lpop 為例） 從 redis 取出來的 job（任務(wù)）還沒處理完進(jìn)程掛掉了或者遇到了異常，由于此時服務(wù)器上已經(jīng)沒有副本了，這個 job 就丟失了。這種隊列就是不安全的。

Laravel 正是為了保證消息隊列的可靠，進(jìn)程掛掉了或者處理失敗還可以重試等，做了比較完善的機(jī)制，如取隊列的同時把隊列放入另一個集合中“暫存”起來。如代碼所示，使用 lpop 取出隊列，同時 zadd 到另一個集合，使用 redis lua 來保證原子性。

public static function pop()
{
 return <<<'LUA'
-- Pop the first job off of the queue...
local job = redis.call('lpop', KEYS[1])
local reserved = false
 
if(job ~= false) then
-- Increment the attempt count and place job on the reserved queue...
reserved = cjson.decode(job)
reserved['attempts'] = reserved['attempts'] + 1
reserved = cjson.encode(reserved)
redis.call('zadd', KEYS[2], ARGV[1], reserved)
end
 
return {job, reserved}
LUA;
}

具體 Laravel 隊列工作原理之前有一篇博文進(jìn)行了整理，請參考：http://m.fzitv.net/article/131414.htm

為什么不用 blpop？

這里為什么不使用阻塞版本的 blpop 呢？

blpop 是阻塞版的 lpop，如果隊列沒有數(shù)據(jù)過來，那么在超時時間內(nèi)就會一直阻塞，直到 rpush 數(shù)據(jù)到隊列，有點類似 http 的長輪詢，假如客戶端取出數(shù)據(jù)的這一刻掛了，還沒來得及暫存到另外的集合中，那么這個數(shù)據(jù)就丟失了。

你可能會問為何不跟 lpop 一樣用 lua 腳本來處理并保證原子性？這個問題作者在 github 上有回答。（https://github.com/laravel/framework/issues/22939）

我們知道 redis lua 腳本實際上就是事務(wù)，作者的大意也是說 MULTI/EXEC 包裹起來的 blpop 沒有意義，這個時候它“退化”為非阻塞版的。

Redis 官方文檔也有說明：

在MULTI/EXEC事務(wù)中的BLPOP

BLPOP 可以用于流水線(pipline,批量地發(fā)送多個命令并讀入多個回復(fù))，但把它用在 MULTI / EXEC 塊當(dāng)中沒有意義。因為這要求整個服務(wù)器被阻塞以保證塊執(zhí)行時的原子性，該行為阻止了其他客戶端執(zhí)行 LPUSH 或 RPUSH 命令。

因此，一個被包裹在 MULTI / EXEC 塊內(nèi)的 BLPOP 命令，行為表現(xiàn)得就像 LPOP 一樣，對空列表返回 nil ，對非空列表彈出列表元素，不進(jìn)行任何阻塞操作。

因此通過 lua 腳本操作 blpop 和 zadd 也沒有意義，結(jié)論就是：因為沒用到阻塞的特性，或者無法保證原子性。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論