1. 從“為什么”開始Lua腳本在Redis中的核心價值如果你用過Redis大概率寫過這樣的業(yè)務(wù)邏輯先GET一個計(jì)數(shù)器判斷是否超過閾值如果沒超過再INCR。這在客戶端看來是兩步操作但在高并發(fā)下這兩步操作之間可能被其他客戶端的請求插入導(dǎo)致計(jì)數(shù)不準(zhǔn)確。為了解決這類問題Redis從2.6版本開始內(nèi)置了Lua腳本引擎。簡單說它允許你將多個Redis命令打包成一個腳本在服務(wù)器端原子性地執(zhí)行。這不僅僅是“把命令打包”它徹底改變了我們使用Redis的方式從單純的數(shù)據(jù)存儲變成了一個可編程的、具備事務(wù)能力的計(jì)算節(jié)點(diǎn)。原子性是其最閃耀的光環(huán)。在Lua腳本執(zhí)行期間整個腳本會被當(dāng)作一個命令服務(wù)器不會處理其他任何命令這完美解決了上述的競態(tài)條件問題。其次它減少了網(wǎng)絡(luò)開銷。原本需要多次往返Round-Trip的多個命令現(xiàn)在只需發(fā)送一次腳本和一次結(jié)果對于延遲敏感的應(yīng)用提升顯著。最后它帶來了邏輯的封裝與復(fù)用。你可以把復(fù)雜的業(yè)務(wù)校驗(yàn)、計(jì)算邏輯固化在服務(wù)器端的一個腳本里客戶端只需調(diào)用一個簡單的EVAL或EVALSHA命令降低了客戶端的復(fù)雜度也保證了邏輯的一致性。但別急著歡呼Lua腳本也是一把雙刃劍。用得不好它可能成為整個系統(tǒng)的“血栓”——一個寫壞了的腳本可能會長時間阻塞整個Redis實(shí)例導(dǎo)致所有請求超時。因此深入理解Lua腳本的每一個細(xì)節(jié)從編寫、調(diào)試到運(yùn)維是每個資深Redis使用者必須掌握的技能。這篇教程我將結(jié)合多年踩坑經(jīng)驗(yàn)帶你從入門到精通不止于語法更聚焦于生產(chǎn)環(huán)境下的實(shí)戰(zhàn)要點(diǎn)和避坑指南。2. 腳本編寫基礎(chǔ)語法、密鑰與參數(shù)編寫Redis Lua腳本你首先得知道它能做什么。腳本中你可以使用幾乎全部的Redis命令通過redis.call()或redis.pcall()來調(diào)用。兩者的區(qū)別至關(guān)重要call()在執(zhí)行命令出錯時會直接拋出Lua錯誤導(dǎo)致腳本停止而pcall()則會以Lua表的形式捕獲錯誤允許腳本繼續(xù)執(zhí)行并做錯誤處理。在絕大多數(shù)需要嚴(yán)格原子性和一致性的場景比如扣庫存你應(yīng)該使用redis.call()確保任何命令失敗都導(dǎo)致整個腳本回滾。只有在某些非核心命令失敗你仍希望腳本繼續(xù)時比如記錄日志到另一個不關(guān)鍵的Key才考慮pcall()。2.1 密鑰KEYS與參數(shù)ARGV的規(guī)范這是新手最容易栽跟頭的地方。在EVAL命令中你需要顯式地傳遞腳本中用到的所有Redis鍵名和普通參數(shù)。EVAL “return {KEYS[1], ARGV[1]}” 1 mykey hello這里的1表示后面緊跟的1個參數(shù)是鍵名mykey它會被放入Lua腳本的KEYS全局?jǐn)?shù)組中。之后的參數(shù)hello則放入ARGV數(shù)組。為什么非要分開這關(guān)系到Redis集群Cluster的運(yùn)作。集群模式下Redis需要根據(jù)鍵名來計(jì)算這個腳本應(yīng)該被路由到哪個槽位slot的節(jié)點(diǎn)上執(zhí)行。如果你把所有變量都塞進(jìn)ARGV對于不操作任何鍵的腳本是可行的但一旦操作了鍵集群就無法正確路由腳本會報(bào)錯。因此一個必須遵守的規(guī)范是所有在腳本中會被redis.call操作的鍵名都必須通過KEYS數(shù)組傳遞并且數(shù)量必須在EVAL命令中聲明準(zhǔn)確。一個常見的反模式是動態(tài)拼接鍵名比如local userKey ‘user:’ .. ARGV[1]; redis.call(‘SET’, userKey, ARGV[2])。這在單機(jī)Redis上能跑但在集群模式下由于鍵名userKey沒有出現(xiàn)在KEYS數(shù)組中腳本可能會被發(fā)送到錯誤的節(jié)點(diǎn)執(zhí)行導(dǎo)致“-CROSSSLOT”錯誤。正確的做法是如果鍵名模式固定應(yīng)將前綴也放入KEYS如果完全動態(tài)則意味著你的數(shù)據(jù)模型可能不適合在集群下使用此類腳本。2.2 Lua數(shù)據(jù)類型與Redis的轉(zhuǎn)換Lua和Redis有各自的數(shù)據(jù)類型系統(tǒng)它們之間的自動轉(zhuǎn)換需要了然于胸。當(dāng)Redis命令的結(jié)果返回到Lua中時Redis的整數(shù)回復(fù)如INCR的結(jié)果會被轉(zhuǎn)換為Lua的number類型浮點(diǎn)數(shù)。但要注意Lua number是浮點(diǎn)型超大整數(shù)可能會損失精度。Redis的批量字符串回復(fù)GET到的字符串被轉(zhuǎn)換為Luastring。Redis的多條批量回復(fù)LRANGE列表被轉(zhuǎn)換為Luatable數(shù)組。Redis的狀態(tài)回復(fù)OK和錯誤回復(fù)會被轉(zhuǎn)換為Luatable結(jié)構(gòu)比較特殊通常你需要檢查返回值的err字段。反過來當(dāng)Lua腳本返回值給客戶端時Luanumber會被轉(zhuǎn)換為Redis的整數(shù)回復(fù)。但如果這個number是浮點(diǎn)數(shù)如3.14Redis會先將其轉(zhuǎn)換為字符串“3.14”然后作為批量字符串回復(fù)返回。這里有個大坑redis.call(‘GET’, ‘counter’)返回的可能是Lua string “5”而tonumber()轉(zhuǎn)換后做計(jì)算再返回一個Lua number 6。客戶端收到的可能是整數(shù)6也可能是字符串“6”取決于Lua number是否是整數(shù)。為了結(jié)果一致性我習(xí)慣在腳本最后顯式使用tostring()或tonumber()進(jìn)行格式化。3. 腳本管理實(shí)戰(zhàn)加載、緩存與持久化沒人會每次執(zhí)行都發(fā)送一遍完整的腳本字符串那太浪費(fèi)網(wǎng)絡(luò)帶寬了。Redis提供了SCRIPT LOAD命令它會計(jì)算腳本的SHA1校驗(yàn)和并緩存腳本返回該SHA1值。之后你就可以用EVALSHA sha1 numkeys key [key …] arg [arg …]來執(zhí)行它效果和EVAL完全一樣。3.1 客戶端的最佳實(shí)踐容錯與加載在生產(chǎn)環(huán)境中直接調(diào)用EVALSHA可能會遇到“NOSCRIPT”錯誤因?yàn)槟_本可能未被加載或已被Redis清除如執(zhí)行了SCRIPT FLUSH。因此一個健壯的客戶端調(diào)用模式應(yīng)該是def execute_script(script_sha, keys, args): try: return redis.evalsha(script_sha, len(keys), *(keys args)) except redis.exceptions.NoScriptError: # 腳本不存在重新加載 script_content load_script_from_disk(‘my_script.lua’) redis.script_load(script_content) # 重試一次 return redis.evalsha(script_sha, len(keys), *(keys args))更高級的做法是在應(yīng)用啟動時或通過配置中心統(tǒng)一預(yù)加載所有需要的腳本到Redis中。對于集群模式你需要確保腳本在所有相關(guān)主節(jié)點(diǎn)上都被加載因?yàn)槟_本的緩存是節(jié)點(diǎn)級別的。3.2 腳本的版本控制與持久化腳本本身也是代碼需要版本管理。我推薦的做法是將Lua腳本作為資源文件存儲在項(xiàng)目的資源目錄如resources/scripts/中并用有意義的文件名命名deduct_inventory.lua。在構(gòu)建或部署流程中計(jì)算腳本的SHA1可以使用sha1sum命令并將其作為配置項(xiàng)或常量寫入客戶端代碼。這樣客戶端代碼里引用的是固定的SHA1與具體的腳本內(nèi)容解耦。部署時通過初始化腳本或啟動流程將新版腳本SCRIPT LOAD到Redis。如果SHA1與之前不同自然就完成了“更新”。由于舊客戶端可能還在用舊的SHA1所以腳本變更應(yīng)該是向后兼容的或者需要配合客戶端灰度發(fā)布。千萬不要把Lua腳本字符串硬編碼在業(yè)務(wù)代碼里那會給維護(hù)和調(diào)試帶來噩夢。4. 性能與阻塞腳本執(zhí)行的黑暗面這是Lua腳本最需要警惕的部分。Redis是單線程的Lua腳本會在這個線程中運(yùn)行直到完成。這意味著一個執(zhí)行緩慢的腳本會阻塞整個實(shí)例所有其他請求都會排隊(duì)等待超時進(jìn)而可能引發(fā)雪崩。4.1 哪些操作會讓腳本變慢循環(huán)中的大量數(shù)據(jù)操作在Lua里用for循環(huán)遍歷一個包含十萬個元素的KEYS并對每個元素調(diào)用redis.call(‘HGET’, …)。這相當(dāng)于在Redis單線程里串行執(zhí)行十萬個命令阻塞時間可想而知。執(zhí)行時間復(fù)雜度高的Redis命令在腳本中執(zhí)行KEYS *、HGETALL在一個巨大的哈希上、LRANGE 0 -1在一個超長列表上。復(fù)雜的Lua計(jì)算雖然Lua計(jì)算本身不涉及Redis但CPU密集型的運(yùn)算如加密解密、復(fù)雜字符串處理同樣會長時間占用線程。4.2 監(jiān)控與規(guī)避SCRIPT KILL和SHUTDOWN NOSAVERedis提供了兩個救命稻草但都有嚴(yán)格條件SCRIPT KILL只能殺死還未執(zhí)行過任何寫命令的腳本。如果一個腳本已經(jīng)修改了數(shù)據(jù)SCRIPT KILL會失敗因?yàn)镽edis無法確定部分執(zhí)行的狀態(tài)回滾成本太高。所以這只對純讀的慢腳本有效。SHUTDOWN NOSAVE這是最后的“拔電源”手段。它會強(qiáng)制關(guān)閉Redis且不保存數(shù)據(jù)。這意味著你會丟失最后一次快照RDB之后的所有數(shù)據(jù)。除非情況萬分危急否則不要使用。因此根本之道在于預(yù)防對腳本進(jìn)行性能評估在測試環(huán)境用DEBUG SCRIPT相關(guān)命令或 simply 用TIME命令測量腳本執(zhí)行時間。明確腳本的時間復(fù)雜度。使用redis.set_repl()和redis.breakpoint()Redis 5.0進(jìn)行調(diào)試雖然生產(chǎn)環(huán)境不能用但在測試時你可以用redis.set_repl(redis.REPL_NONE)讓腳本的寫命令不生效然后用redis.breakpoint()設(shè)置斷點(diǎn)通過redis-cli –ldb進(jìn)行單步調(diào)試觀察腳本行為。設(shè)置lua-time-limit在redis.conf中默認(rèn)是5秒。超過這個時間Redis會開始接受其他客戶端的SCRIPT KILL和SHUTDOWN命令。但注意這只是一個檢測機(jī)制腳本本身并不會自動停止它只是給了你一個干預(yù)的機(jī)會窗口。分解大腳本如果邏輯允許將一個大腳本拆分成多個原子性小腳本?；蛘呖紤]是否真的需要原子性有時用WATCH/MULTI/EXEC事務(wù)或者利用Redis的原子命令如INCRBY、HSETNX組合也能達(dá)到目的且更安全。5. 調(diào)試與運(yùn)維讓腳本無所遁形再嚴(yán)謹(jǐn)?shù)拈_發(fā)也離不開調(diào)試。除了上面提到的redis-cli –ldbLua Debugger交互式調(diào)試外還有一些運(yùn)維層面的技巧。5.1 日志與錯誤追蹤在腳本中你不能直接使用print但可以通過redis.log()函數(shù)將日志寫入Redis日志文件注意日志級別。redis.log(redis.LOG_WARNING, “Script started with key: ” .. KEYS[1])這對于追蹤生產(chǎn)環(huán)境復(fù)雜腳本的執(zhí)行路徑非常有用。另外確保用pcall包裹可能出錯的非核心調(diào)用并妥善處理錯誤避免腳本因非關(guān)鍵錯誤而整體失敗。local ok, err redis.pcall(‘SET’, ‘log:’ .. ARGV[1], ‘some info’) if not ok then redis.log(redis.LOG_ERR, “Failed to write log: ” .. err) — 不影響主邏輯繼續(xù)執(zhí)行 end5.2INFO命令中的腳本信息運(yùn)行INFO commandstats可以看到所有命令的調(diào)用統(tǒng)計(jì)其中也包括EVAL和EVALSHA這可以幫助你發(fā)現(xiàn)腳本是否被頻繁調(diào)用。INFO memory中關(guān)于Lua內(nèi)存的部分可以監(jiān)控腳本緩存占用的大小。5.3 復(fù)制與持久化影響需要特別注意的是Lua腳本的復(fù)制Replication和持久化AOF行為。當(dāng)一個腳本被傳播到從節(jié)點(diǎn)或?qū)懭階OF文件時Redis默認(rèn)記錄的是EVAL命令本身即完整的腳本內(nèi)容而不是腳本執(zhí)行過程中產(chǎn)生的具體寫命令。這樣做保證了從節(jié)點(diǎn)或AOF重放時能獲得完全一致的結(jié)果因?yàn)槟_本執(zhí)行是確定性的。但這也意味著如果你的腳本內(nèi)容非常大會對網(wǎng)絡(luò)復(fù)制和AOF文件大小造成壓力。你可以通過redis.replicate_commands()函數(shù)Redis 3.2來改變這一行為讓Redis改為記錄腳本執(zhí)行產(chǎn)生的實(shí)際寫命令序列這通常能顯著減少數(shù)據(jù)量但前提是你的腳本必須是純函數(shù)式的即相同的KEYS和ARGV輸入總是產(chǎn)生相同的寫命令序列否則會導(dǎo)致主從數(shù)據(jù)不一致。6. 經(jīng)典模式與實(shí)戰(zhàn)案例解析理論說了這么多來看幾個實(shí)戰(zhàn)中高頻使用的腳本模式。6.1 分布式鎖的加強(qiáng)版簡單的SET key value NX PX timeout可以實(shí)現(xiàn)鎖但釋放時需要用Lua保證原子性避免誤刪其他客戶端的鎖?！?KEYS[1]: 鎖的key — ARGV[1]: 當(dāng)前客戶端持有的鎖標(biāo)識UUID — ARGV[2]: 鎖的過期時間毫秒 local lockKey KEYS[1] local lockId ARGV[1] local ttl tonumber(ARGV[2]) — 嘗試獲取鎖 local currentLockId redis.call(‘GET’, lockKey) if currentLockId false then — 鎖不存在可以獲取 redis.call(‘SET’, lockKey, lockId, ‘PX’, ttl) return true elseif currentLockId lockId then — 鎖是自己持有的刷新過期時間可重入鎖的簡單實(shí)現(xiàn) redis.call(‘PEXPIRE’, lockKey, ttl) return true else — 鎖被其他客戶端持有 return false end釋放鎖的腳本— KEYS[1]: 鎖的key — ARGV[1]: 期望的鎖標(biāo)識 if redis.call(‘GET’, KEYS[1]) ARGV[1] then return redis.call(‘DEL’, KEYS[1]) else return 0 end6.2 滑動窗口限流實(shí)現(xiàn)一個在最近N秒內(nèi)最多允許M次請求的限流器?！?KEYS[1]: 限流器key如 rate_limiter:user123 — ARGV[1]: 窗口大小秒 — ARGV[2]: 最大請求次數(shù) local key KEYS[1] local window tonumber(ARGV[1]) local limit tonumber(ARGV[2]) local now redis.call(‘TIME’) — Redis 5.0返回秒和微秒 local currentTime tonumber(now[1]) * 1000 math.floor(tonumber(now[2]) / 1000) — 轉(zhuǎn)換為毫秒時間戳 local clearBefore currentTime – window * 1000 — 移除窗口之前的記錄 redis.call(‘ZREMRANGEBYSCORE’, key, 0, clearBefore) — 獲取當(dāng)前窗口內(nèi)的請求數(shù) local currentCount redis.call(‘ZCARD’, key) if currentCount limit then — 未超限添加本次請求記錄用時間戳作為score和member redis.call(‘ZADD’, key, currentTime, currentTime) — 設(shè)置整個key的過期時間避免冷數(shù)據(jù)堆積 redis.call(‘PEXPIRE’, key, window * 1000 1000) — 多加1秒緩沖 return true — 允許通過 else return false — 拒絕 end6.3 庫存扣減與恢復(fù)電商秒殺場景保證庫存不超賣。— KEYS[1]: 商品庫存key (如 stock:sku_1001) — ARGV[1]: 需要扣減的數(shù)量 — ARGV[2]: 本次操作的唯一流水號用于冪等和恢復(fù) local stockKey KEYS[1] local deductAmount tonumber(ARGV[1]) local txId ARGV[2] — 檢查庫存是否充足 local currentStock tonumber(redis.call(‘GET’, stockKey)) if currentStock nil then return {err “stock key not exist”} end if currentStock deductAmount then return {err “insufficient stock”, available currentStock} end — 扣減庫存 local newStock currentStock – deductAmount redis.call(‘SET’, stockKey, newStock) — 記錄扣減流水用于可能的恢復(fù)如訂單取消 local recordKey ‘stock_record:’ .. txId redis.call(‘HSET’, recordKey, ‘sku_key’, stockKey, ‘a(chǎn)mount’, deductAmount, ‘time’, redis.call(‘TIME’)[1]) redis.call(‘PEXPIRE’, recordKey, 86400000) — 24小時過期 return {ok true, new_stock newStock}對應(yīng)的庫存恢復(fù)腳本如訂單取消時調(diào)用— KEYS[1]: 流水記錄key local recordKey KEYS[1] local record redis.call(‘HGETALL’, recordKey) if #record 0 then return {err “record not found or expired”} end — 解析記錄 local skuKey, amount for i 1, #record, 2 do if record[i] ‘sku_key’ then skuKey record[i1] elseif record[i] ‘a(chǎn)mount’ then amount tonumber(record[i1]) end end if skuKey and amount then redis.call(‘INCRBY’, skuKey, amount) redis.call(‘DEL’, recordKey) return {ok true} else return {err “invalid record format”} end7. 集群環(huán)境下的特殊考量在Redis Cluster中使用Lua腳本除了前述的KEYS規(guī)范還有更多細(xì)節(jié)。7.1 多鍵操作與哈希標(biāo)簽Hash TagRedis Cluster要求一個命令包括腳本中的所有鍵必須位于同一個哈希槽slot。如果你需要對多個鍵進(jìn)行原子操作而這些鍵天然不在同一個槽怎么辦這時可以使用哈希標(biāo)簽。哈希標(biāo)簽是指鍵名中{}包圍的部分集群在計(jì)算slot時只使用這部分。例如user:{1000}:profile和user:{1000}:orders盡管鍵名不同但因?yàn)楣?biāo)簽都是1000它們會被分配到同一個slot。你可以在腳本中操作它們。但務(wù)必謹(jǐn)慎使用濫用哈希標(biāo)簽會導(dǎo)致數(shù)據(jù)分布不均某些節(jié)點(diǎn)負(fù)載過重。7.2 跨節(jié)點(diǎn)腳本的替代方案有時原子性的多鍵操作確實(shí)需要涉及不同節(jié)點(diǎn)。此時Lua腳本無法直接實(shí)現(xiàn)。常見的替代方案是使用兩階段提交2PC或Saga事務(wù)模式但這會引入復(fù)雜性并削弱一致性。另一種思路是重新設(shè)計(jì)數(shù)據(jù)模型看看能否將要一起操作的數(shù)據(jù)聚合到同一個鍵里比如使用Hash或Sorted Set結(jié)構(gòu)。這往往是從根本上更優(yōu)的解決方案。8. 我踩過的坑與血淚經(jīng)驗(yàn)最后分享幾個只有踩過才知道的坑?？?數(shù)字精度丟失。如前所述Lua的number是雙精度浮點(diǎn)。一個經(jīng)典的場景是操作金融余額以分為單位。如果你在Lua中計(jì)算local balance 100.01 – 0.01在極少數(shù)情況下由于浮點(diǎn)誤差結(jié)果可能不是精確的100.00。對于精確計(jì)算要么在客戶端用高精度庫算好再傳要么在Redis中全部用字符串存儲在Lua中用字符串操作或者使用Redis的INCRBYFLOAT命令它本身也是浮點(diǎn)但由Redis處理?？?腳本中的隨機(jī)數(shù)。Lua的math.random()在同一個Redis實(shí)例內(nèi)每次執(zhí)行腳本時如果種子不變生成的隨機(jī)序列是確定的。這破壞了腳本的“純函數(shù)”性可能會影響復(fù)制和AOF。如果確實(shí)需要不可預(yù)測的隨機(jī)性可以從ARGV傳入一個隨機(jī)種子或者使用redis.call(‘TIME’)的微秒部分作為隨機(jī)源?？?redis.call()的錯誤處理不夠直觀。比如redis.call(‘HGET’, ‘non_exist_hash’, ‘field’)返回的是nil在Lua中是false而不是一個錯誤。而redis.call(‘GET’, ‘non_exist_key’)也返回nil。但redis.call(‘HGETALL’, ‘non_exist_hash’)返回的是空表{}。你需要熟悉每個命令在鍵不存在時的返回行為并在腳本中做健壯的判空處理。坑4腳本的“副作用”與只讀腳本。即使你的腳本只包含GET等讀命令它依然會阻塞其他命令。對于復(fù)雜的只讀腳本可以考慮使用Redis的READONLY命令需要在腳本中調(diào)用redis.set_repl(redis.REPL_NONE)不READONLY是一個獨(dú)立的命令但更根本的是優(yōu)化腳本性能。另外在集群只讀副本上執(zhí)行腳本需要確保腳本確實(shí)是只讀的否則會報(bào)錯。掌握Lua腳本是你從Redis“用戶”進(jìn)階為“玩家”的關(guān)鍵一步。它賦予了Redis更強(qiáng)的能力但也帶來了更大的責(zé)任。始終記住原子性不等于性能能力越大阻塞的風(fēng)險也越大。在享受它帶來的便利時務(wù)必通過嚴(yán)謹(jǐn)?shù)臏y試、充分的監(jiān)控和清晰的設(shè)計(jì)來駕馭它。