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