戰(zhàn)：從單線程模型到分布式鎖應(yīng)用)
1. 項(xiàng)目概述為什么我們需要關(guān)注Redis Lua腳本的原子性如果你用過Redis大概率聽過或者用過EVAL命令。你可能知道它能執(zhí)行Lua腳本也模模糊糊地聽說它能“保證原子性”但具體怎么回事為什么能保證以及到底該在什么場(chǎng)景下用它心里可能沒個(gè)準(zhǔn)數(shù)。今天我們就來把這塊硬骨頭啃透。簡(jiǎn)單來說Redis Lua腳本的原子性指的是一個(gè)腳本在執(zhí)行過程中不會(huì)被其他客戶端的命令插入或打斷。這聽起來有點(diǎn)像數(shù)據(jù)庫(kù)里的事務(wù)但實(shí)現(xiàn)機(jī)制和保證級(jí)別完全不同。理解這一點(diǎn)是避免在分布式環(huán)境下踩坑的關(guān)鍵。比如你寫了一個(gè)腳本用來扣減庫(kù)存如果這個(gè)操作不是原子的在高并發(fā)下就可能出現(xiàn)超賣。而Lua腳本正是Redis提供給你解決這類問題的“瑞士軍刀”。這篇文章適合所有正在或即將使用Redis的開發(fā)者無論你是剛?cè)腴T還是已經(jīng)用它做過緩存現(xiàn)在想深入其更高級(jí)的特性。我會(huì)從原理講起掰開揉碎了說清楚“原子性”是怎么來的然后結(jié)合我這些年趟過的坑分享幾個(gè)最實(shí)用、最高頻的使用場(chǎng)景和避坑指南。保證你看完不僅能搞懂還能立刻用起來。2. 核心原理深度拆解Lua腳本的原子性從何而來要理解Lua腳本的原子性我們不能停留在“Redis說它是原子它就是原子”的層面必須深入到Redis的單線程模型和命令執(zhí)行機(jī)制中去。2.1 Redis的單線程事件循環(huán)原子性的基石很多人知道Redis是單線程的但單線程到底意味著什么它指的是Redis核心的網(wǎng)絡(luò)I/O和鍵值數(shù)據(jù)讀寫操作是由一個(gè)主線程串行處理的。Redis基于Reactor模式使用I/O多路復(fù)用來處理海量的客戶端連接但當(dāng)涉及到執(zhí)行命令、操作內(nèi)存數(shù)據(jù)時(shí)所有命令都會(huì)進(jìn)入一個(gè)隊(duì)列由這個(gè)單線程依次取出、執(zhí)行、返回結(jié)果。這就帶來了一個(gè)最直接的推論在任意時(shí)刻Redis服務(wù)器最多只執(zhí)行一個(gè)命令。當(dāng)一個(gè)命令正在處理時(shí)其他所有命令都必須等待。Lua腳本在Redis中被視為一個(gè)“命令”。當(dāng)你發(fā)送EVAL “return redis.call(‘GET’ KEYS[1])” 1 mykey時(shí)對(duì)于Redis的事件循環(huán)來說這和發(fā)送一個(gè)簡(jiǎn)單的GET mykey命令沒有本質(zhì)區(qū)別——都是一個(gè)待處理的任務(wù)項(xiàng)。因此Lua腳本執(zhí)行的原子性首先繼承自Redis單線程命令處理的原子性。一個(gè)腳本一旦開始執(zhí)行在其執(zhí)行完畢并返回結(jié)果之前Redis不會(huì)去處理任何其他客戶端的任何命令。這就從根本上杜絕了線程間資源競(jìng)爭(zhēng)的問題這是與多線程數(shù)據(jù)庫(kù)如MySQL實(shí)現(xiàn)事務(wù)隔離級(jí)別完全不同的底層邏輯。2.2 Lua腳本的執(zhí)行引擎嵌入與隔離Redis內(nèi)嵌了Lua解釋器。當(dāng)你調(diào)用EVAL時(shí)發(fā)生的事情可以分解為以下幾個(gè)步驟接收與解析Redis服務(wù)器接收到EVAL命令和完整的Lua腳本字符串。編譯與加載Redis的Lua引擎會(huì)編譯如果未緩存并加載這段腳本。腳本中通過redis.call()或redis.pcall()函數(shù)來調(diào)用Redis命令。執(zhí)行Lua解釋器開始逐行執(zhí)行腳本中的邏輯。每當(dāng)遇到redis.call()時(shí)它會(huì)向Redis的核心命令執(zhí)行器發(fā)起一個(gè)“內(nèi)部調(diào)用”。原子性保證的關(guān)鍵這些“內(nèi)部調(diào)用”雖然也是Redis命令但它們并非來自網(wǎng)絡(luò)客戶端而是來自當(dāng)前正在執(zhí)行的Lua腳本上下文。Redis的單線程執(zhí)行器會(huì)處理這些內(nèi)部調(diào)用但由于執(zhí)行器本身正被這個(gè)腳本“獨(dú)占”所以這些內(nèi)部調(diào)用同樣不會(huì)被其他客戶端命令打斷。腳本中的所有Redis操作可能是幾十個(gè)GET、SET、INCR在效果上被捆綁成了一個(gè)不可分割的整體。這里有一個(gè)非常重要的點(diǎn)Lua腳本的原子性是“執(zhí)行過程”的原子性而非“失敗回滾”的原子性。如果腳本在執(zhí)行到一半時(shí)因?yàn)榇abug比如對(duì)nil值做算術(shù)運(yùn)算而拋出異常腳本會(huì)停止執(zhí)行但之前已經(jīng)執(zhí)行成功的Redis命令不會(huì)被回滾。這一點(diǎn)和傳統(tǒng)數(shù)據(jù)庫(kù)的ACID事務(wù)有本質(zhì)區(qū)別。Redis沒有Undo Log。注意務(wù)必區(qū)分“原子性”和“事務(wù)性”。Redis Lua腳本提供的是原子執(zhí)行Atomic Execution而非原子提交Atomic Commit。它保證了操作組合不被干擾但不保證所有操作要么全做要么全不做。你需要通過腳本內(nèi)的邏輯判斷來實(shí)現(xiàn)類似“回滾”的效果。2.3 與Redis事務(wù)MULTI/EXEC的對(duì)比很多人會(huì)把Lua腳本和Redis的MULTI/EXEC事務(wù)命令搞混。它們確實(shí)有相似的目標(biāo)但實(shí)現(xiàn)和保證級(jí)別不同。特性Redis Lua 腳本Redis MULTI/EXEC 事務(wù)原子性保證強(qiáng)原子性。腳本執(zhí)行期間無其他命令干擾。弱原子性。僅在EXEC執(zhí)行時(shí)保證命令隊(duì)列連續(xù)執(zhí)行但其他客戶端命令可能在MULTI后、EXEC前執(zhí)行。隔離性完全隔離。腳本看到的是執(zhí)行開始時(shí)的一致性數(shù)據(jù)快照因?yàn)闊o干擾。可能遇到競(jìng)態(tài)條件。在WATCH機(jī)制下可實(shí)現(xiàn)CASCheck-And-Set但更復(fù)雜。回滾能力無。執(zhí)行失敗的命令不會(huì)回滾。無。即使某個(gè)命令失敗隊(duì)列后面的命令仍會(huì)執(zhí)行。復(fù)雜性高。需要編寫Lua代碼調(diào)試相對(duì)復(fù)雜。低。只是將命令排隊(duì)語(yǔ)法簡(jiǎn)單。應(yīng)用場(chǎng)景復(fù)雜的多步邏輯需要強(qiáng)一致性保證如庫(kù)存扣減、狀態(tài)轉(zhuǎn)換。簡(jiǎn)單的命令批量執(zhí)行對(duì)原子性要求不極致或配合WATCH實(shí)現(xiàn)樂觀鎖。核心區(qū)別在于在MULTI和EXEC之間Redis只是將命令排隊(duì)并沒有阻止其他客戶端執(zhí)行命令。因此事務(wù)隊(duì)列中的命令在執(zhí)行時(shí)操作的數(shù)據(jù)可能已經(jīng)被其他客戶端修改。而Lua腳本在執(zhí)行全過程中數(shù)據(jù)視圖是凍結(jié)的。實(shí)操心得對(duì)于需要“讀取-計(jì)算-寫入”模式的復(fù)雜操作無腦選擇Lua腳本。使用MULTI/EXEC事務(wù)你很可能需要配合WATCH來實(shí)現(xiàn)樂觀鎖代碼會(huì)變得冗長(zhǎng)且容易出錯(cuò)。而Lua腳本一個(gè)命令搞定既簡(jiǎn)潔又可靠。3. Lua腳本的“魔鬼細(xì)節(jié)”與避坑指南理解了基本原理我們來看看實(shí)際使用中那些容易踩坑的細(xì)節(jié)。這些往往是官方文檔不會(huì)著重強(qiáng)調(diào)但卻是保障線上穩(wěn)定性的關(guān)鍵。3.1 腳本的緩存與SHA1性能與管理的平衡每次發(fā)送一個(gè)很長(zhǎng)的Lua腳本字符串網(wǎng)絡(luò)開銷和Redis的解析開銷都很大。因此Redis提供了SCRIPT LOAD和EVALSHA命令。SCRIPT LOAD script將腳本加載到Redis服務(wù)器內(nèi)存返回一個(gè)該腳本的SHA1校驗(yàn)和。EVALSHA sha1 numkeys key [key …] arg [arg …]通過SHA1值來執(zhí)行已加載的腳本。最佳實(shí)踐是在應(yīng)用啟動(dòng)時(shí)加載所有需要的Lua腳本獲取其SHA1值并緩存到本地如本地變量或配置中心。后續(xù)執(zhí)行一律使用EVALSHA。這能極大減少網(wǎng)絡(luò)傳輸量。但是這里有個(gè)大坑腳本緩存不是永久的。Redis的腳本緩存是易失的重啟、執(zhí)行SCRIPT FLUSH命令或者當(dāng)服務(wù)器內(nèi)存不足觸發(fā)某些機(jī)制時(shí)緩存都可能被清除。如果你用EVALSHA去執(zhí)行一個(gè)已經(jīng)不存在的腳本Redis會(huì)返回一個(gè)NOSCRIPT錯(cuò)誤。避坑策略實(shí)現(xiàn)一個(gè)安全的執(zhí)行封裝不要直接調(diào)用EVALSHA。寫一個(gè)包裝函數(shù)先嘗試EVALSHA如果捕獲到NOSCRIPT錯(cuò)誤則回退到使用EVAL重新發(fā)送腳本并執(zhí)行同時(shí)可以重新緩存SHA1值。-- 偽代碼示例 function safe_evalsha(client, sha1, keys, args) local result client.evalsha(sha1, #keys, unpack(keys, args)) if result.error and result.error:contains(‘NOSCRIPT’) then -- 重新加載腳本這里需要你有原始的script字符串 client.script(‘load’ original_script) -- 重試 result client.evalsha(sha1, #keys, unpack(keys, args)) end return result end將腳本作為應(yīng)用配置管理將Lua腳本內(nèi)容像SQL語(yǔ)句一樣存儲(chǔ)在版本控制系統(tǒng)中。應(yīng)用啟動(dòng)時(shí)從固定位置讀取并加載。這樣也方便腳本的版本管理和審計(jì)。3.2 腳本的“純函數(shù)”與隨機(jī)性一個(gè)影響復(fù)現(xiàn)性的陷阱Redis要求在默認(rèn)配置下Lua腳本必須是純函數(shù)的即對(duì)于相同的輸入KEYS和ARGV腳本執(zhí)行的Redis命令序列必須完全相同。這是因?yàn)镽edis需要根據(jù)腳本內(nèi)容計(jì)算SHA1值用于緩存和復(fù)制。如果你在腳本中使用了隨機(jī)數(shù)math.random或系統(tǒng)時(shí)間os.time就會(huì)違反這個(gè)原則。這會(huì)導(dǎo)致兩個(gè)嚴(yán)重問題主從數(shù)據(jù)不一致在主節(jié)點(diǎn)上執(zhí)行成功的腳本其SHA1值會(huì)被同步給從節(jié)點(diǎn)。但由于隨機(jī)性腳本在從節(jié)點(diǎn)重放時(shí)執(zhí)行的命令序列可能不同導(dǎo)致最終數(shù)據(jù)不一致。AOF持久化問題如果開啟了AOF腳本是以EVALSHA形式記錄的。重啟后通過AOF恢復(fù)時(shí)如果腳本因?yàn)殡S機(jī)性而行為不同數(shù)據(jù)就亂了。解決方案將隨機(jī)性因素作為參數(shù)傳入所有需要隨機(jī)數(shù)或時(shí)間戳的地方都在客戶端生成好通過ARGV參數(shù)傳遞給腳本。確保腳本邏輯只由輸入?yún)?shù)決定。-- 錯(cuò)誤示范 local randomValue math.random(1 100) redis.call(‘SET’ ‘random_key’ randomValue) -- 正確示范 local randomValue tonumber(ARGV[1]) -- 由客戶端生成并傳入 redis.call(‘SET’ ‘random_key’ randomValue)使用redis.replicate_commands()Redis 3.2在腳本第一行調(diào)用此函數(shù)Redis會(huì)改為記錄腳本實(shí)際產(chǎn)生的寫命令到AOF和復(fù)制鏈路而不是記錄EVALSHA。這放寬了“純函數(shù)”的要求允許腳本內(nèi)包含隨機(jī)邏輯但會(huì)稍微增加AOF日志體積。除非必要否則不建議優(yōu)先使用。3.3 腳本的調(diào)試與日志如何洞察黑盒內(nèi)部調(diào)試Lua腳本是痛苦的因?yàn)樗谝粋€(gè)遠(yuǎn)程的Redis服務(wù)器內(nèi)部執(zhí)行。你無法像本地代碼一樣設(shè)置斷點(diǎn)。這里有幾個(gè)實(shí)用的調(diào)試技巧使用redis.log函數(shù)輸出日志Redis Lua引擎提供了redis.log(loglevel message)函數(shù)。你可以將中間變量或執(zhí)行路徑信息打印到Redis的日志文件中默認(rèn)是stdout或配置的日志文件。redis.log(redis.LOG_NOTICE “Key count: ” .. #KEYS) redis.log(redis.LOG_NOTICE “First arg: ” .. tostring(ARGV[1]))注意日志級(jí)別redis.LOG_DEBUG在默認(rèn)配置下可能不會(huì)輸出建議使用redis.LOG_NOTICE或redis.LOG_WARNING。生產(chǎn)環(huán)境要慎用避免日志洪水。在測(cè)試環(huán)境使用redis-cli --eval這是最直接的測(cè)試方式。你可以將腳本寫在一個(gè).lua文件里然后用redis-cli執(zhí)行并觀察返回值和數(shù)據(jù)變化。redis-cli --eval /path/to/myscript.lua key1 key2 arg1 arg2分步模擬與單元測(cè)試對(duì)于復(fù)雜腳本在本地用Lua環(huán)境模擬Redis調(diào)用是不現(xiàn)實(shí)的。更好的方法是為你的腳本編寫一個(gè)“客戶端模擬層”的單元測(cè)試。使用一個(gè)內(nèi)存中的模擬對(duì)象來替代redis.call驗(yàn)證你的業(yè)務(wù)邏輯是否正確。這能保證腳本核心邏輯的可靠性。實(shí)操心得復(fù)雜的Lua腳本在編寫時(shí)就應(yīng)該像編寫核心業(yè)務(wù)代碼一樣進(jìn)行充分的邏輯審查和邊界條件測(cè)試。將其視為你應(yīng)用代碼的一部分而不是一個(gè)可以隨意拼接的字符串。4. 五大核心使用場(chǎng)景與實(shí)戰(zhàn)代碼解析理論說再多不如看實(shí)戰(zhàn)。下面我結(jié)合五個(gè)最常見的場(chǎng)景給出具體的腳本示例和代碼解析。你可以把這些當(dāng)作模板直接修改使用。4.1 場(chǎng)景一分布式鎖的釋放解決原子性問題這是最經(jīng)典的場(chǎng)景。普通的分布式鎖實(shí)現(xiàn)是SET key uuid NX PX 30000釋放時(shí)需要用GET判斷uuid是否匹配再DEL。但GET和DEL是兩個(gè)命令不是原子的。-- KEYS[1]: 鎖的key -- ARGV[1]: 當(dāng)前客戶端持有的鎖標(biāo)識(shí)如UUID -- 返回值1表示釋放成功0表示釋放失敗鎖不屬于該客戶端或已過期 if redis.call(‘GET’ KEYS[1]) ARGV[1] then -- 只有鎖的持有者才能釋放 return redis.call(‘DEL’ KEYS[1]) else return 0 end為什么必須用Lua腳本如果不用腳本在GET之后、DEL之前鎖可能因?yàn)槌瑫r(shí)被自動(dòng)釋放然后被另一個(gè)客戶端獲取。此時(shí)再執(zhí)行DEL就會(huì)誤刪別人的鎖。腳本保證了“判斷所有權(quán)”和“刪除鎖”是一個(gè)不可分割的操作。4.2 場(chǎng)景二庫(kù)存扣減與防超賣電商秒殺、搶購(gòu)等場(chǎng)景的基石。核心是“檢查庫(kù)存”和“扣減庫(kù)存”必須原子。-- KEYS[1]: 商品庫(kù)存key例如 stock:item_1001 -- ARGV[1]: 本次需要扣減的數(shù)量 -- 返回值剩余庫(kù)存如果扣減成功或一個(gè)錯(cuò)誤值如-1表示庫(kù)存不足 local current tonumber(redis.call(‘GET’ KEYS[1])) if current nil then current 0 end local quantity tonumber(ARGV[1]) if current quantity then -- 庫(kù)存不足返回-1。也可以返回0或特定字符串由客戶端約定。 return -1 end -- 庫(kù)存充足執(zhí)行扣減 local newStock current - quantity redis.call(‘SET’ KEYS[1] newStock) return newStock進(jìn)階技巧這個(gè)腳本返回的是扣減后的庫(kù)存。在高并發(fā)下你可能更關(guān)心是否扣減成功。可以修改為成功返回1失敗返回0。更復(fù)雜的場(chǎng)景可能涉及多個(gè)商品庫(kù)存的同時(shí)扣減購(gòu)物車只需擴(kuò)展KEYS和ARGV在腳本內(nèi)循環(huán)處理即可。4.3 場(chǎng)景三限流器滑動(dòng)時(shí)間窗口實(shí)現(xiàn)一個(gè)在N秒內(nèi)最多允許M次請(qǐng)求的限流器。-- KEYS[1]: 限流器的key例如 rate_limit:user_123:api_login -- ARGV[1]: 時(shí)間窗口大小秒 -- ARGV[2]: 最大請(qǐng)求次數(shù) -- ARGV[3]: 當(dāng)前時(shí)間戳由客戶端傳入保證一致性 local window tonumber(ARGV[1]) local limit tonumber(ARGV[2]) local now tonumber(ARGV[3]) -- 移除時(shí)間窗口之前的記錄 redis.call(‘ZREMRANGEBYSCORE’ KEYS[1] 0 now - window) -- 獲取當(dāng)前窗口內(nèi)的請(qǐng)求數(shù)量 local current redis.call(‘ZCARD’ KEYS[1]) if current limit then -- 未超限添加本次請(qǐng)求記錄分?jǐn)?shù)為當(dāng)前時(shí)間戳 redis.call(‘ZADD’ KEYS[1] now now) -- 成員也用時(shí)間戳保證唯一 -- 設(shè)置key的過期時(shí)間避免冷數(shù)據(jù)長(zhǎng)期占用內(nèi)存 redis.call(‘EXPIRE’ KEYS[1] window 1) return 1 -- 允許通過 else return 0 -- 拒絕通過 end解析這里用到了Redis的Sorted SetZSET。每個(gè)請(qǐng)求的時(shí)間戳作為分?jǐn)?shù)和成員。腳本原子地完成了“清理舊數(shù)據(jù)”、“計(jì)數(shù)”、“判斷”、“添加新記錄”和“設(shè)置過期時(shí)間”這五個(gè)步驟。如果不用腳本在高并發(fā)下計(jì)數(shù)和添加操作之間可能被其他請(qǐng)求插入導(dǎo)致計(jì)數(shù)不準(zhǔn)。4.4 場(chǎng)景四簡(jiǎn)單的消息隊(duì)列確保ACK和重試一個(gè)需要確保消息被成功處理后才刪除的簡(jiǎn)單隊(duì)列。-- KEYS[1]: 待處理隊(duì)列 key (list)例如 task_queue -- KEYS[2]: 處理中隊(duì)列 key (list)例如 task_processing -- ARGV[1]: 當(dāng)前消費(fèi)者ID用于故障恢復(fù)時(shí)識(shí)別 -- ARGV[2]: 消息處理超時(shí)時(shí)間秒 -- 1. 嘗試從處理中隊(duì)列取回本消費(fèi)者超時(shí)的任務(wù)模擬ACK失敗后的重新入隊(duì) local processingTasks redis.call(‘LRANGE’ KEYS[2] 0 -1) local recovered 0 for i task in ipairs(processingTasks) do -- 這里假設(shè)任務(wù)數(shù)據(jù)中包含了消費(fèi)者ID和時(shí)間戳格式為 consumerId:timestamp:taskData -- 這是一個(gè)簡(jiǎn)化示例實(shí)際格式需自行定義 local consumerId timestamp _ string.match(task “^(%d):(%d):(.)$”) if consumerId ARGV[1] and tonumber(timestamp) tonumber(ARGV[3]) then -- ARGV[3]為當(dāng)前時(shí)間戳 redis.call(‘LREM’ KEYS[2] 1 task) redis.call(‘RPUSH’ KEYS[1] task) recovered recovered 1 end end -- 2. 從待處理隊(duì)列取出一個(gè)新任務(wù) local task redis.call(‘LPOP’ KEYS[1]) if task then -- 給任務(wù)打上消費(fèi)者ID和當(dāng)前時(shí)間戳然后放入處理中隊(duì)列 local taggedTask ARGV[1] .. “:” .. ARGV[3] .. “:” .. task redis.call(‘RPUSH’ KEYS[2] taggedTask) -- 設(shè)置處理中隊(duì)列的過期時(shí)間略可通過外部定時(shí)任務(wù)清理 return {recovered task} -- 返回恢復(fù)的任務(wù)數(shù)和取出的新任務(wù) else return {recovered nil} -- 沒有新任務(wù) end說明這是一個(gè)簡(jiǎn)化版的可ACK隊(duì)列。生產(chǎn)環(huán)境更復(fù)雜的需求如優(yōu)先級(jí)、延遲隊(duì)列建議直接使用成熟的中間件如RabbitMQ、Kafka或Redis的Stream類型。但這個(gè)腳本展示了如何用Lua原子地實(shí)現(xiàn)“狀態(tài)轉(zhuǎn)移”和“故障恢復(fù)檢查”。4.5 場(chǎng)景五聚合統(tǒng)計(jì)與更新需要先讀取多個(gè)值計(jì)算后再更新回去的場(chǎng)景。比如更新用戶排行榜分?jǐn)?shù)。-- KEYS[1]: 用戶分?jǐn)?shù)key (hash field)例如 user:1001:score -- KEYS[2]: 全局排行榜key (zset)例如 leaderboard -- ARGV[1]: 本次要增加的分?jǐn)?shù) -- ARGV[2]: 用戶ID local delta tonumber(ARGV[1]) local userId ARGV[2] -- 獲取當(dāng)前分?jǐn)?shù) local currentScore tonumber(redis.call(‘HGET’ KEYS[1] ‘score’)) or 0 -- 計(jì)算新分?jǐn)?shù) local newScore currentScore delta -- 更新Hash中的分?jǐn)?shù) redis.call(‘HSET’ KEYS[1] ‘score’ newScore) -- 更新ZSet排行榜 redis.call(‘ZADD’ KEYS[2] newScore userId) return newScore為什么需要原子性如果不用腳本先HGET客戶端計(jì)算再HSET和ZADD在并發(fā)更新同一個(gè)用戶分?jǐn)?shù)時(shí)最后的ZADD可能基于一個(gè)舊的分?jǐn)?shù)值導(dǎo)致排行榜數(shù)據(jù)錯(cuò)誤。腳本保證了“讀-計(jì)算-寫”這個(gè)鏈路的原子性。5. 性能、安全與生產(chǎn)環(huán)境最佳實(shí)踐將Lua腳本用于生產(chǎn)環(huán)境除了功能正確還必須考慮性能和安全。5.1 腳本的執(zhí)行時(shí)間與超時(shí)控制Lua腳本會(huì)阻塞Redis的單線程。一個(gè)執(zhí)行緩慢的腳本比如包含復(fù)雜循環(huán)或KEYS *這樣的操作會(huì)拖垮整個(gè)Redis實(shí)例導(dǎo)致所有其他請(qǐng)求超時(shí)。Redis默認(rèn)配置了lua-time-limit通常為5秒。如果腳本執(zhí)行超過這個(gè)時(shí)間Redis會(huì)開始記錄日志并開始接受其他客戶端的SCRIPT KILL和SHUTDOWN NOSAVE命令。最佳實(shí)踐腳本必須輕量、高效。避免在Lua腳本中進(jìn)行大量耗時(shí)的計(jì)算。Redis的優(yōu)勢(shì)是內(nèi)存操作和I/O復(fù)雜計(jì)算應(yīng)放在客戶端。避免在腳本中使用KEYS命令進(jìn)行模式匹配。這不僅慢而且在集群模式下不可用。應(yīng)該使用SCAN但注意SCAN在腳本中也可能使執(zhí)行時(shí)間變長(zhǎng)或者從根本上重新設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)和訪問模式。對(duì)腳本進(jìn)行性能測(cè)試。用redis-benchmark或模擬生產(chǎn)壓力的工具測(cè)試腳本在高并發(fā)下的執(zhí)行時(shí)間和Redis的QPS變化。設(shè)置合理的超時(shí)和重試機(jī)制。客戶端調(diào)用腳本時(shí)設(shè)置一個(gè)比lua-time-limit更短的超時(shí)時(shí)間并準(zhǔn)備好重試或降級(jí)策略。5.2 腳本的安全性防止注入與惡意代碼永遠(yuǎn)不要相信來自用戶輸入的腳本內(nèi)容。如果你允許客戶端上傳并執(zhí)行任意Lua腳本那將是一個(gè)巨大的安全漏洞。黃金法則腳本內(nèi)容應(yīng)該來自受信任的源如你的應(yīng)用程序服務(wù)器并且是固定的、經(jīng)過審查的字符串模板。客戶端只能傳遞KEYS和ARGV參數(shù)。參數(shù)化就像SQL預(yù)編譯語(yǔ)句一樣永遠(yuǎn)不要用字符串拼接的方式將用戶輸入直接拼接到腳本中。務(wù)必使用KEYS和ARGV數(shù)組來傳遞變量。-- 危險(xiǎn) local userInput ARGV[1] local script “return redis.call(‘GET’ ‘” .. userInput .. “’)” -- 如果userInput是 ’); DROP ALL KEYS; -- 就完了 -- 安全 local key KEYS[1] -- 用戶輸入作為key參數(shù)傳入 return redis.call(‘GET’ key)沙箱環(huán)境Redis的Lua環(huán)境是沙箱化的移除了很多危險(xiǎn)的標(biāo)準(zhǔn)庫(kù)函數(shù)如os.executeio.open。但即便如此也不應(yīng)放松警惕。5.3 在Redis集群模式下的使用在Redis Cluster中數(shù)據(jù)分布在不同的槽slot上。Lua腳本操作的所有key必須位于同一個(gè)節(jié)點(diǎn)上即所有key必須屬于同一個(gè)hash slot。這是由Redis Cluster的數(shù)據(jù)分片機(jī)制決定的因?yàn)槟_本需要在一個(gè)節(jié)點(diǎn)上原子執(zhí)行。如何保證對(duì)于需要操作多個(gè)key的腳本確保這些key使用相同的hash tag。Redis Cluster的hash slot計(jì)算可以通過{}來指定只對(duì)括號(hào)內(nèi)的內(nèi)容進(jìn)行hash。例如user:{1001}:profile和user:{1001}:orders它們都會(huì)被分配到user:1001這個(gè)key所在的slot因?yàn)橹挥?001被用于計(jì)算hash。如果你的腳本邏輯必須操作分布在不同節(jié)點(diǎn)的key那么Lua腳本就無法直接使用了。你需要重新設(shè)計(jì)數(shù)據(jù)模型或者考慮使用其他分布式事務(wù)方案但這超出了Redis的范疇。實(shí)操心得在微服務(wù)架構(gòu)下我通常會(huì)將需要強(qiáng)一致性的、涉及多個(gè)key的核心業(yè)務(wù)操作封裝成獨(dú)立的服務(wù)。這個(gè)服務(wù)內(nèi)部通過預(yù)加載的Lua腳本與Redis交互對(duì)外提供原子操作API。這樣既保證了數(shù)據(jù)一致性又隔離了復(fù)雜性。6. 常見問題排查與調(diào)試技巧實(shí)錄即使理解了所有原理和最佳實(shí)踐線上問題依然可能出現(xiàn)。下面是我遇到過的幾個(gè)典型問題及排查思路。6.1 錯(cuò)誤“BUSY Redis is busy running a script”現(xiàn)象客戶端收到這個(gè)錯(cuò)誤或者觀察到Redis響應(yīng)變慢甚至無響應(yīng)。原因有一個(gè)Lua腳本執(zhí)行時(shí)間過長(zhǎng)超過了lua-time-limit并且還沒有被殺死。Redis在腳本超時(shí)后會(huì)允許執(zhí)行SCRIPT KILL但如果腳本已經(jīng)執(zhí)行過寫命令SCRIPT KILL就無法終止它為了保證數(shù)據(jù)一致性此時(shí)Redis會(huì)處于這種“忙”狀態(tài)。排查與解決使用redis-cli連接服務(wù)器執(zhí)行SCRIPT KILL。如果成功服務(wù)會(huì)恢復(fù)。如果SCRIPT KILL失敗因?yàn)槟_本有寫操作那么唯一的辦法就是等待腳本自然結(jié)束或者執(zhí)行SHUTDOWN NOSAVE強(qiáng)制關(guān)閉Redis數(shù)據(jù)會(huì)丟失這是最后手段。根本解決分析是哪個(gè)腳本導(dǎo)致的。檢查Redis日志會(huì)記錄慢腳本優(yōu)化腳本邏輯避免大循環(huán)、KEYS命令等。對(duì)腳本進(jìn)行超時(shí)監(jiān)控和熔斷。6.2 錯(cuò)誤“NOSCRIPT No matching script”現(xiàn)象使用EVALSHA時(shí)頻繁報(bào)此錯(cuò)。原因腳本緩存丟失。可能是Redis重啟、內(nèi)存淘汰、或人為執(zhí)行了SCRIPT FLUSH。解決如前文所述實(shí)現(xiàn)客戶端的“安全執(zhí)行封裝”在捕獲到NOSCRIPT錯(cuò)誤時(shí)降級(jí)到使用EVAL重試并重新緩存SHA1。6.3 腳本執(zhí)行結(jié)果不符合預(yù)期現(xiàn)象腳本返回nil、false或意外的數(shù)值業(yè)務(wù)邏輯出錯(cuò)。排查步驟檢查參數(shù)傳遞確認(rèn)KEYS和ARGV的數(shù)量、順序、類型與腳本期望的一致。Lua是動(dòng)態(tài)類型tonumber()轉(zhuǎn)換失敗會(huì)得到nil后續(xù)運(yùn)算會(huì)出錯(cuò)。檢查數(shù)據(jù)類型用TYPE命令確認(rèn)你操作的key確實(shí)是你以為的類型String Hash List Set Zset。用redis.call(‘GET’ key)去讀一個(gè)Hash key會(huì)返回錯(cuò)誤。添加調(diào)試日志在測(cè)試環(huán)境在腳本關(guān)鍵分支插入redis.log語(yǔ)句輸出中間變量的值。這是最有效的調(diào)試手段。簡(jiǎn)化與隔離將復(fù)雜腳本拆分成幾個(gè)簡(jiǎn)單的腳本單獨(dú)測(cè)試或者用redis-cli --eval手動(dòng)執(zhí)行逐步驗(yàn)證每一部分邏輯。注意Nil值在Lua中nil和false在條件判斷中都為假。但Redis的redis.call()執(zhí)行失敗會(huì)返回一個(gè)包含err字段的Lua表而不是nil。使用redis.pcall()則會(huì)在錯(cuò)誤時(shí)返回一個(gè)包含err字段的表不會(huì)拋出異常這有時(shí)用于錯(cuò)誤處理。6.4 性能瓶頸排查現(xiàn)象引入Lua腳本后Redis整體QPS下降或延遲增高。排查使用SLOWLOG命令查看Redis慢查詢?nèi)罩尽?zhí)行時(shí)間過長(zhǎng)的腳本會(huì)被記錄在這里。SLOWLOG GET 10可以獲取最近10條慢日志。使用INFO commandstats命令查看所有命令的統(tǒng)計(jì)信息找到EVAL和EVALSHA的調(diào)用次數(shù)和總耗時(shí)計(jì)算平均耗時(shí)。監(jiān)控網(wǎng)絡(luò)I/O如果腳本很大且沒有使用EVALSHA網(wǎng)絡(luò)傳輸可能成為瓶頸。檢查客戶端和服務(wù)器之間的帶寬和流量。Profiling腳本在非生產(chǎn)環(huán)境可以在腳本前后使用redis.call(‘TIME’)獲取時(shí)間戳粗略計(jì)算腳本內(nèi)各部分的耗時(shí)。一個(gè)典型的性能優(yōu)化案例我們有一個(gè)腳本最初為了“通用”在內(nèi)部使用了for循環(huán)遍歷ARGV來動(dòng)態(tài)構(gòu)造多個(gè)命令。后來發(fā)現(xiàn)當(dāng)參數(shù)很多時(shí)腳本編譯和執(zhí)行效率很低。優(yōu)化方案是將業(yè)務(wù)邏輯拆分讓一個(gè)腳本只處理固定數(shù)量的key或者改用Redis的MSET、MGET等批量命令來替代循環(huán)中的多個(gè)SET/GET性能提升了數(shù)十倍。Lua腳本是Redis進(jìn)階之路上必須熟練掌握的工具。它用簡(jiǎn)單的語(yǔ)法賦予了Redis處理復(fù)雜原子操作的能力。理解其原子性的根源在于單線程模型牢記其無回滾的特性避開緩存、隨機(jī)性、性能和安全上的坑你就能在分布式系統(tǒng)中游刃有余地解決那些令人頭疼的一致性問題。 Redis Lua腳本原子性原理與實(shí)戰(zhàn)：從單線程模型到分布式鎖應(yīng)用
1. 項(xiàng)目概述為什么我們需要關(guān)注Redis Lua腳本的原子性如果你用過Redis大概率聽過或者用過EVAL命令。你可能知道它能執(zhí)行Lua腳本也模模糊糊地聽說它能“保證原子性”但具體怎么回事為什么能保證以及到底該在什么場(chǎng)景下用它心里可能沒個(gè)準(zhǔn)數(shù)。今天我們就來把這塊硬骨頭啃透。簡(jiǎn)單來說Redis Lua腳本的原子性指的是一個(gè)腳本在執(zhí)行過程中不會(huì)被其他客戶端的命令插入或打斷。這聽起來有點(diǎn)像數(shù)據(jù)庫(kù)里的事務(wù)但實(shí)現(xiàn)機(jī)制和保證級(jí)別完全不同。理解這一點(diǎn)是避免在分布式環(huán)境下踩坑的關(guān)鍵。比如你寫了一個(gè)腳本用來扣減庫(kù)存如果這個(gè)操作不是原子的在高并發(fā)下就可能出現(xiàn)超賣。而Lua腳本正是Redis提供給你解決這類問題的“瑞士軍刀”。這篇文章適合所有正在或即將使用Redis的開發(fā)者無論你是剛?cè)腴T還是已經(jīng)用它做過緩存現(xiàn)在想深入其更高級(jí)的特性。我會(huì)從原理講起掰開揉碎了說清楚“原子性”是怎么來的然后結(jié)合我這些年趟過的坑分享幾個(gè)最實(shí)用、最高頻的使用場(chǎng)景和避坑指南。保證你看完不僅能搞懂還能立刻用起來。2. 核心原理深度拆解Lua腳本的原子性從何而來要理解Lua腳本的原子性我們不能停留在“Redis說它是原子它就是原子”的層面必須深入到Redis的單線程模型和命令執(zhí)行機(jī)制中去。2.1 Redis的單線程事件循環(huán)原子性的基石很多人知道Redis是單線程的但單線程到底意味著什么它指的是Redis核心的網(wǎng)絡(luò)I/O和鍵值數(shù)據(jù)讀寫操作是由一個(gè)主線程串行處理的。Redis基于Reactor模式使用I/O多路復(fù)用來處理海量的客戶端連接但當(dāng)涉及到執(zhí)行命令、操作內(nèi)存數(shù)據(jù)時(shí)所有命令都會(huì)進(jìn)入一個(gè)隊(duì)列由這個(gè)單線程依次取出、執(zhí)行、返回結(jié)果。這就帶來了一個(gè)最直接的推論在任意時(shí)刻Redis服務(wù)器最多只執(zhí)行一個(gè)命令。當(dāng)一個(gè)命令正在處理時(shí)其他所有命令都必須等待。Lua腳本在Redis中被視為一個(gè)“命令”。當(dāng)你發(fā)送EVAL “return redis.call(‘GET’ KEYS[1])” 1 mykey時(shí)對(duì)于Redis的事件循環(huán)來說這和發(fā)送一個(gè)簡(jiǎn)單的GET mykey命令沒有本質(zhì)區(qū)別——都是一個(gè)待處理的任務(wù)項(xiàng)。因此Lua腳本執(zhí)行的原子性首先繼承自Redis單線程命令處理的原子性。一個(gè)腳本一旦開始執(zhí)行在其執(zhí)行完畢并返回結(jié)果之前Redis不會(huì)去處理任何其他客戶端的任何命令。這就從根本上杜絕了線程間資源競(jìng)爭(zhēng)的問題這是與多線程數(shù)據(jù)庫(kù)如MySQL實(shí)現(xiàn)事務(wù)隔離級(jí)別完全不同的底層邏輯。2.2 Lua腳本的執(zhí)行引擎嵌入與隔離Redis內(nèi)嵌了Lua解釋器。當(dāng)你調(diào)用EVAL時(shí)發(fā)生的事情可以分解為以下幾個(gè)步驟接收與解析Redis服務(wù)器接收到EVAL命令和完整的Lua腳本字符串。編譯與加載Redis的Lua引擎會(huì)編譯如果未緩存并加載這段腳本。腳本中通過redis.call()或redis.pcall()函數(shù)來調(diào)用Redis命令。執(zhí)行Lua解釋器開始逐行執(zhí)行腳本中的邏輯。每當(dāng)遇到redis.call()時(shí)它會(huì)向Redis的核心命令執(zhí)行器發(fā)起一個(gè)“內(nèi)部調(diào)用”。原子性保證的關(guān)鍵這些“內(nèi)部調(diào)用”雖然也是Redis命令但它們并非來自網(wǎng)絡(luò)客戶端而是來自當(dāng)前正在執(zhí)行的Lua腳本上下文。Redis的單線程執(zhí)行器會(huì)處理這些內(nèi)部調(diào)用但由于執(zhí)行器本身正被這個(gè)腳本“獨(dú)占”所以這些內(nèi)部調(diào)用同樣不會(huì)被其他客戶端命令打斷。腳本中的所有Redis操作可能是幾十個(gè)GET、SET、INCR在效果上被捆綁成了一個(gè)不可分割的整體。這里有一個(gè)非常重要的點(diǎn)Lua腳本的原子性是“執(zhí)行過程”的原子性而非“失敗回滾”的原子性。如果腳本在執(zhí)行到一半時(shí)因?yàn)榇abug比如對(duì)nil值做算術(shù)運(yùn)算而拋出異常腳本會(huì)停止執(zhí)行但之前已經(jīng)執(zhí)行成功的Redis命令不會(huì)被回滾。這一點(diǎn)和傳統(tǒng)數(shù)據(jù)庫(kù)的ACID事務(wù)有本質(zhì)區(qū)別。Redis沒有Undo Log。注意務(wù)必區(qū)分“原子性”和“事務(wù)性”。Redis Lua腳本提供的是原子執(zhí)行Atomic Execution而非原子提交Atomic Commit。它保證了操作組合不被干擾但不保證所有操作要么全做要么全不做。你需要通過腳本內(nèi)的邏輯判斷來實(shí)現(xiàn)類似“回滾”的效果。2.3 與Redis事務(wù)MULTI/EXEC的對(duì)比很多人會(huì)把Lua腳本和Redis的MULTI/EXEC事務(wù)命令搞混。它們確實(shí)有相似的目標(biāo)但實(shí)現(xiàn)和保證級(jí)別不同。特性Redis Lua 腳本Redis MULTI/EXEC 事務(wù)原子性保證強(qiáng)原子性。腳本執(zhí)行期間無其他命令干擾。弱原子性。僅在EXEC執(zhí)行時(shí)保證命令隊(duì)列連續(xù)執(zhí)行但其他客戶端命令可能在MULTI后、EXEC前執(zhí)行。隔離性完全隔離。腳本看到的是執(zhí)行開始時(shí)的一致性數(shù)據(jù)快照因?yàn)闊o干擾。可能遇到競(jìng)態(tài)條件。在WATCH機(jī)制下可實(shí)現(xiàn)CASCheck-And-Set但更復(fù)雜。回滾能力無。執(zhí)行失敗的命令不會(huì)回滾。無。即使某個(gè)命令失敗隊(duì)列后面的命令仍會(huì)執(zhí)行。復(fù)雜性高。需要編寫Lua代碼調(diào)試相對(duì)復(fù)雜。低。只是將命令排隊(duì)語(yǔ)法簡(jiǎn)單。應(yīng)用場(chǎng)景復(fù)雜的多步邏輯需要強(qiáng)一致性保證如庫(kù)存扣減、狀態(tài)轉(zhuǎn)換。簡(jiǎn)單的命令批量執(zhí)行對(duì)原子性要求不極致或配合WATCH實(shí)現(xiàn)樂觀鎖。核心區(qū)別在于在MULTI和EXEC之間Redis只是將命令排隊(duì)并沒有阻止其他客戶端執(zhí)行命令。因此事務(wù)隊(duì)列中的命令在執(zhí)行時(shí)操作的數(shù)據(jù)可能已經(jīng)被其他客戶端修改。而Lua腳本在執(zhí)行全過程中數(shù)據(jù)視圖是凍結(jié)的。實(shí)操心得對(duì)于需要“讀取-計(jì)算-寫入”模式的復(fù)雜操作無腦選擇Lua腳本。使用MULTI/EXEC事務(wù)你很可能需要配合WATCH來實(shí)現(xiàn)樂觀鎖代碼會(huì)變得冗長(zhǎng)且容易出錯(cuò)。而Lua腳本一個(gè)命令搞定既簡(jiǎn)潔又可靠。3. Lua腳本的“魔鬼細(xì)節(jié)”與避坑指南理解了基本原理我們來看看實(shí)際使用中那些容易踩坑的細(xì)節(jié)。這些往往是官方文檔不會(huì)著重強(qiáng)調(diào)但卻是保障線上穩(wěn)定性的關(guān)鍵。3.1 腳本的緩存與SHA1性能與管理的平衡每次發(fā)送一個(gè)很長(zhǎng)的Lua腳本字符串網(wǎng)絡(luò)開銷和Redis的解析開銷都很大。因此Redis提供了SCRIPT LOAD和EVALSHA命令。SCRIPT LOAD script將腳本加載到Redis服務(wù)器內(nèi)存返回一個(gè)該腳本的SHA1校驗(yàn)和。EVALSHA sha1 numkeys key [key …] arg [arg …]通過SHA1值來執(zhí)行已加載的腳本。最佳實(shí)踐是在應(yīng)用啟動(dòng)時(shí)加載所有需要的Lua腳本獲取其SHA1值并緩存到本地如本地變量或配置中心。后續(xù)執(zhí)行一律使用EVALSHA。這能極大減少網(wǎng)絡(luò)傳輸量。但是這里有個(gè)大坑腳本緩存不是永久的。Redis的腳本緩存是易失的重啟、執(zhí)行SCRIPT FLUSH命令或者當(dāng)服務(wù)器內(nèi)存不足觸發(fā)某些機(jī)制時(shí)緩存都可能被清除。如果你用EVALSHA去執(zhí)行一個(gè)已經(jīng)不存在的腳本Redis會(huì)返回一個(gè)NOSCRIPT錯(cuò)誤。避坑策略實(shí)現(xiàn)一個(gè)安全的執(zhí)行封裝不要直接調(diào)用EVALSHA。寫一個(gè)包裝函數(shù)先嘗試EVALSHA如果捕獲到NOSCRIPT錯(cuò)誤則回退到使用EVAL重新發(fā)送腳本并執(zhí)行同時(shí)可以重新緩存SHA1值。-- 偽代碼示例 function safe_evalsha(client, sha1, keys, args) local result client.evalsha(sha1, #keys, unpack(keys, args)) if result.error and result.error:contains(‘NOSCRIPT’) then -- 重新加載腳本這里需要你有原始的script字符串 client.script(‘load’ original_script) -- 重試 result client.evalsha(sha1, #keys, unpack(keys, args)) end return result end將腳本作為應(yīng)用配置管理將Lua腳本內(nèi)容像SQL語(yǔ)句一樣存儲(chǔ)在版本控制系統(tǒng)中。應(yīng)用啟動(dòng)時(shí)從固定位置讀取并加載。這樣也方便腳本的版本管理和審計(jì)。3.2 腳本的“純函數(shù)”與隨機(jī)性一個(gè)影響復(fù)現(xiàn)性的陷阱Redis要求在默認(rèn)配置下Lua腳本必須是純函數(shù)的即對(duì)于相同的輸入KEYS和ARGV腳本執(zhí)行的Redis命令序列必須完全相同。這是因?yàn)镽edis需要根據(jù)腳本內(nèi)容計(jì)算SHA1值用于緩存和復(fù)制。如果你在腳本中使用了隨機(jī)數(shù)math.random或系統(tǒng)時(shí)間os.time就會(huì)違反這個(gè)原則。這會(huì)導(dǎo)致兩個(gè)嚴(yán)重問題主從數(shù)據(jù)不一致在主節(jié)點(diǎn)上執(zhí)行成功的腳本其SHA1值會(huì)被同步給從節(jié)點(diǎn)。但由于隨機(jī)性腳本在從節(jié)點(diǎn)重放時(shí)執(zhí)行的命令序列可能不同導(dǎo)致最終數(shù)據(jù)不一致。AOF持久化問題如果開啟了AOF腳本是以EVALSHA形式記錄的。重啟后通過AOF恢復(fù)時(shí)如果腳本因?yàn)殡S機(jī)性而行為不同數(shù)據(jù)就亂了。解決方案將隨機(jī)性因素作為參數(shù)傳入所有需要隨機(jī)數(shù)或時(shí)間戳的地方都在客戶端生成好通過ARGV參數(shù)傳遞給腳本。確保腳本邏輯只由輸入?yún)?shù)決定。-- 錯(cuò)誤示范 local randomValue math.random(1 100) redis.call(‘SET’ ‘random_key’ randomValue) -- 正確示范 local randomValue tonumber(ARGV[1]) -- 由客戶端生成并傳入 redis.call(‘SET’ ‘random_key’ randomValue)使用redis.replicate_commands()Redis 3.2在腳本第一行調(diào)用此函數(shù)Redis會(huì)改為記錄腳本實(shí)際產(chǎn)生的寫命令到AOF和復(fù)制鏈路而不是記錄EVALSHA。這放寬了“純函數(shù)”的要求允許腳本內(nèi)包含隨機(jī)邏輯但會(huì)稍微增加AOF日志體積。除非必要否則不建議優(yōu)先使用。3.3 腳本的調(diào)試與日志如何洞察黑盒內(nèi)部調(diào)試Lua腳本是痛苦的因?yàn)樗谝粋€(gè)遠(yuǎn)程的Redis服務(wù)器內(nèi)部執(zhí)行。你無法像本地代碼一樣設(shè)置斷點(diǎn)。這里有幾個(gè)實(shí)用的調(diào)試技巧使用redis.log函數(shù)輸出日志Redis Lua引擎提供了redis.log(loglevel message)函數(shù)。你可以將中間變量或執(zhí)行路徑信息打印到Redis的日志文件中默認(rèn)是stdout或配置的日志文件。redis.log(redis.LOG_NOTICE “Key count: ” .. #KEYS) redis.log(redis.LOG_NOTICE “First arg: ” .. tostring(ARGV[1]))注意日志級(jí)別redis.LOG_DEBUG在默認(rèn)配置下可能不會(huì)輸出建議使用redis.LOG_NOTICE或redis.LOG_WARNING。生產(chǎn)環(huán)境要慎用避免日志洪水。在測(cè)試環(huán)境使用redis-cli --eval這是最直接的測(cè)試方式。你可以將腳本寫在一個(gè).lua文件里然后用redis-cli執(zhí)行并觀察返回值和數(shù)據(jù)變化。redis-cli --eval /path/to/myscript.lua key1 key2 arg1 arg2分步模擬與單元測(cè)試對(duì)于復(fù)雜腳本在本地用Lua環(huán)境模擬Redis調(diào)用是不現(xiàn)實(shí)的。更好的方法是為你的腳本編寫一個(gè)“客戶端模擬層”的單元測(cè)試。使用一個(gè)內(nèi)存中的模擬對(duì)象來替代redis.call驗(yàn)證你的業(yè)務(wù)邏輯是否正確。這能保證腳本核心邏輯的可靠性。實(shí)操心得復(fù)雜的Lua腳本在編寫時(shí)就應(yīng)該像編寫核心業(yè)務(wù)代碼一樣進(jìn)行充分的邏輯審查和邊界條件測(cè)試。將其視為你應(yīng)用代碼的一部分而不是一個(gè)可以隨意拼接的字符串。4. 五大核心使用場(chǎng)景與實(shí)戰(zhàn)代碼解析理論說再多不如看實(shí)戰(zhàn)。下面我結(jié)合五個(gè)最常見的場(chǎng)景給出具體的腳本示例和代碼解析。你可以把這些當(dāng)作模板直接修改使用。4.1 場(chǎng)景一分布式鎖的釋放解決原子性問題這是最經(jīng)典的場(chǎng)景。普通的分布式鎖實(shí)現(xiàn)是SET key uuid NX PX 30000釋放時(shí)需要用GET判斷uuid是否匹配再DEL。但GET和DEL是兩個(gè)命令不是原子的。-- KEYS[1]: 鎖的key -- ARGV[1]: 當(dāng)前客戶端持有的鎖標(biāo)識(shí)如UUID -- 返回值1表示釋放成功0表示釋放失敗鎖不屬于該客戶端或已過期 if redis.call(‘GET’ KEYS[1]) ARGV[1] then -- 只有鎖的持有者才能釋放 return redis.call(‘DEL’ KEYS[1]) else return 0 end為什么必須用Lua腳本如果不用腳本在GET之后、DEL之前鎖可能因?yàn)槌瑫r(shí)被自動(dòng)釋放然后被另一個(gè)客戶端獲取。此時(shí)再執(zhí)行DEL就會(huì)誤刪別人的鎖。腳本保證了“判斷所有權(quán)”和“刪除鎖”是一個(gè)不可分割的操作。4.2 場(chǎng)景二庫(kù)存扣減與防超賣電商秒殺、搶購(gòu)等場(chǎng)景的基石。核心是“檢查庫(kù)存”和“扣減庫(kù)存”必須原子。-- KEYS[1]: 商品庫(kù)存key例如 stock:item_1001 -- ARGV[1]: 本次需要扣減的數(shù)量 -- 返回值剩余庫(kù)存如果扣減成功或一個(gè)錯(cuò)誤值如-1表示庫(kù)存不足 local current tonumber(redis.call(‘GET’ KEYS[1])) if current nil then current 0 end local quantity tonumber(ARGV[1]) if current quantity then -- 庫(kù)存不足返回-1。也可以返回0或特定字符串由客戶端約定。 return -1 end -- 庫(kù)存充足執(zhí)行扣減 local newStock current - quantity redis.call(‘SET’ KEYS[1] newStock) return newStock進(jìn)階技巧這個(gè)腳本返回的是扣減后的庫(kù)存。在高并發(fā)下你可能更關(guān)心是否扣減成功。可以修改為成功返回1失敗返回0。更復(fù)雜的場(chǎng)景可能涉及多個(gè)商品庫(kù)存的同時(shí)扣減購(gòu)物車只需擴(kuò)展KEYS和ARGV在腳本內(nèi)循環(huán)處理即可。4.3 場(chǎng)景三限流器滑動(dòng)時(shí)間窗口實(shí)現(xiàn)一個(gè)在N秒內(nèi)最多允許M次請(qǐng)求的限流器。-- KEYS[1]: 限流器的key例如 rate_limit:user_123:api_login -- ARGV[1]: 時(shí)間窗口大小秒 -- ARGV[2]: 最大請(qǐng)求次數(shù) -- ARGV[3]: 當(dāng)前時(shí)間戳由客戶端傳入保證一致性 local window tonumber(ARGV[1]) local limit tonumber(ARGV[2]) local now tonumber(ARGV[3]) -- 移除時(shí)間窗口之前的記錄 redis.call(‘ZREMRANGEBYSCORE’ KEYS[1] 0 now - window) -- 獲取當(dāng)前窗口內(nèi)的請(qǐng)求數(shù)量 local current redis.call(‘ZCARD’ KEYS[1]) if current limit then -- 未超限添加本次請(qǐng)求記錄分?jǐn)?shù)為當(dāng)前時(shí)間戳 redis.call(‘ZADD’ KEYS[1] now now) -- 成員也用時(shí)間戳保證唯一 -- 設(shè)置key的過期時(shí)間避免冷數(shù)據(jù)長(zhǎng)期占用內(nèi)存 redis.call(‘EXPIRE’ KEYS[1] window 1) return 1 -- 允許通過 else return 0 -- 拒絕通過 end解析這里用到了Redis的Sorted SetZSET。每個(gè)請(qǐng)求的時(shí)間戳作為分?jǐn)?shù)和成員。腳本原子地完成了“清理舊數(shù)據(jù)”、“計(jì)數(shù)”、“判斷”、“添加新記錄”和“設(shè)置過期時(shí)間”這五個(gè)步驟。如果不用腳本在高并發(fā)下計(jì)數(shù)和添加操作之間可能被其他請(qǐng)求插入導(dǎo)致計(jì)數(shù)不準(zhǔn)。4.4 場(chǎng)景四簡(jiǎn)單的消息隊(duì)列確保ACK和重試一個(gè)需要確保消息被成功處理后才刪除的簡(jiǎn)單隊(duì)列。-- KEYS[1]: 待處理隊(duì)列 key (list)例如 task_queue -- KEYS[2]: 處理中隊(duì)列 key (list)例如 task_processing -- ARGV[1]: 當(dāng)前消費(fèi)者ID用于故障恢復(fù)時(shí)識(shí)別 -- ARGV[2]: 消息處理超時(shí)時(shí)間秒 -- 1. 嘗試從處理中隊(duì)列取回本消費(fèi)者超時(shí)的任務(wù)模擬ACK失敗后的重新入隊(duì) local processingTasks redis.call(‘LRANGE’ KEYS[2] 0 -1) local recovered 0 for i task in ipairs(processingTasks) do -- 這里假設(shè)任務(wù)數(shù)據(jù)中包含了消費(fèi)者ID和時(shí)間戳格式為 consumerId:timestamp:taskData -- 這是一個(gè)簡(jiǎn)化示例實(shí)際格式需自行定義 local consumerId timestamp _ string.match(task “^(%d):(%d):(.)$”) if consumerId ARGV[1] and tonumber(timestamp) tonumber(ARGV[3]) then -- ARGV[3]為當(dāng)前時(shí)間戳 redis.call(‘LREM’ KEYS[2] 1 task) redis.call(‘RPUSH’ KEYS[1] task) recovered recovered 1 end end -- 2. 從待處理隊(duì)列取出一個(gè)新任務(wù) local task redis.call(‘LPOP’ KEYS[1]) if task then -- 給任務(wù)打上消費(fèi)者ID和當(dāng)前時(shí)間戳然后放入處理中隊(duì)列 local taggedTask ARGV[1] .. “:” .. ARGV[3] .. “:” .. task redis.call(‘RPUSH’ KEYS[2] taggedTask) -- 設(shè)置處理中隊(duì)列的過期時(shí)間略可通過外部定時(shí)任務(wù)清理 return {recovered task} -- 返回恢復(fù)的任務(wù)數(shù)和取出的新任務(wù) else return {recovered nil} -- 沒有新任務(wù) end說明這是一個(gè)簡(jiǎn)化版的可ACK隊(duì)列。生產(chǎn)環(huán)境更復(fù)雜的需求如優(yōu)先級(jí)、延遲隊(duì)列建議直接使用成熟的中間件如RabbitMQ、Kafka或Redis的Stream類型。但這個(gè)腳本展示了如何用Lua原子地實(shí)現(xiàn)“狀態(tài)轉(zhuǎn)移”和“故障恢復(fù)檢查”。4.5 場(chǎng)景五聚合統(tǒng)計(jì)與更新需要先讀取多個(gè)值計(jì)算后再更新回去的場(chǎng)景。比如更新用戶排行榜分?jǐn)?shù)。-- KEYS[1]: 用戶分?jǐn)?shù)key (hash field)例如 user:1001:score -- KEYS[2]: 全局排行榜key (zset)例如 leaderboard -- ARGV[1]: 本次要增加的分?jǐn)?shù) -- ARGV[2]: 用戶ID local delta tonumber(ARGV[1]) local userId ARGV[2] -- 獲取當(dāng)前分?jǐn)?shù) local currentScore tonumber(redis.call(‘HGET’ KEYS[1] ‘score’)) or 0 -- 計(jì)算新分?jǐn)?shù) local newScore currentScore delta -- 更新Hash中的分?jǐn)?shù) redis.call(‘HSET’ KEYS[1] ‘score’ newScore) -- 更新ZSet排行榜 redis.call(‘ZADD’ KEYS[2] newScore userId) return newScore為什么需要原子性如果不用腳本先HGET客戶端計(jì)算再HSET和ZADD在并發(fā)更新同一個(gè)用戶分?jǐn)?shù)時(shí)最后的ZADD可能基于一個(gè)舊的分?jǐn)?shù)值導(dǎo)致排行榜數(shù)據(jù)錯(cuò)誤。腳本保證了“讀-計(jì)算-寫”這個(gè)鏈路的原子性。5. 性能、安全與生產(chǎn)環(huán)境最佳實(shí)踐將Lua腳本用于生產(chǎn)環(huán)境除了功能正確還必須考慮性能和安全。5.1 腳本的執(zhí)行時(shí)間與超時(shí)控制Lua腳本會(huì)阻塞Redis的單線程。一個(gè)執(zhí)行緩慢的腳本比如包含復(fù)雜循環(huán)或KEYS *這樣的操作會(huì)拖垮整個(gè)Redis實(shí)例導(dǎo)致所有其他請(qǐng)求超時(shí)。Redis默認(rèn)配置了lua-time-limit通常為5秒。如果腳本執(zhí)行超過這個(gè)時(shí)間Redis會(huì)開始記錄日志并開始接受其他客戶端的SCRIPT KILL和SHUTDOWN NOSAVE命令。最佳實(shí)踐腳本必須輕量、高效。避免在Lua腳本中進(jìn)行大量耗時(shí)的計(jì)算。Redis的優(yōu)勢(shì)是內(nèi)存操作和I/O復(fù)雜計(jì)算應(yīng)放在客戶端。避免在腳本中使用KEYS命令進(jìn)行模式匹配。這不僅慢而且在集群模式下不可用。應(yīng)該使用SCAN但注意SCAN在腳本中也可能使執(zhí)行時(shí)間變長(zhǎng)或者從根本上重新設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)和訪問模式。對(duì)腳本進(jìn)行性能測(cè)試。用redis-benchmark或模擬生產(chǎn)壓力的工具測(cè)試腳本在高并發(fā)下的執(zhí)行時(shí)間和Redis的QPS變化。設(shè)置合理的超時(shí)和重試機(jī)制。客戶端調(diào)用腳本時(shí)設(shè)置一個(gè)比lua-time-limit更短的超時(shí)時(shí)間并準(zhǔn)備好重試或降級(jí)策略。5.2 腳本的安全性防止注入與惡意代碼永遠(yuǎn)不要相信來自用戶輸入的腳本內(nèi)容。如果你允許客戶端上傳并執(zhí)行任意Lua腳本那將是一個(gè)巨大的安全漏洞。黃金法則腳本內(nèi)容應(yīng)該來自受信任的源如你的應(yīng)用程序服務(wù)器并且是固定的、經(jīng)過審查的字符串模板。客戶端只能傳遞KEYS和ARGV參數(shù)。參數(shù)化就像SQL預(yù)編譯語(yǔ)句一樣永遠(yuǎn)不要用字符串拼接的方式將用戶輸入直接拼接到腳本中。務(wù)必使用KEYS和ARGV數(shù)組來傳遞變量。-- 危險(xiǎn) local userInput ARGV[1] local script “return redis.call(‘GET’ ‘” .. userInput .. “’)” -- 如果userInput是 ’); DROP ALL KEYS; -- 就完了 -- 安全 local key KEYS[1] -- 用戶輸入作為key參數(shù)傳入 return redis.call(‘GET’ key)沙箱環(huán)境Redis的Lua環(huán)境是沙箱化的移除了很多危險(xiǎn)的標(biāo)準(zhǔn)庫(kù)函數(shù)如os.executeio.open。但即便如此也不應(yīng)放松警惕。5.3 在Redis集群模式下的使用在Redis Cluster中數(shù)據(jù)分布在不同的槽slot上。Lua腳本操作的所有key必須位于同一個(gè)節(jié)點(diǎn)上即所有key必須屬于同一個(gè)hash slot。這是由Redis Cluster的數(shù)據(jù)分片機(jī)制決定的因?yàn)槟_本需要在一個(gè)節(jié)點(diǎn)上原子執(zhí)行。如何保證對(duì)于需要操作多個(gè)key的腳本確保這些key使用相同的hash tag。Redis Cluster的hash slot計(jì)算可以通過{}來指定只對(duì)括號(hào)內(nèi)的內(nèi)容進(jìn)行hash。例如user:{1001}:profile和user:{1001}:orders它們都會(huì)被分配到user:1001這個(gè)key所在的slot因?yàn)橹挥?001被用于計(jì)算hash。如果你的腳本邏輯必須操作分布在不同節(jié)點(diǎn)的key那么Lua腳本就無法直接使用了。你需要重新設(shè)計(jì)數(shù)據(jù)模型或者考慮使用其他分布式事務(wù)方案但這超出了Redis的范疇。實(shí)操心得在微服務(wù)架構(gòu)下我通常會(huì)將需要強(qiáng)一致性的、涉及多個(gè)key的核心業(yè)務(wù)操作封裝成獨(dú)立的服務(wù)。這個(gè)服務(wù)內(nèi)部通過預(yù)加載的Lua腳本與Redis交互對(duì)外提供原子操作API。這樣既保證了數(shù)據(jù)一致性又隔離了復(fù)雜性。6. 常見問題排查與調(diào)試技巧實(shí)錄即使理解了所有原理和最佳實(shí)踐線上問題依然可能出現(xiàn)。下面是我遇到過的幾個(gè)典型問題及排查思路。6.1 錯(cuò)誤“BUSY Redis is busy running a script”現(xiàn)象客戶端收到這個(gè)錯(cuò)誤或者觀察到Redis響應(yīng)變慢甚至無響應(yīng)。原因有一個(gè)Lua腳本執(zhí)行時(shí)間過長(zhǎng)超過了lua-time-limit并且還沒有被殺死。Redis在腳本超時(shí)后會(huì)允許執(zhí)行SCRIPT KILL但如果腳本已經(jīng)執(zhí)行過寫命令SCRIPT KILL就無法終止它為了保證數(shù)據(jù)一致性此時(shí)Redis會(huì)處于這種“忙”狀態(tài)。排查與解決使用redis-cli連接服務(wù)器執(zhí)行SCRIPT KILL。如果成功服務(wù)會(huì)恢復(fù)。如果SCRIPT KILL失敗因?yàn)槟_本有寫操作那么唯一的辦法就是等待腳本自然結(jié)束或者執(zhí)行SHUTDOWN NOSAVE強(qiáng)制關(guān)閉Redis數(shù)據(jù)會(huì)丟失這是最后手段。根本解決分析是哪個(gè)腳本導(dǎo)致的。檢查Redis日志會(huì)記錄慢腳本優(yōu)化腳本邏輯避免大循環(huán)、KEYS命令等。對(duì)腳本進(jìn)行超時(shí)監(jiān)控和熔斷。6.2 錯(cuò)誤“NOSCRIPT No matching script”現(xiàn)象使用EVALSHA時(shí)頻繁報(bào)此錯(cuò)。原因腳本緩存丟失。可能是Redis重啟、內(nèi)存淘汰、或人為執(zhí)行了SCRIPT FLUSH。解決如前文所述實(shí)現(xiàn)客戶端的“安全執(zhí)行封裝”在捕獲到NOSCRIPT錯(cuò)誤時(shí)降級(jí)到使用EVAL重試并重新緩存SHA1。6.3 腳本執(zhí)行結(jié)果不符合預(yù)期現(xiàn)象腳本返回nil、false或意外的數(shù)值業(yè)務(wù)邏輯出錯(cuò)。排查步驟檢查參數(shù)傳遞確認(rèn)KEYS和ARGV的數(shù)量、順序、類型與腳本期望的一致。Lua是動(dòng)態(tài)類型tonumber()轉(zhuǎn)換失敗會(huì)得到nil后續(xù)運(yùn)算會(huì)出錯(cuò)。檢查數(shù)據(jù)類型用TYPE命令確認(rèn)你操作的key確實(shí)是你以為的類型String Hash List Set Zset。用redis.call(‘GET’ key)去讀一個(gè)Hash key會(huì)返回錯(cuò)誤。添加調(diào)試日志在測(cè)試環(huán)境在腳本關(guān)鍵分支插入redis.log語(yǔ)句輸出中間變量的值。這是最有效的調(diào)試手段。簡(jiǎn)化與隔離將復(fù)雜腳本拆分成幾個(gè)簡(jiǎn)單的腳本單獨(dú)測(cè)試或者用redis-cli --eval手動(dòng)執(zhí)行逐步驗(yàn)證每一部分邏輯。注意Nil值在Lua中nil和false在條件判斷中都為假。但Redis的redis.call()執(zhí)行失敗會(huì)返回一個(gè)包含err字段的Lua表而不是nil。使用redis.pcall()則會(huì)在錯(cuò)誤時(shí)返回一個(gè)包含err字段的表不會(huì)拋出異常這有時(shí)用于錯(cuò)誤處理。6.4 性能瓶頸排查現(xiàn)象引入Lua腳本后Redis整體QPS下降或延遲增高。排查使用SLOWLOG命令查看Redis慢查詢?nèi)罩尽?zhí)行時(shí)間過長(zhǎng)的腳本會(huì)被記錄在這里。SLOWLOG GET 10可以獲取最近10條慢日志。使用INFO commandstats命令查看所有命令的統(tǒng)計(jì)信息找到EVAL和EVALSHA的調(diào)用次數(shù)和總耗時(shí)計(jì)算平均耗時(shí)。監(jiān)控網(wǎng)絡(luò)I/O如果腳本很大且沒有使用EVALSHA網(wǎng)絡(luò)傳輸可能成為瓶頸。檢查客戶端和服務(wù)器之間的帶寬和流量。Profiling腳本在非生產(chǎn)環(huán)境可以在腳本前后使用redis.call(‘TIME’)獲取時(shí)間戳粗略計(jì)算腳本內(nèi)各部分的耗時(shí)。一個(gè)典型的性能優(yōu)化案例我們有一個(gè)腳本最初為了“通用”在內(nèi)部使用了for循環(huán)遍歷ARGV來動(dòng)態(tài)構(gòu)造多個(gè)命令。后來發(fā)現(xiàn)當(dāng)參數(shù)很多時(shí)腳本編譯和執(zhí)行效率很低。優(yōu)化方案是將業(yè)務(wù)邏輯拆分讓一個(gè)腳本只處理固定數(shù)量的key或者改用Redis的MSET、MGET等批量命令來替代循環(huán)中的多個(gè)SET/GET性能提升了數(shù)十倍。Lua腳本是Redis進(jìn)階之路上必須熟練掌握的工具。它用簡(jiǎn)單的語(yǔ)法賦予了Redis處理復(fù)雜原子操作的能力。理解其原子性的根源在于單線程模型牢記其無回滾的特性避開緩存、隨機(jī)性、性能和安全上的坑你就能在分布式系統(tǒng)中游刃有余地解決那些令人頭疼的一致性問題。