深度拆解：從原子性真相到秒殺場(chǎng)景實(shí)戰(zhàn))
1. 我為什么專門(mén)寫(xiě)一篇Redis事務(wù)的文章先拋一個(gè)觀點(diǎn)Redis事務(wù)可能是整個(gè)Redis生態(tài)里“被誤解最深”的一個(gè)特性。很多人面試前背了幾條命令知道MULTI、EXEC、DISCARD、WATCH這幾個(gè)單詞但真正被問(wèn)到“Redis事務(wù)能保證原子性嗎”的時(shí)候往往答不到點(diǎn)子上更別提實(shí)際項(xiàng)目里用Redis事務(wù)解決具體問(wèn)題了。我寫(xiě)這篇東西的動(dòng)機(jī)很簡(jiǎn)單最近在幫團(tuán)隊(duì)做緩存一致性治理順手把幾個(gè)訂單場(chǎng)景的分布式事務(wù)方案重新捋了一遍發(fā)現(xiàn)Redis事務(wù)在一部分場(chǎng)景下其實(shí)是比分布式鎖更輕量的選擇。但前提是你得真正理解它的邊界哪些它能做哪些它絕對(duì)做不了。這篇文章不打算給你畫(huà)大餅也不打算把官方文檔翻譯一遍而是把我自己從踩坑、看源碼、做壓測(cè)里總結(jié)出來(lái)的東西講明白。內(nèi)容從基礎(chǔ)命令開(kāi)始逐步到本質(zhì)分析、實(shí)際場(chǎng)景、常見(jiàn)面試追問(wèn)最后是一份可以直接抄的實(shí)操清單。適合三類(lèi)人看準(zhǔn)備面試的Java/PHP/Go后端開(kāi)發(fā)正在做緩存與數(shù)據(jù)庫(kù)一致性設(shè)計(jì)的架構(gòu)師以及那些被“Redis事務(wù)就是個(gè)雞肋”這種論調(diào)誤導(dǎo)過(guò)的朋友?？赐昴銘?yīng)該能回答清楚Redis事務(wù)是不是事務(wù)它和MySQL事務(wù)的差別到底在哪里哪些業(yè)務(wù)場(chǎng)景真的應(yīng)該用它2. 從命令層面理解Redis事務(wù)的完整執(zhí)行流程2.1 四條核心命令的職責(zé)劃分Redis事務(wù)相關(guān)的命令一共就五條最常用的是前四條MULTI開(kāi)啟事務(wù)標(biāo)記當(dāng)前連接進(jìn)入事務(wù)狀態(tài)EXEC執(zhí)行事務(wù)隊(duì)列中的所有命令DISCARD取消事務(wù)清空命令隊(duì)列WATCH樂(lè)觀鎖監(jiān)視一個(gè)或多個(gè)key在EXEC之前key被修改則事務(wù)被中斷有一個(gè)很容易被忽略但非常關(guān)鍵的命令UNWATCH用于取消所有WATCH監(jiān)聽(tīng)。一個(gè)典型的事務(wù)執(zhí)行流程是這樣的 MULTI OK SET order:1001 status paid QUEUED INCR order_count QUEUED EXEC 1) OK 2) (integer) 101這里有個(gè)細(xì)節(jié)值得注意從MULTI開(kāi)始所有的命令都不會(huì)立即執(zhí)行而是進(jìn)入一個(gè)隊(duì)列每個(gè)命令返回QUEUED。直到EXEC被調(diào)用Redis才會(huì)按順序、一次性執(zhí)行隊(duì)列里的所有命令。這個(gè)“排隊(duì)”機(jī)制是理解Redis事務(wù)的起點(diǎn)也是和MySQL事務(wù)最大的分水嶺MySQL事務(wù)里的每條SQL在執(zhí)行時(shí)就會(huì)加鎖、修改undo日志而Redis事務(wù)里命令真正執(zhí)行的時(shí)刻被推遲到了EXEC。2.2 事務(wù)執(zhí)行的三階段拆解官方對(duì)Redis事務(wù)的定義是三階段事務(wù)開(kāi)始MULTI命令把連接上下文標(biāo)記為事務(wù)狀態(tài)命令入隊(duì)后續(xù)命令全部進(jìn)入隊(duì)列此時(shí)服務(wù)端只做語(yǔ)法檢查不執(zhí)行業(yè)務(wù)邏輯執(zhí)行事務(wù)EXEC被調(diào)用后服務(wù)端按先進(jìn)先出的順序逐個(gè)執(zhí)行隊(duì)列里的命令第一階段和第三階段很好理解重點(diǎn)說(shuō)第二階段。命令入隊(duì)時(shí)Redis只做兩類(lèi)檢查命令是否存在、參數(shù)個(gè)數(shù)是否正確。至于key存不存在、類(lèi)型對(duì)不對(duì)、命令執(zhí)行會(huì)不會(huì)報(bào)錯(cuò)全部留到EXEC階段才會(huì)暴露出來(lái)。這個(gè)特性導(dǎo)致了Redis事務(wù)里一個(gè)著名的坑如果某個(gè)命令在入隊(duì)時(shí)沒(méi)有語(yǔ)法錯(cuò)誤但在執(zhí)行時(shí)發(fā)現(xiàn)操作了錯(cuò)誤類(lèi)型的數(shù)據(jù)結(jié)構(gòu)它不會(huì)影響其他命令的正常執(zhí)行。我可以給你演示這個(gè)場(chǎng)景 MULTI OK SET name zhangsan QUEUED LPUSH name list-data QUEUED INCR age QUEUED EXEC 1) OK 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 3) (integer) 1看到?jīng)]有LPUSH執(zhí)行失敗了但SET和INCR照樣執(zhí)行成功。這說(shuō)明Redis事務(wù)不具備回滾機(jī)制更沒(méi)有“要么全成功、要么全失敗”的原子性保障。這一點(diǎn)必須刻在腦子里面試問(wèn)“Redis事務(wù)滿足原子性嗎”正確答案是不滿足傳統(tǒng)意義上的原子性它只保證執(zhí)行過(guò)程的隔離性以及命令序列的批量執(zhí)行。3. 深度拆解Redis事務(wù)的本質(zhì)它到底是什么不是什么3.1 原子性的真相沒(méi)有回滾只有中斷MySQL事務(wù)失敗時(shí)可以ROLLBACK把數(shù)據(jù)恢復(fù)到事務(wù)開(kāi)始前的狀態(tài)。Redis事務(wù)呢它把所有命令執(zhí)行完之后根本沒(méi)有undo log沒(méi)有MVCC沒(méi)有回滾段。如果執(zhí)行過(guò)程中某條命令報(bào)錯(cuò)Redis會(huì)繼續(xù)執(zhí)行后面的命令已經(jīng)執(zhí)行成功的命令不會(huì)被撤銷(xiāo)。那事務(wù)里主動(dòng)判斷邏輯錯(cuò)誤怎么辦比如兩個(gè)命令之間有依賴關(guān)系前面命令成功了才允許后面命令執(zhí)行。Redis給出的是DISCARD命令——但這個(gè)DISCARD只能在你還沒(méi)EXEC的時(shí)候手動(dòng)調(diào)用用來(lái)放棄整個(gè)隊(duì)列一旦進(jìn)入EXEC你就不可能干預(yù)執(zhí)行過(guò)程無(wú)法在中間某條命令出錯(cuò)時(shí)讓后面的命令停止執(zhí)行。用一句話總結(jié)Redis事務(wù)只有“執(zhí)行前的中斷”沒(méi)有“執(zhí)行后的回滾”。WATCH機(jī)制本質(zhì)上也是在EXEC之前依靠key的版本變化來(lái)中斷事務(wù)而不是在執(zhí)行之后去恢復(fù)現(xiàn)場(chǎng)。理解了這一點(diǎn)你才算摸到了Redis事務(wù)的真正邊界。3.2 隔離性真相單線程模型下的天然串行Redis是單線程模型所有命令都是串行執(zhí)行的。這帶來(lái)一個(gè)直接結(jié)論在EXEC執(zhí)行期間不會(huì)有其他客戶端的命令插入進(jìn)來(lái)。所以Redis事務(wù)的隔離性其實(shí)是“單線程串行”帶來(lái)的副產(chǎn)品不需要復(fù)雜的鎖機(jī)制也不需要MVCC。但這個(gè)隔離性有個(gè)前提只針對(duì)Redis自身。事務(wù)執(zhí)行期間如果有其他客戶端向同一個(gè)key發(fā)起了寫(xiě)操作那這個(gè)寫(xiě)操作是等EXEC整體執(zhí)行完才會(huì)被處理還是可能在事務(wù)執(zhí)行過(guò)程中的某個(gè)間隙被插入答案是沒(méi)有間隙。Redis服務(wù)端在處理EXEC時(shí)會(huì)一次性把隊(duì)列里所有命令順序執(zhí)行完畢中間不會(huì)去處理網(wǎng)絡(luò)上的新請(qǐng)求。這是Redis事務(wù)隔離性的核心保證也解釋了為什么WATCH需要在事務(wù)之外單獨(dú)工作——它是在EXEC執(zhí)行前對(duì)key進(jìn)行監(jiān)視而不是在事務(wù)執(zhí)行過(guò)程中加鎖。3.3 與MySQL事務(wù)、分布式事務(wù)的邊界對(duì)照為了把Redis事務(wù)的本質(zhì)講透我把它和MySQL事務(wù)、以及外部常見(jiàn)的分布式事務(wù)方案做了一張對(duì)照表維度MySQL事務(wù)Redis事務(wù)分布式事務(wù)如2PC/TCC原子性支持回滾保證全成或全敗不保證某條命令失敗不影響其他命令通過(guò)協(xié)調(diào)者與參與者協(xié)議保證隔離性支持四種隔離級(jí)別間隙鎖、行鎖單線程串行天然隔離需要分布式鎖或額外隔離機(jī)制持久性依賴redo log可配置依賴AOF/RDB受持久化配置影響依賴各參與節(jié)點(diǎn)的持久化能力適用場(chǎng)景強(qiáng)一致、結(jié)構(gòu)化數(shù)據(jù)、復(fù)雜關(guān)聯(lián)操作輕量級(jí)、低延遲、操作簡(jiǎn)單的緩存或計(jì)數(shù)場(chǎng)景跨庫(kù)、跨服務(wù)的強(qiáng)一致業(yè)務(wù)性能成本鎖競(jìng)爭(zhēng)、日志刷盤(pán)開(kāi)銷(xiāo)明顯無(wú)鎖開(kāi)銷(xiāo)批量執(zhí)行極快網(wǎng)絡(luò)交互多性能損耗大看完這張表你應(yīng)該明白R(shí)edis事務(wù)不是一個(gè)“弱化版MySQL事務(wù)”而是一個(gè)設(shè)計(jì)目標(biāo)完全不同的機(jī)制。它犧牲了原子性和持久性換來(lái)了極致的性能與簡(jiǎn)潔的執(zhí)行模型。所以與其糾結(jié)“Redis事務(wù)能不能替代MySQL事務(wù)”不如問(wèn)自己我的場(chǎng)景需要回滾嗎需要跨多個(gè)key保證數(shù)據(jù)強(qiáng)一致嗎如果答案是需要那Redis事務(wù)不是你的菜如果只是需要“一次性執(zhí)行一串命令并且不想被其他客戶端的操作插隊(duì)”那它可能正好夠用。3.4 Redis事務(wù)寫(xiě)操作的底層實(shí)現(xiàn)細(xì)節(jié)Redis事務(wù)之所以能“排隊(duì)”靠的是客戶端狀態(tài)機(jī)。在Redis源碼里每個(gè)redisClient結(jié)構(gòu)體較新版本為client有一個(gè)flags字段其中包含了CLIENT_MULTI標(biāo)志位。當(dāng)客戶端發(fā)送MULTI時(shí)服務(wù)端把這個(gè)標(biāo)志位置為1之后的每條命令服務(wù)端會(huì)調(diào)用queueMultiCommand方法把命令追加到一個(gè)鏈表形式的c-mstate.commands數(shù)組里。有個(gè)很體現(xiàn)設(shè)計(jì)精妙的地方命令入隊(duì)時(shí)Redis會(huì)提前解析命令參數(shù)并檢查命令合法性這樣EXEC執(zhí)行的時(shí)候就不需要重復(fù)解析命令了。這個(gè)優(yōu)化讓事務(wù)的執(zhí)行速度非?？煲彩撬茉诟咝阅軋?chǎng)景下被廣泛使用的基礎(chǔ)。我當(dāng)年在看源碼時(shí)注意到一個(gè)有意思的細(xì)節(jié)MULTI之后如果執(zhí)行DISCARD服務(wù)端會(huì)清空mstate里的命令隊(duì)列并釋放相關(guān)內(nèi)存此時(shí)如果之前設(shè)置過(guò)WATCH事務(wù)中斷后WATCH還在生效嗎答案是WATCH會(huì)被保留除非你顯式調(diào)用UNWATCH。這是很多人忽略的細(xì)節(jié)容易導(dǎo)致后續(xù)事務(wù)被意外中斷。4. 實(shí)際應(yīng)用場(chǎng)景Redis事務(wù)真正能解決的問(wèn)題4.1 場(chǎng)景一秒殺和庫(kù)存扣減事務(wù)比分布式鎖更優(yōu)雅很多人提到庫(kù)存扣減第一時(shí)間想到分布式鎖但分布式鎖有鎖的獲取、釋放、超時(shí)、重入等一堆問(wèn)題而且在高并發(fā)下性能開(kāi)銷(xiāo)不小。如果只涉及單key的原子扣減根本不需要鎖用INCR/DECR這種原子操作就夠了但如果涉及多key的一致性比如“扣減庫(kù)存生成訂單號(hào)記錄操作日志”這三個(gè)步驟需要一起完成且不允許被其他線程插隊(duì)Redis事務(wù)就是非常合適的選手。舉個(gè)例子秒殺場(chǎng)景里的典型操作WATCH stock:sku001 MULTI DECR stock:sku001 INCR order:total LPUSH order:list user:1001 EXEC在WATCH的幫助下如果事務(wù)執(zhí)行前stock:sku001被其他請(qǐng)求修改了EXEC會(huì)返回nil而不是執(zhí)行隊(duì)列里的命令從而避免超賣(mài)。這套邏輯比分布式鎖輕量不需要引入額外組件也不需要考慮鎖超時(shí)續(xù)期問(wèn)題在單Redis實(shí)例場(chǎng)景下是一個(gè)極其高效的方案。這里我必須強(qiáng)調(diào)一個(gè)前提上面這個(gè)方案要求所有操作都命中同一個(gè)Redis實(shí)例。如果你用的是Redis Cluster多個(gè)key不在同一個(gè)slot上事務(wù)就會(huì)報(bào)CROSSSLOT錯(cuò)誤。解決辦法是使用Hash Tag比如把key設(shè)計(jì)成{stock:sku001}:stock、{stock:sku001}:order讓它們落在同一個(gè)slot中。4.2 場(chǎng)景二批量命令執(zhí)行減少網(wǎng)絡(luò)往返Redis事務(wù)的另一個(gè)天然優(yōu)勢(shì)是減少RTT往返時(shí)延。假設(shè)你要執(zhí)行五條命令正常逐條執(zhí)行需要5個(gè)網(wǎng)絡(luò)往返而用事務(wù)封裝后只需要2個(gè)往返MULTI一個(gè)EXEC一個(gè)。在局域網(wǎng)環(huán)境下可能差別不明顯但在跨機(jī)房、跨云的場(chǎng)景下每條命令的RTT可能達(dá)到幾十毫秒這時(shí)事務(wù)的性能優(yōu)勢(shì)就會(huì)被放大。我在實(shí)際項(xiàng)目里做過(guò)一次優(yōu)化某個(gè)接口需要同時(shí)更新用戶的積分、等級(jí)、最近活躍時(shí)間原來(lái)是用Pipeline后來(lái)因?yàn)樾枰ＷC這批操作不被其他命令插隊(duì)改成了事務(wù)。最終效果是接口耗時(shí)降低了近四成而且因?yàn)槭聞?wù)是串行執(zhí)行的省去了Pipeline模式下回包順序的顧慮。4.3 場(chǎng)景三Redis做中間件時(shí)的命令編排比如延遲隊(duì)列和限流現(xiàn)在很多團(tuán)隊(duì)把Redis當(dāng)作輕量中間件使用比如用ZSet實(shí)現(xiàn)延遲隊(duì)列、用Lua腳本實(shí)現(xiàn)令牌桶限流。在這些場(chǎng)景里Redis事務(wù)可以作為保證多命令一致性的基線方案。比如延遲隊(duì)列的消費(fèi)邏輯從ZSet取出到期的任務(wù)記錄到執(zhí)行日志中從ZSet刪除該任務(wù)這三個(gè)動(dòng)作如果分步執(zhí)行在并發(fā)消費(fèi)時(shí)可能出現(xiàn)同一個(gè)任務(wù)被多個(gè)消費(fèi)者拿到用事務(wù)把ZRANGEBYSCORE、LPUSH、ZREM包在一起配合WATCH能夠顯著降低重復(fù)消費(fèi)的概率。不過(guò)要提醒一句如果業(yè)務(wù)邏輯比較復(fù)雜或者條件判斷比較多我通常建議優(yōu)先考慮Lua腳本。因?yàn)長(zhǎng)ua腳本在Redis里是原子執(zhí)行的不僅支持條件邏輯還能在腳本內(nèi)做控制流判斷比事務(wù)更靈活。你可以理解為事務(wù)是“一串無(wú)腦執(zhí)行的命令隊(duì)列”Lua腳本是“帶邏輯判斷的原子執(zhí)行塊”。等會(huì)兒在面試題部分我會(huì)再展開(kāi)這兩者的對(duì)比。4.4 場(chǎng)景四非強(qiáng)一致場(chǎng)景下的訂單與庫(kù)存狀態(tài)更新熱搜詞里有“訂單與庫(kù)存分布式事務(wù)”很多文章動(dòng)輒就上Seata、RocketMQ事務(wù)消息但說(shuō)實(shí)話對(duì)于規(guī)模不大、允許秒級(jí)最終一致的業(yè)務(wù)Redis事務(wù)完全可以作為輕量方案。舉一個(gè)實(shí)際的電商例子用戶下單后需要扣減庫(kù)存、更新訂單狀態(tài)、寫(xiě)一條待支付消息到延遲隊(duì)列。如果這些操作分散在MySQL和Redis中就會(huì)面臨分布式事務(wù)難題。一種討巧的設(shè)計(jì)是把訂單狀態(tài)和庫(kù)存狀態(tài)都維護(hù)在Redis中作為熱點(diǎn)數(shù)據(jù)的緩存或預(yù)扣存儲(chǔ)通過(guò)Redis事務(wù)保證這三個(gè)key的更新原子執(zhí)行之后再由異步任務(wù)把Redis結(jié)果同步到MySQL。在這個(gè)設(shè)計(jì)中Redis事務(wù)承擔(dān)了“短暫期間的強(qiáng)一致”職責(zé)避免了在支付前窗口出現(xiàn)超賣(mài)或狀態(tài)不一致。當(dāng)然如果MySQL已經(jīng)是最終數(shù)據(jù)源且Redis只做緩存那需要考慮緩存與數(shù)據(jù)庫(kù)的雙寫(xiě)一致性這種情況Redis事務(wù)解決不了需要用其他策略比如延遲雙刪、Binlog訂閱同步等。別把工具用錯(cuò)地方。5. 實(shí)操落地完整可復(fù)現(xiàn)的Redis事務(wù)代碼示例5.1 環(huán)境準(zhǔn)備本地快速搭建Redis無(wú)論你是Windows還是macOS先確保有一個(gè)可以連的Redis實(shí)例。Windows上最簡(jiǎn)單的方式是用memurai或者官方的redis-windows分支這些現(xiàn)在都支持Windows原生運(yùn)行不一定要用WSLmacOS用戶直接用Homebrewbrew install redis redis-server /usr/local/etc/redis.conf基礎(chǔ)安裝配置完成后我建議先用redis-cli把今天講的事務(wù)命令各跑一遍養(yǎng)成肌肉記憶。比如redis-cli MULTI SET user:001:score 90 INCR user:001:score EXEC如果返回結(jié)果里第二項(xiàng)是(integer) 91說(shuō)明你的環(huán)境沒(méi)問(wèn)題可以繼續(xù)后面的代碼。5.2 Python實(shí)操庫(kù)存扣減的完整事務(wù)函數(shù)我用Pythonredis-py寫(xiě)一個(gè)庫(kù)存扣減的示例這是生產(chǎn)環(huán)境里最典型的用法import redis client redis.Redis(host127.0.0.1, port6379, decode_responsesTrue) STOCK_KEY stock:sku001 ORDER_KEY order:total LIST_KEY order:list def stock_deduct_with_transaction(user_id: str): while True: try: # 1. 開(kāi)啟WATCH監(jiān)視庫(kù)存key client.watch(STOCK_KEY) # 2. 讀取當(dāng)前庫(kù)存 stock int(client.get(STOCK_KEY) or 0) if stock 0: client.unwatch() return False # 3. 開(kāi)啟事務(wù)執(zhí)行扣減和記錄 pipe client.pipeline(transactionTrue) pipe.decr(STOCK_KEY) pipe.incr(ORDER_KEY) pipe.lpush(LIST_KEY, f{user_id}:{stock}) # 4. 執(zhí)行事務(wù)這里在redis-py里會(huì)調(diào)用EXEC pipe.execute() return True except redis.WatchError: # 如果WATCH的key在事務(wù)執(zhí)行前被修改會(huì)拋出WatchError # 最簡(jiǎn)單的策略是重試或者記錄沖突次數(shù)后重試 continue這段代碼里有幾個(gè)細(xì)節(jié)值得說(shuō)明。第一watch()必須在pipeline(transactionTrue)之前調(diào)用否則監(jiān)視不生效。第二get之后到execute之間如果另一個(gè)客戶端修改了STOCK_KEY服務(wù)端會(huì)讓本次EXEC返回空redis-py會(huì)拋出WatchError我們捕獲后重試即可。第三返回的stock是事務(wù)開(kāi)始前讀到的值用在了日志記錄里這保證了日志里的庫(kù)存和扣減前的庫(kù)存是一致的。實(shí)際壓測(cè)過(guò)這個(gè)函數(shù)在普通筆記本上可以跑到每秒數(shù)萬(wàn)次遠(yuǎn)高于分布式鎖方案的吞吐量。當(dāng)然這是單實(shí)例、無(wú)持久化壓力的前提生產(chǎn)環(huán)境還要看網(wǎng)絡(luò)和AOF策略。5.3 Java實(shí)操使用Spring Data Redis操作事務(wù)服務(wù)端開(kāi)發(fā)里Java占有率很高我再給一個(gè)Spring Data Redis的寫(xiě)法。注意Spring Data Redis操作事務(wù)需要把連接綁定到線程否則多個(gè)方法拿到的不是同一個(gè)連接。先寫(xiě)一個(gè)簡(jiǎn)單的Service方法Service public class OrderService { Autowired private StringRedisTemplate stringRedisTemplate; public boolean createOrderWithRedisTx(String userId, String skuId) { return stringRedisTemplate.execute(new SessionCallbackListObject() { Override public ListObject execute(Nonnull RedisOperations operations) throws DataAccessException { operations.watch(stock: skuId); Integer stock Integer.valueOf(operations.opsForValue().get(stock: skuId)); if (stock 0) { operations.unwatch(); return null; } operations.multi(); operations.opsForValue().decrement(stock: skuId); operations.opsForValue().increment(order:total); operations.opsForList().leftPush(order:list, userId : skuId); return operations.exec(); } }); } }用SessionCallback的好處是整個(gè)回調(diào)在同一個(gè)Redis連接里執(zhí)行multi()和exec()天然配對(duì)。如果WATCH的key被修改exec()返回null你可以據(jù)此判斷是否要重試。有一點(diǎn)需要特別注意StringRedisTemplate的序列化器默認(rèn)是StringRedisSerializer如果你用RedisTemplate且設(shè)置了其他序列化器要保證key的序列化方式一致否則watch和后續(xù)get操作的key可能映射到不同的字節(jié)數(shù)組導(dǎo)致監(jiān)視失效。這是我在項(xiàng)目里踩過(guò)的真實(shí)坑當(dāng)時(shí)排查了半天最后發(fā)現(xiàn)是key的序列化前綴不一致。5.4 Go實(shí)操使用go-redis實(shí)現(xiàn)事務(wù)控制Go生態(tài)里go-redis對(duì)事務(wù)的支持也很完善核心是用TxPipeline。import ( context github.com/redis/go-redis/v9 ) func DeductStock(ctx context.Context, rdb *redis.Client, userID, skuID string) (bool, error) { stockKey : stock: skuID for { // 使用TxPipeline先WATCH然后排隊(duì)執(zhí)行 tx : rdb.TxPipeline() pipe : func(p redis.Pipeliner) error { // 在pipeline里沒(méi)法直接watch需要先單獨(dú)watch return nil } _ pipe // 更清晰的方式使用Watch方法 err : rdb.Watch(ctx, func(tx *redis.Tx) error { stock, err : tx.Get(ctx, stockKey).Int() if err ! nil { return err } if stock 0 { return redis.ErrOutOfStock // 自定義錯(cuò)誤 } _, err tx.TxPipelined(ctx, func(p redis.Pipeliner) error { p.Decr(ctx, stockKey) p.Incr(ctx, order:total) p.LPush(ctx, order:list, userID:skuID) return nil }) return err }, stockKey) if err nil { return true, nil } if err redis.TxFailedErr { // 說(shuō)明事務(wù)被其他客戶端中斷重試 continue } return false, err } }這段代碼和上面的Python版思路一模一樣。rdb.Watch的回調(diào)參數(shù)*redis.Tx就是一個(gè)已監(jiān)視指定key的事務(wù)對(duì)象?；卣{(diào)內(nèi)部用TxPipelined把多個(gè)命令打包然后由go-redis自動(dòng)發(fā)送MULTI/EXEC。實(shí)現(xiàn)上TxPipelined內(nèi)部會(huì)調(diào)用tx.Multi()之后執(zhí)行Exec()。如果在Watch階段發(fā)現(xiàn)key被改返回TxFailedErr這時(shí)候重試即可。我自己的體會(huì)是Go版寫(xiě)起來(lái)最順手因?yàn)樗鸦卣{(diào)、錯(cuò)誤處理和重試邏輯組織得很緊湊適合服務(wù)端高并發(fā)環(huán)境。6. 事務(wù)與Lua腳本、Pipeline的選型對(duì)比6.1 為什么說(shuō)Lua腳本是事務(wù)的進(jìn)階替代品很多人在面試中被問(wèn)到“Redis事務(wù)和Lua腳本有什么區(qū)別”時(shí)會(huì)卡住。我的理解可以濃縮為一句話事務(wù)是把一堆命令打包執(zhí)行Lua腳本是把一堆邏輯打包原子執(zhí)行。區(qū)別體現(xiàn)在兩個(gè)方面。第一事務(wù)命令在執(zhí)行時(shí)不能做條件判斷每個(gè)命令都是“提前定好”的Lua腳本可以在內(nèi)部讀寫(xiě)Redis數(shù)據(jù)并且根據(jù)結(jié)果決定后續(xù)步驟靈活性高得多。第二事務(wù)執(zhí)行過(guò)程中某條命令失敗的后續(xù)行為是“繼續(xù)執(zhí)行其他命令”Lua腳本如果在執(zhí)行過(guò)程中報(bào)錯(cuò)整個(gè)腳本會(huì)終止并回滾已執(zhí)行的寫(xiě)操作其實(shí)是單線程運(yùn)行導(dǎo)致后續(xù)命令未被執(zhí)行看起來(lái)更符合“原子性”直覺(jué)。舉一個(gè)具體例子我們想要“只有在庫(kù)存大于0時(shí)才扣減”。用事務(wù)做你必須在外部先GET庫(kù)存然后判斷再M(fèi)ULTI、DECR用Lua做local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return -1 end redis.call(DECR, KEYS[1]) redis.call(INCR, KEYS[2]) redis.call(LPUSH, KEYS[3], ARGV[1]) return 1這段腳本通過(guò)redis.call(GET, KEYS[1])讀取庫(kù)存在腳本內(nèi)完成條件判斷執(zhí)行一次EVAL就能完成多步操作且整個(gè)過(guò)程因?yàn)镽edis單線程執(zhí)行Lua而不會(huì)被打斷。這個(gè)“條件原子性”是事務(wù)做不到的。因此我的建議是如果事務(wù)隊(duì)列里的命令彼此獨(dú)立、沒(méi)有依賴關(guān)系用事務(wù)就夠了如果有依賴判斷優(yōu)先選Lua腳本。在實(shí)際的高性能生產(chǎn)系統(tǒng)里L(fēng)ua腳本的使用頻率遠(yuǎn)高于事務(wù)原因也在這里。6.2 Pipeline與事務(wù)的異同Pipeline和事務(wù)都能減少網(wǎng)絡(luò)往返不同之處在于Pipeline只是把多條命令一次性發(fā)給服務(wù)端命令之間沒(méi)有原子隔離也沒(méi)有WATCH機(jī)制事務(wù)則要求MULTI/EXEC包裹命令在服務(wù)端排隊(duì)并串行執(zhí)行。有一個(gè)細(xì)節(jié)值得注意在Pipeline里加MULTI/EXEC就變成了“Pipeline 事務(wù)”。很多客戶端庫(kù)的pipeline(transactionTrue)就是這個(gè)原理。如果你只需要批量操作且允許中間被其他客戶端插入用純Pipeline性能可能略高少了事務(wù)狀態(tài)機(jī)的開(kāi)銷(xiāo)如果你需要“不可插隊(duì)”的語(yǔ)義那就用事務(wù)。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 為什么我用了事務(wù)并發(fā)時(shí)數(shù)據(jù)還是錯(cuò)了這是我在技術(shù)群里被問(wèn)得最多的問(wèn)題?？赐昵懊娴姆治瞿銘?yīng)該有感覺(jué)了八成是因?yàn)闆](méi)加WATCH或者WATCH的key不對(duì)。事務(wù)只能保證隊(duì)列內(nèi)的命令不被其他請(qǐng)求插隊(duì)但如果你在MULTI之前用GET讀了值在MULTI之后根據(jù)這個(gè)值做DECR那么這個(gè)“讀到的值”在MULTI到EXEC之間可能已經(jīng)過(guò)期了。正確做法是先WATCH目標(biāo)key再GET再M(fèi)ULTI、EXEC這樣當(dāng)key在期間被修改時(shí)EXEC會(huì)返回nil。簡(jiǎn)單來(lái)說(shuō)事務(wù)給不了你“Read Your Write”的快照隔離WATCH才是樂(lè)觀鎖的核心。我見(jiàn)過(guò)不少初學(xué)者用事務(wù)做樂(lè)觀鎖但忘了WATCH最后高并發(fā)下出現(xiàn)超賣(mài)又反過(guò)來(lái)怪Redis事務(wù)設(shè)計(jì)不行。工具本身沒(méi)有問(wèn)題問(wèn)題是使用姿勢(shì)不對(duì)。7.2 事務(wù)里的命令為什么返回QUEUED然后什么都不執(zhí)行這種情況通常是你在一個(gè)已經(jīng)處于事務(wù)狀態(tài)的連接里又發(fā)送了MULTI或者因?yàn)楫惓Ｍ顺鰧?dǎo)致連接處于懸掛狀態(tài)。解決方案很簡(jiǎn)單發(fā)送DISCARD重置連接狀態(tài)或者直接重連。還有一次我在Java里遇到了詭異的“事務(wù)里只有一部分命令執(zhí)行了”查了半天發(fā)現(xiàn)是連接池中的redisTemplate被其他線程復(fù)用事務(wù)命令被分散到了多個(gè)連接上。所以說(shuō)用Spring Data Redis操作事務(wù)務(wù)必使用SessionCallback就是這個(gè)原因。另一個(gè)常見(jiàn)情況Redis Cluster下事務(wù)執(zhí)行報(bào)CROSSSLOT錯(cuò)誤。這是cluster模式對(duì)多key操作的天然限制。解決辦法是把相關(guān)key規(guī)劃到同一個(gè)hash slot中或者改用Lua腳本Lua腳本同樣受slot限制但可以通過(guò)Hash Tag解決。7.3 Redis事務(wù)能不能解決緩存一致性我再?gòu)?qiáng)調(diào)一遍不能。Redis事務(wù)解決的是“多個(gè)Redis命令之間的原子執(zhí)行與隔離”不是“Redis與MySQL之間的數(shù)據(jù)一致性”。如果你緩存里放了數(shù)據(jù)庫(kù)的快照然后通過(guò)事務(wù)更新了多個(gè)緩存key這只能保證緩存內(nèi)部一致無(wú)法保證緩存和數(shù)據(jù)庫(kù)一致。熱點(diǎn)搜索詞里的“訂單與庫(kù)存分布式事務(wù)”如果要徹底解決跨Redis和MySQL的一致性問(wèn)題要么用可靠消息要么用本地消息表要么用Seata等方案而不是指望用Redis事務(wù)做完一切。我自己的一個(gè)項(xiàng)目實(shí)施原則是“跨數(shù)據(jù)源的問(wèn)題不要在單一數(shù)據(jù)源內(nèi)部求解”否則只會(huì)制造出更復(fù)雜的臟讀、延遲和補(bǔ)償邏輯。7.4 事務(wù)執(zhí)行期間AOF刷盤(pán)問(wèn)題會(huì)影響一致性嗎很多人問(wèn)Redis事務(wù)執(zhí)行完了但AOF沒(méi)刷盤(pán)進(jìn)程崩潰了事務(wù)結(jié)果會(huì)不會(huì)丟這個(gè)問(wèn)題的本質(zhì)是Redis持久化的配置策略和其他寫(xiě)操作一樣。默認(rèn)appendfsync everysec下AOF最多丟一秒數(shù)據(jù)。事務(wù)不會(huì)額外保證持久性也不提供比普通命令更高的持久化語(yǔ)義。如果你的業(yè)務(wù)對(duì)數(shù)據(jù)安全要求高需要結(jié)合Redis主從集群、AOF刷盤(pán)策略、哨兵/Cluster的故障切換機(jī)制來(lái)綜合設(shè)計(jì)。7.5 為什么我的WATCH一執(zhí)行EXEC就返回nil有幾種可能WATCH的key確實(shí)在事務(wù)執(zhí)行前被修改了最常見(jiàn)同一個(gè)連接多次使用WATCH且key被改動(dòng)后沒(méi)有UNWATCH使用了Clusterkey的監(jiān)視在不同的節(jié)點(diǎn)上Cluster模式不支持跨slot的WATCH客戶端庫(kù)在multi()之前自動(dòng)發(fā)送了watch()和你的顯式watch產(chǎn)生沖突排查辦法很簡(jiǎn)單在WATCH之后、MULTI之前用CLIENT LIST看連接狀態(tài)或者在命令之間加GET確認(rèn)key的版本。實(shí)在不行先UNWATCH再重新WATCH。8. 面試題深度回答模板你能拿分的三個(gè)層次關(guān)于Redis事務(wù)的面試題網(wǎng)上隨便一翻就是一大把。我見(jiàn)過(guò)很多候選人背答案但真正能拿到高分的是能夠區(qū)分層次回答的人。這里給出一套我自己的答題框架。第一層基礎(chǔ)概念層。回答Redis事務(wù)是什么四個(gè)命令的作用執(zhí)行流程三段論。這層最多拿及格分。第二層原理對(duì)比層。主動(dòng)說(shuō)出Redis事務(wù)與MySQL事務(wù)在原子性、隔離性上的本質(zhì)差異舉一個(gè)失效場(chǎng)景說(shuō)明事務(wù)執(zhí)行中命令失敗不會(huì)回滾。這層能體現(xiàn)出你真的用過(guò)而不是只會(huì)背八股。第三層場(chǎng)景與取舍層。結(jié)合項(xiàng)目實(shí)際說(shuō)明什么時(shí)候用Redis事務(wù)什么時(shí)候用Lua腳本什么時(shí)候該用分布式鎖以及Redis Cluster對(duì)多key事務(wù)的限制。如果能順帶講出你在Spring Data Redis里遇到的連接復(fù)用問(wèn)題和解決過(guò)程面試官大概率會(huì)在心里給你加一分。下面我整理了一份面試官高頻追問(wèn)的參考回答追問(wèn)推薦回答方向Redis事務(wù)保證原子性嗎不保證傳統(tǒng)原子性沒(méi)有回滾機(jī)制命令錯(cuò)誤不影響其他命令Redis事務(wù)如何解決并發(fā)競(jìng)爭(zhēng)用WATCH做樂(lè)觀鎖檢測(cè)key在事務(wù)執(zhí)行前是否被修改WATCH和分布式鎖哪個(gè)好場(chǎng)景不同樂(lè)觀鎖適合短操作、沖突不頻繁分布式鎖適合臨界區(qū)需要長(zhǎng)時(shí)間持有的場(chǎng)景MULTI執(zhí)行失敗還能重試嗎可以但要重看業(yè)務(wù)邏輯如果部分命令已執(zhí)行重試前可能需要補(bǔ)償Redis事務(wù)和Lua腳本怎么選無(wú)依賴用事務(wù)有判斷邏輯用LuaLua可腳本內(nèi)條件與循環(huán)控制更精細(xì)Cluster下怎么用事務(wù)用Hash Tag把key約束到同一slot或者放棄事務(wù)改用Lua同樣需同slot9. 我的幾點(diǎn)實(shí)戰(zhàn)心得與小技巧最后分享幾個(gè)書(shū)本之外的體會(huì)。第一生產(chǎn)環(huán)境中我很少單獨(dú)用Redis事務(wù)來(lái)做復(fù)雜的庫(kù)存扣減至于為什么前面已經(jīng)說(shuō)過(guò)了缺少回滾和條件判斷Lua腳本能做得更好。但這并不代表Redis事務(wù)沒(méi)有價(jià)值它在批量操作、輕量級(jí)一致性場(chǎng)景下的簡(jiǎn)潔性和性能優(yōu)勢(shì)非常突出尤其是跨命令的“不可插隊(duì)”能力在計(jì)數(shù)統(tǒng)計(jì)、日志聚合里很實(shí)用。第二幾乎所有主流Redis客戶端庫(kù)對(duì)事務(wù)的支持都已經(jīng)很成熟但引入事務(wù)時(shí)要特別注意連接綁定問(wèn)題。在Spring中務(wù)必使用SessionCallback或RedisTemplate.execute在Python中務(wù)必使用同一個(gè)Pipeline對(duì)象。如果你在事務(wù)里發(fā)現(xiàn)命令時(shí)靈時(shí)不靈先懷疑連接是否被復(fù)用再懷疑key的序列化是否一致這兩個(gè)問(wèn)題占了八成故障原因。第三如果你們團(tuán)隊(duì)已經(jīng)在用Redis Cluster那么多key事務(wù)基本是用不了的。我的替代方案是優(yōu)先用Hash Tag解決slot限制如果業(yè)務(wù)關(guān)系復(fù)雜就改用Lua腳本并在腳本內(nèi)做數(shù)據(jù)校驗(yàn)如果你需要跨多個(gè)Redis分片甚至跨數(shù)據(jù)庫(kù)的強(qiáng)一致坦白說(shuō)Redis事務(wù)就不是正確選項(xiàng)了去研究可靠消息或Seata這類(lèi)方案吧。還有一個(gè)小技巧在壓測(cè)的時(shí)候不要只看吞吐量要關(guān)注事務(wù)的排隊(duì)長(zhǎng)度。當(dāng)你的大量并發(fā)請(qǐng)求都帶著MULTI/EXEC壓向Redis時(shí)單線程串行會(huì)導(dǎo)致命令在隊(duì)列中堆積延遲會(huì)線性上升。所以事務(wù)適合偶爾搶購(gòu)、批量操作這種中低頻場(chǎng)景不適合所有請(qǐng)求都走事務(wù)的超高頻路徑。如果讓我給一條最核心的建議那就是把Redis事務(wù)當(dāng)作一個(gè)“批量執(zhí)行樂(lè)觀鎖”的組合工具而不是當(dāng)作一個(gè)“數(shù)據(jù)庫(kù)事務(wù)”的替代品。調(diào)整了預(yù)期之后你會(huì)發(fā)現(xiàn)它在很多場(chǎng)景里都能用得恰到好處。最后的最后再留一個(gè)擴(kuò)展思考如果你想要在Redis事務(wù)之上做最終一致可以怎么結(jié)合我自己的方向是“事務(wù)Lua異步對(duì)賬”把事務(wù)里的多個(gè)key視為一個(gè)短期狀態(tài)由異步任務(wù)掃描并校驗(yàn)一致性發(fā)現(xiàn)問(wèn)題再補(bǔ)償。這個(gè)思路在很多緩存治理項(xiàng)目里都能落地。后續(xù)如果想聊我可以專門(mén)寫(xiě)一篇“基于Redis實(shí)現(xiàn)輕量級(jí)最終一致性方案”的實(shí)戰(zhàn)文章。 Redis事務(wù)深度拆解：從原子性真相到秒殺場(chǎng)景實(shí)戰(zhàn)
1. 我為什么專門(mén)寫(xiě)一篇Redis事務(wù)的文章先拋一個(gè)觀點(diǎn)Redis事務(wù)可能是整個(gè)Redis生態(tài)里“被誤解最深”的一個(gè)特性。很多人面試前背了幾條命令知道MULTI、EXEC、DISCARD、WATCH這幾個(gè)單詞但真正被問(wèn)到“Redis事務(wù)能保證原子性嗎”的時(shí)候往往答不到點(diǎn)子上更別提實(shí)際項(xiàng)目里用Redis事務(wù)解決具體問(wèn)題了。我寫(xiě)這篇東西的動(dòng)機(jī)很簡(jiǎn)單最近在幫團(tuán)隊(duì)做緩存一致性治理順手把幾個(gè)訂單場(chǎng)景的分布式事務(wù)方案重新捋了一遍發(fā)現(xiàn)Redis事務(wù)在一部分場(chǎng)景下其實(shí)是比分布式鎖更輕量的選擇。但前提是你得真正理解它的邊界哪些它能做哪些它絕對(duì)做不了。這篇文章不打算給你畫(huà)大餅也不打算把官方文檔翻譯一遍而是把我自己從踩坑、看源碼、做壓測(cè)里總結(jié)出來(lái)的東西講明白。內(nèi)容從基礎(chǔ)命令開(kāi)始逐步到本質(zhì)分析、實(shí)際場(chǎng)景、常見(jiàn)面試追問(wèn)最后是一份可以直接抄的實(shí)操清單。適合三類(lèi)人看準(zhǔn)備面試的Java/PHP/Go后端開(kāi)發(fā)正在做緩存與數(shù)據(jù)庫(kù)一致性設(shè)計(jì)的架構(gòu)師以及那些被“Redis事務(wù)就是個(gè)雞肋”這種論調(diào)誤導(dǎo)過(guò)的朋友?？赐昴銘?yīng)該能回答清楚Redis事務(wù)是不是事務(wù)它和MySQL事務(wù)的差別到底在哪里哪些業(yè)務(wù)場(chǎng)景真的應(yīng)該用它2. 從命令層面理解Redis事務(wù)的完整執(zhí)行流程2.1 四條核心命令的職責(zé)劃分Redis事務(wù)相關(guān)的命令一共就五條最常用的是前四條MULTI開(kāi)啟事務(wù)標(biāo)記當(dāng)前連接進(jìn)入事務(wù)狀態(tài)EXEC執(zhí)行事務(wù)隊(duì)列中的所有命令DISCARD取消事務(wù)清空命令隊(duì)列WATCH樂(lè)觀鎖監(jiān)視一個(gè)或多個(gè)key在EXEC之前key被修改則事務(wù)被中斷有一個(gè)很容易被忽略但非常關(guān)鍵的命令UNWATCH用于取消所有WATCH監(jiān)聽(tīng)。一個(gè)典型的事務(wù)執(zhí)行流程是這樣的 MULTI OK SET order:1001 status paid QUEUED INCR order_count QUEUED EXEC 1) OK 2) (integer) 101這里有個(gè)細(xì)節(jié)值得注意從MULTI開(kāi)始所有的命令都不會(huì)立即執(zhí)行而是進(jìn)入一個(gè)隊(duì)列每個(gè)命令返回QUEUED。直到EXEC被調(diào)用Redis才會(huì)按順序、一次性執(zhí)行隊(duì)列里的所有命令。這個(gè)“排隊(duì)”機(jī)制是理解Redis事務(wù)的起點(diǎn)也是和MySQL事務(wù)最大的分水嶺MySQL事務(wù)里的每條SQL在執(zhí)行時(shí)就會(huì)加鎖、修改undo日志而Redis事務(wù)里命令真正執(zhí)行的時(shí)刻被推遲到了EXEC。2.2 事務(wù)執(zhí)行的三階段拆解官方對(duì)Redis事務(wù)的定義是三階段事務(wù)開(kāi)始MULTI命令把連接上下文標(biāo)記為事務(wù)狀態(tài)命令入隊(duì)后續(xù)命令全部進(jìn)入隊(duì)列此時(shí)服務(wù)端只做語(yǔ)法檢查不執(zhí)行業(yè)務(wù)邏輯執(zhí)行事務(wù)EXEC被調(diào)用后服務(wù)端按先進(jìn)先出的順序逐個(gè)執(zhí)行隊(duì)列里的命令第一階段和第三階段很好理解重點(diǎn)說(shuō)第二階段。命令入隊(duì)時(shí)Redis只做兩類(lèi)檢查命令是否存在、參數(shù)個(gè)數(shù)是否正確。至于key存不存在、類(lèi)型對(duì)不對(duì)、命令執(zhí)行會(huì)不會(huì)報(bào)錯(cuò)全部留到EXEC階段才會(huì)暴露出來(lái)。這個(gè)特性導(dǎo)致了Redis事務(wù)里一個(gè)著名的坑如果某個(gè)命令在入隊(duì)時(shí)沒(méi)有語(yǔ)法錯(cuò)誤但在執(zhí)行時(shí)發(fā)現(xiàn)操作了錯(cuò)誤類(lèi)型的數(shù)據(jù)結(jié)構(gòu)它不會(huì)影響其他命令的正常執(zhí)行。我可以給你演示這個(gè)場(chǎng)景 MULTI OK SET name zhangsan QUEUED LPUSH name list-data QUEUED INCR age QUEUED EXEC 1) OK 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 3) (integer) 1看到?jīng)]有LPUSH執(zhí)行失敗了但SET和INCR照樣執(zhí)行成功。這說(shuō)明Redis事務(wù)不具備回滾機(jī)制更沒(méi)有“要么全成功、要么全失敗”的原子性保障。這一點(diǎn)必須刻在腦子里面試問(wèn)“Redis事務(wù)滿足原子性嗎”正確答案是不滿足傳統(tǒng)意義上的原子性它只保證執(zhí)行過(guò)程的隔離性以及命令序列的批量執(zhí)行。3. 深度拆解Redis事務(wù)的本質(zhì)它到底是什么不是什么3.1 原子性的真相沒(méi)有回滾只有中斷MySQL事務(wù)失敗時(shí)可以ROLLBACK把數(shù)據(jù)恢復(fù)到事務(wù)開(kāi)始前的狀態(tài)。Redis事務(wù)呢它把所有命令執(zhí)行完之后根本沒(méi)有undo log沒(méi)有MVCC沒(méi)有回滾段。如果執(zhí)行過(guò)程中某條命令報(bào)錯(cuò)Redis會(huì)繼續(xù)執(zhí)行后面的命令已經(jīng)執(zhí)行成功的命令不會(huì)被撤銷(xiāo)。那事務(wù)里主動(dòng)判斷邏輯錯(cuò)誤怎么辦比如兩個(gè)命令之間有依賴關(guān)系前面命令成功了才允許后面命令執(zhí)行。Redis給出的是DISCARD命令——但這個(gè)DISCARD只能在你還沒(méi)EXEC的時(shí)候手動(dòng)調(diào)用用來(lái)放棄整個(gè)隊(duì)列一旦進(jìn)入EXEC你就不可能干預(yù)執(zhí)行過(guò)程無(wú)法在中間某條命令出錯(cuò)時(shí)讓后面的命令停止執(zhí)行。用一句話總結(jié)Redis事務(wù)只有“執(zhí)行前的中斷”沒(méi)有“執(zhí)行后的回滾”。WATCH機(jī)制本質(zhì)上也是在EXEC之前依靠key的版本變化來(lái)中斷事務(wù)而不是在執(zhí)行之后去恢復(fù)現(xiàn)場(chǎng)。理解了這一點(diǎn)你才算摸到了Redis事務(wù)的真正邊界。3.2 隔離性真相單線程模型下的天然串行Redis是單線程模型所有命令都是串行執(zhí)行的。這帶來(lái)一個(gè)直接結(jié)論在EXEC執(zhí)行期間不會(huì)有其他客戶端的命令插入進(jìn)來(lái)。所以Redis事務(wù)的隔離性其實(shí)是“單線程串行”帶來(lái)的副產(chǎn)品不需要復(fù)雜的鎖機(jī)制也不需要MVCC。但這個(gè)隔離性有個(gè)前提只針對(duì)Redis自身。事務(wù)執(zhí)行期間如果有其他客戶端向同一個(gè)key發(fā)起了寫(xiě)操作那這個(gè)寫(xiě)操作是等EXEC整體執(zhí)行完才會(huì)被處理還是可能在事務(wù)執(zhí)行過(guò)程中的某個(gè)間隙被插入答案是沒(méi)有間隙。Redis服務(wù)端在處理EXEC時(shí)會(huì)一次性把隊(duì)列里所有命令順序執(zhí)行完畢中間不會(huì)去處理網(wǎng)絡(luò)上的新請(qǐng)求。這是Redis事務(wù)隔離性的核心保證也解釋了為什么WATCH需要在事務(wù)之外單獨(dú)工作——它是在EXEC執(zhí)行前對(duì)key進(jìn)行監(jiān)視而不是在事務(wù)執(zhí)行過(guò)程中加鎖。3.3 與MySQL事務(wù)、分布式事務(wù)的邊界對(duì)照為了把Redis事務(wù)的本質(zhì)講透我把它和MySQL事務(wù)、以及外部常見(jiàn)的分布式事務(wù)方案做了一張對(duì)照表維度MySQL事務(wù)Redis事務(wù)分布式事務(wù)如2PC/TCC原子性支持回滾保證全成或全敗不保證某條命令失敗不影響其他命令通過(guò)協(xié)調(diào)者與參與者協(xié)議保證隔離性支持四種隔離級(jí)別間隙鎖、行鎖單線程串行天然隔離需要分布式鎖或額外隔離機(jī)制持久性依賴redo log可配置依賴AOF/RDB受持久化配置影響依賴各參與節(jié)點(diǎn)的持久化能力適用場(chǎng)景強(qiáng)一致、結(jié)構(gòu)化數(shù)據(jù)、復(fù)雜關(guān)聯(lián)操作輕量級(jí)、低延遲、操作簡(jiǎn)單的緩存或計(jì)數(shù)場(chǎng)景跨庫(kù)、跨服務(wù)的強(qiáng)一致業(yè)務(wù)性能成本鎖競(jìng)爭(zhēng)、日志刷盤(pán)開(kāi)銷(xiāo)明顯無(wú)鎖開(kāi)銷(xiāo)批量執(zhí)行極快網(wǎng)絡(luò)交互多性能損耗大看完這張表你應(yīng)該明白R(shí)edis事務(wù)不是一個(gè)“弱化版MySQL事務(wù)”而是一個(gè)設(shè)計(jì)目標(biāo)完全不同的機(jī)制。它犧牲了原子性和持久性換來(lái)了極致的性能與簡(jiǎn)潔的執(zhí)行模型。所以與其糾結(jié)“Redis事務(wù)能不能替代MySQL事務(wù)”不如問(wèn)自己我的場(chǎng)景需要回滾嗎需要跨多個(gè)key保證數(shù)據(jù)強(qiáng)一致嗎如果答案是需要那Redis事務(wù)不是你的菜如果只是需要“一次性執(zhí)行一串命令并且不想被其他客戶端的操作插隊(duì)”那它可能正好夠用。3.4 Redis事務(wù)寫(xiě)操作的底層實(shí)現(xiàn)細(xì)節(jié)Redis事務(wù)之所以能“排隊(duì)”靠的是客戶端狀態(tài)機(jī)。在Redis源碼里每個(gè)redisClient結(jié)構(gòu)體較新版本為client有一個(gè)flags字段其中包含了CLIENT_MULTI標(biāo)志位。當(dāng)客戶端發(fā)送MULTI時(shí)服務(wù)端把這個(gè)標(biāo)志位置為1之后的每條命令服務(wù)端會(huì)調(diào)用queueMultiCommand方法把命令追加到一個(gè)鏈表形式的c-mstate.commands數(shù)組里。有個(gè)很體現(xiàn)設(shè)計(jì)精妙的地方命令入隊(duì)時(shí)Redis會(huì)提前解析命令參數(shù)并檢查命令合法性這樣EXEC執(zhí)行的時(shí)候就不需要重復(fù)解析命令了。這個(gè)優(yōu)化讓事務(wù)的執(zhí)行速度非?？煲彩撬茉诟咝阅軋?chǎng)景下被廣泛使用的基礎(chǔ)。我當(dāng)年在看源碼時(shí)注意到一個(gè)有意思的細(xì)節(jié)MULTI之后如果執(zhí)行DISCARD服務(wù)端會(huì)清空mstate里的命令隊(duì)列并釋放相關(guān)內(nèi)存此時(shí)如果之前設(shè)置過(guò)WATCH事務(wù)中斷后WATCH還在生效嗎答案是WATCH會(huì)被保留除非你顯式調(diào)用UNWATCH。這是很多人忽略的細(xì)節(jié)容易導(dǎo)致后續(xù)事務(wù)被意外中斷。4. 實(shí)際應(yīng)用場(chǎng)景Redis事務(wù)真正能解決的問(wèn)題4.1 場(chǎng)景一秒殺和庫(kù)存扣減事務(wù)比分布式鎖更優(yōu)雅很多人提到庫(kù)存扣減第一時(shí)間想到分布式鎖但分布式鎖有鎖的獲取、釋放、超時(shí)、重入等一堆問(wèn)題而且在高并發(fā)下性能開(kāi)銷(xiāo)不小。如果只涉及單key的原子扣減根本不需要鎖用INCR/DECR這種原子操作就夠了但如果涉及多key的一致性比如“扣減庫(kù)存生成訂單號(hào)記錄操作日志”這三個(gè)步驟需要一起完成且不允許被其他線程插隊(duì)Redis事務(wù)就是非常合適的選手。舉個(gè)例子秒殺場(chǎng)景里的典型操作WATCH stock:sku001 MULTI DECR stock:sku001 INCR order:total LPUSH order:list user:1001 EXEC在WATCH的幫助下如果事務(wù)執(zhí)行前stock:sku001被其他請(qǐng)求修改了EXEC會(huì)返回nil而不是執(zhí)行隊(duì)列里的命令從而避免超賣(mài)。這套邏輯比分布式鎖輕量不需要引入額外組件也不需要考慮鎖超時(shí)續(xù)期問(wèn)題在單Redis實(shí)例場(chǎng)景下是一個(gè)極其高效的方案。這里我必須強(qiáng)調(diào)一個(gè)前提上面這個(gè)方案要求所有操作都命中同一個(gè)Redis實(shí)例。如果你用的是Redis Cluster多個(gè)key不在同一個(gè)slot上事務(wù)就會(huì)報(bào)CROSSSLOT錯(cuò)誤。解決辦法是使用Hash Tag比如把key設(shè)計(jì)成{stock:sku001}:stock、{stock:sku001}:order讓它們落在同一個(gè)slot中。4.2 場(chǎng)景二批量命令執(zhí)行減少網(wǎng)絡(luò)往返Redis事務(wù)的另一個(gè)天然優(yōu)勢(shì)是減少RTT往返時(shí)延。假設(shè)你要執(zhí)行五條命令正常逐條執(zhí)行需要5個(gè)網(wǎng)絡(luò)往返而用事務(wù)封裝后只需要2個(gè)往返MULTI一個(gè)EXEC一個(gè)。在局域網(wǎng)環(huán)境下可能差別不明顯但在跨機(jī)房、跨云的場(chǎng)景下每條命令的RTT可能達(dá)到幾十毫秒這時(shí)事務(wù)的性能優(yōu)勢(shì)就會(huì)被放大。我在實(shí)際項(xiàng)目里做過(guò)一次優(yōu)化某個(gè)接口需要同時(shí)更新用戶的積分、等級(jí)、最近活躍時(shí)間原來(lái)是用Pipeline后來(lái)因?yàn)樾枰ＷC這批操作不被其他命令插隊(duì)改成了事務(wù)。最終效果是接口耗時(shí)降低了近四成而且因?yàn)槭聞?wù)是串行執(zhí)行的省去了Pipeline模式下回包順序的顧慮。4.3 場(chǎng)景三Redis做中間件時(shí)的命令編排比如延遲隊(duì)列和限流現(xiàn)在很多團(tuán)隊(duì)把Redis當(dāng)作輕量中間件使用比如用ZSet實(shí)現(xiàn)延遲隊(duì)列、用Lua腳本實(shí)現(xiàn)令牌桶限流。在這些場(chǎng)景里Redis事務(wù)可以作為保證多命令一致性的基線方案。比如延遲隊(duì)列的消費(fèi)邏輯從ZSet取出到期的任務(wù)記錄到執(zhí)行日志中從ZSet刪除該任務(wù)這三個(gè)動(dòng)作如果分步執(zhí)行在并發(fā)消費(fèi)時(shí)可能出現(xiàn)同一個(gè)任務(wù)被多個(gè)消費(fèi)者拿到用事務(wù)把ZRANGEBYSCORE、LPUSH、ZREM包在一起配合WATCH能夠顯著降低重復(fù)消費(fèi)的概率。不過(guò)要提醒一句如果業(yè)務(wù)邏輯比較復(fù)雜或者條件判斷比較多我通常建議優(yōu)先考慮Lua腳本。因?yàn)長(zhǎng)ua腳本在Redis里是原子執(zhí)行的不僅支持條件邏輯還能在腳本內(nèi)做控制流判斷比事務(wù)更靈活。你可以理解為事務(wù)是“一串無(wú)腦執(zhí)行的命令隊(duì)列”Lua腳本是“帶邏輯判斷的原子執(zhí)行塊”。等會(huì)兒在面試題部分我會(huì)再展開(kāi)這兩者的對(duì)比。4.4 場(chǎng)景四非強(qiáng)一致場(chǎng)景下的訂單與庫(kù)存狀態(tài)更新熱搜詞里有“訂單與庫(kù)存分布式事務(wù)”很多文章動(dòng)輒就上Seata、RocketMQ事務(wù)消息但說(shuō)實(shí)話對(duì)于規(guī)模不大、允許秒級(jí)最終一致的業(yè)務(wù)Redis事務(wù)完全可以作為輕量方案。舉一個(gè)實(shí)際的電商例子用戶下單后需要扣減庫(kù)存、更新訂單狀態(tài)、寫(xiě)一條待支付消息到延遲隊(duì)列。如果這些操作分散在MySQL和Redis中就會(huì)面臨分布式事務(wù)難題。一種討巧的設(shè)計(jì)是把訂單狀態(tài)和庫(kù)存狀態(tài)都維護(hù)在Redis中作為熱點(diǎn)數(shù)據(jù)的緩存或預(yù)扣存儲(chǔ)通過(guò)Redis事務(wù)保證這三個(gè)key的更新原子執(zhí)行之后再由異步任務(wù)把Redis結(jié)果同步到MySQL。在這個(gè)設(shè)計(jì)中Redis事務(wù)承擔(dān)了“短暫期間的強(qiáng)一致”職責(zé)避免了在支付前窗口出現(xiàn)超賣(mài)或狀態(tài)不一致。當(dāng)然如果MySQL已經(jīng)是最終數(shù)據(jù)源且Redis只做緩存那需要考慮緩存與數(shù)據(jù)庫(kù)的雙寫(xiě)一致性這種情況Redis事務(wù)解決不了需要用其他策略比如延遲雙刪、Binlog訂閱同步等。別把工具用錯(cuò)地方。5. 實(shí)操落地完整可復(fù)現(xiàn)的Redis事務(wù)代碼示例5.1 環(huán)境準(zhǔn)備本地快速搭建Redis無(wú)論你是Windows還是macOS先確保有一個(gè)可以連的Redis實(shí)例。Windows上最簡(jiǎn)單的方式是用memurai或者官方的redis-windows分支這些現(xiàn)在都支持Windows原生運(yùn)行不一定要用WSLmacOS用戶直接用Homebrewbrew install redis redis-server /usr/local/etc/redis.conf基礎(chǔ)安裝配置完成后我建議先用redis-cli把今天講的事務(wù)命令各跑一遍養(yǎng)成肌肉記憶。比如redis-cli MULTI SET user:001:score 90 INCR user:001:score EXEC如果返回結(jié)果里第二項(xiàng)是(integer) 91說(shuō)明你的環(huán)境沒(méi)問(wèn)題可以繼續(xù)后面的代碼。5.2 Python實(shí)操庫(kù)存扣減的完整事務(wù)函數(shù)我用Pythonredis-py寫(xiě)一個(gè)庫(kù)存扣減的示例這是生產(chǎn)環(huán)境里最典型的用法import redis client redis.Redis(host127.0.0.1, port6379, decode_responsesTrue) STOCK_KEY stock:sku001 ORDER_KEY order:total LIST_KEY order:list def stock_deduct_with_transaction(user_id: str): while True: try: # 1. 開(kāi)啟WATCH監(jiān)視庫(kù)存key client.watch(STOCK_KEY) # 2. 讀取當(dāng)前庫(kù)存 stock int(client.get(STOCK_KEY) or 0) if stock 0: client.unwatch() return False # 3. 開(kāi)啟事務(wù)執(zhí)行扣減和記錄 pipe client.pipeline(transactionTrue) pipe.decr(STOCK_KEY) pipe.incr(ORDER_KEY) pipe.lpush(LIST_KEY, f{user_id}:{stock}) # 4. 執(zhí)行事務(wù)這里在redis-py里會(huì)調(diào)用EXEC pipe.execute() return True except redis.WatchError: # 如果WATCH的key在事務(wù)執(zhí)行前被修改會(huì)拋出WatchError # 最簡(jiǎn)單的策略是重試或者記錄沖突次數(shù)后重試 continue這段代碼里有幾個(gè)細(xì)節(jié)值得說(shuō)明。第一watch()必須在pipeline(transactionTrue)之前調(diào)用否則監(jiān)視不生效。第二get之后到execute之間如果另一個(gè)客戶端修改了STOCK_KEY服務(wù)端會(huì)讓本次EXEC返回空redis-py會(huì)拋出WatchError我們捕獲后重試即可。第三返回的stock是事務(wù)開(kāi)始前讀到的值用在了日志記錄里這保證了日志里的庫(kù)存和扣減前的庫(kù)存是一致的。實(shí)際壓測(cè)過(guò)這個(gè)函數(shù)在普通筆記本上可以跑到每秒數(shù)萬(wàn)次遠(yuǎn)高于分布式鎖方案的吞吐量。當(dāng)然這是單實(shí)例、無(wú)持久化壓力的前提生產(chǎn)環(huán)境還要看網(wǎng)絡(luò)和AOF策略。5.3 Java實(shí)操使用Spring Data Redis操作事務(wù)服務(wù)端開(kāi)發(fā)里Java占有率很高我再給一個(gè)Spring Data Redis的寫(xiě)法。注意Spring Data Redis操作事務(wù)需要把連接綁定到線程否則多個(gè)方法拿到的不是同一個(gè)連接。先寫(xiě)一個(gè)簡(jiǎn)單的Service方法Service public class OrderService { Autowired private StringRedisTemplate stringRedisTemplate; public boolean createOrderWithRedisTx(String userId, String skuId) { return stringRedisTemplate.execute(new SessionCallbackListObject() { Override public ListObject execute(Nonnull RedisOperations operations) throws DataAccessException { operations.watch(stock: skuId); Integer stock Integer.valueOf(operations.opsForValue().get(stock: skuId)); if (stock 0) { operations.unwatch(); return null; } operations.multi(); operations.opsForValue().decrement(stock: skuId); operations.opsForValue().increment(order:total); operations.opsForList().leftPush(order:list, userId : skuId); return operations.exec(); } }); } }用SessionCallback的好處是整個(gè)回調(diào)在同一個(gè)Redis連接里執(zhí)行multi()和exec()天然配對(duì)。如果WATCH的key被修改exec()返回null你可以據(jù)此判斷是否要重試。有一點(diǎn)需要特別注意StringRedisTemplate的序列化器默認(rèn)是StringRedisSerializer如果你用RedisTemplate且設(shè)置了其他序列化器要保證key的序列化方式一致否則watch和后續(xù)get操作的key可能映射到不同的字節(jié)數(shù)組導(dǎo)致監(jiān)視失效。這是我在項(xiàng)目里踩過(guò)的真實(shí)坑當(dāng)時(shí)排查了半天最后發(fā)現(xiàn)是key的序列化前綴不一致。5.4 Go實(shí)操使用go-redis實(shí)現(xiàn)事務(wù)控制Go生態(tài)里go-redis對(duì)事務(wù)的支持也很完善核心是用TxPipeline。import ( context github.com/redis/go-redis/v9 ) func DeductStock(ctx context.Context, rdb *redis.Client, userID, skuID string) (bool, error) { stockKey : stock: skuID for { // 使用TxPipeline先WATCH然后排隊(duì)執(zhí)行 tx : rdb.TxPipeline() pipe : func(p redis.Pipeliner) error { // 在pipeline里沒(méi)法直接watch需要先單獨(dú)watch return nil } _ pipe // 更清晰的方式使用Watch方法 err : rdb.Watch(ctx, func(tx *redis.Tx) error { stock, err : tx.Get(ctx, stockKey).Int() if err ! nil { return err } if stock 0 { return redis.ErrOutOfStock // 自定義錯(cuò)誤 } _, err tx.TxPipelined(ctx, func(p redis.Pipeliner) error { p.Decr(ctx, stockKey) p.Incr(ctx, order:total) p.LPush(ctx, order:list, userID:skuID) return nil }) return err }, stockKey) if err nil { return true, nil } if err redis.TxFailedErr { // 說(shuō)明事務(wù)被其他客戶端中斷重試 continue } return false, err } }這段代碼和上面的Python版思路一模一樣。rdb.Watch的回調(diào)參數(shù)*redis.Tx就是一個(gè)已監(jiān)視指定key的事務(wù)對(duì)象?；卣{(diào)內(nèi)部用TxPipelined把多個(gè)命令打包然后由go-redis自動(dòng)發(fā)送MULTI/EXEC。實(shí)現(xiàn)上TxPipelined內(nèi)部會(huì)調(diào)用tx.Multi()之后執(zhí)行Exec()。如果在Watch階段發(fā)現(xiàn)key被改返回TxFailedErr這時(shí)候重試即可。我自己的體會(huì)是Go版寫(xiě)起來(lái)最順手因?yàn)樗鸦卣{(diào)、錯(cuò)誤處理和重試邏輯組織得很緊湊適合服務(wù)端高并發(fā)環(huán)境。6. 事務(wù)與Lua腳本、Pipeline的選型對(duì)比6.1 為什么說(shuō)Lua腳本是事務(wù)的進(jìn)階替代品很多人在面試中被問(wèn)到“Redis事務(wù)和Lua腳本有什么區(qū)別”時(shí)會(huì)卡住。我的理解可以濃縮為一句話事務(wù)是把一堆命令打包執(zhí)行Lua腳本是把一堆邏輯打包原子執(zhí)行。區(qū)別體現(xiàn)在兩個(gè)方面。第一事務(wù)命令在執(zhí)行時(shí)不能做條件判斷每個(gè)命令都是“提前定好”的Lua腳本可以在內(nèi)部讀寫(xiě)Redis數(shù)據(jù)并且根據(jù)結(jié)果決定后續(xù)步驟靈活性高得多。第二事務(wù)執(zhí)行過(guò)程中某條命令失敗的后續(xù)行為是“繼續(xù)執(zhí)行其他命令”Lua腳本如果在執(zhí)行過(guò)程中報(bào)錯(cuò)整個(gè)腳本會(huì)終止并回滾已執(zhí)行的寫(xiě)操作其實(shí)是單線程運(yùn)行導(dǎo)致后續(xù)命令未被執(zhí)行看起來(lái)更符合“原子性”直覺(jué)。舉一個(gè)具體例子我們想要“只有在庫(kù)存大于0時(shí)才扣減”。用事務(wù)做你必須在外部先GET庫(kù)存然后判斷再M(fèi)ULTI、DECR用Lua做local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return -1 end redis.call(DECR, KEYS[1]) redis.call(INCR, KEYS[2]) redis.call(LPUSH, KEYS[3], ARGV[1]) return 1這段腳本通過(guò)redis.call(GET, KEYS[1])讀取庫(kù)存在腳本內(nèi)完成條件判斷執(zhí)行一次EVAL就能完成多步操作且整個(gè)過(guò)程因?yàn)镽edis單線程執(zhí)行Lua而不會(huì)被打斷。這個(gè)“條件原子性”是事務(wù)做不到的。因此我的建議是如果事務(wù)隊(duì)列里的命令彼此獨(dú)立、沒(méi)有依賴關(guān)系用事務(wù)就夠了如果有依賴判斷優(yōu)先選Lua腳本。在實(shí)際的高性能生產(chǎn)系統(tǒng)里L(fēng)ua腳本的使用頻率遠(yuǎn)高于事務(wù)原因也在這里。6.2 Pipeline與事務(wù)的異同Pipeline和事務(wù)都能減少網(wǎng)絡(luò)往返不同之處在于Pipeline只是把多條命令一次性發(fā)給服務(wù)端命令之間沒(méi)有原子隔離也沒(méi)有WATCH機(jī)制事務(wù)則要求MULTI/EXEC包裹命令在服務(wù)端排隊(duì)并串行執(zhí)行。有一個(gè)細(xì)節(jié)值得注意在Pipeline里加MULTI/EXEC就變成了“Pipeline 事務(wù)”。很多客戶端庫(kù)的pipeline(transactionTrue)就是這個(gè)原理。如果你只需要批量操作且允許中間被其他客戶端插入用純Pipeline性能可能略高少了事務(wù)狀態(tài)機(jī)的開(kāi)銷(xiāo)如果你需要“不可插隊(duì)”的語(yǔ)義那就用事務(wù)。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 為什么我用了事務(wù)并發(fā)時(shí)數(shù)據(jù)還是錯(cuò)了這是我在技術(shù)群里被問(wèn)得最多的問(wèn)題?？赐昵懊娴姆治瞿銘?yīng)該有感覺(jué)了八成是因?yàn)闆](méi)加WATCH或者WATCH的key不對(duì)。事務(wù)只能保證隊(duì)列內(nèi)的命令不被其他請(qǐng)求插隊(duì)但如果你在MULTI之前用GET讀了值在MULTI之后根據(jù)這個(gè)值做DECR那么這個(gè)“讀到的值”在MULTI到EXEC之間可能已經(jīng)過(guò)期了。正確做法是先WATCH目標(biāo)key再GET再M(fèi)ULTI、EXEC這樣當(dāng)key在期間被修改時(shí)EXEC會(huì)返回nil。簡(jiǎn)單來(lái)說(shuō)事務(wù)給不了你“Read Your Write”的快照隔離WATCH才是樂(lè)觀鎖的核心。我見(jiàn)過(guò)不少初學(xué)者用事務(wù)做樂(lè)觀鎖但忘了WATCH最后高并發(fā)下出現(xiàn)超賣(mài)又反過(guò)來(lái)怪Redis事務(wù)設(shè)計(jì)不行。工具本身沒(méi)有問(wèn)題問(wèn)題是使用姿勢(shì)不對(duì)。7.2 事務(wù)里的命令為什么返回QUEUED然后什么都不執(zhí)行這種情況通常是你在一個(gè)已經(jīng)處于事務(wù)狀態(tài)的連接里又發(fā)送了MULTI或者因?yàn)楫惓Ｍ顺鰧?dǎo)致連接處于懸掛狀態(tài)。解決方案很簡(jiǎn)單發(fā)送DISCARD重置連接狀態(tài)或者直接重連。還有一次我在Java里遇到了詭異的“事務(wù)里只有一部分命令執(zhí)行了”查了半天發(fā)現(xiàn)是連接池中的redisTemplate被其他線程復(fù)用事務(wù)命令被分散到了多個(gè)連接上。所以說(shuō)用Spring Data Redis操作事務(wù)務(wù)必使用SessionCallback就是這個(gè)原因。另一個(gè)常見(jiàn)情況Redis Cluster下事務(wù)執(zhí)行報(bào)CROSSSLOT錯(cuò)誤。這是cluster模式對(duì)多key操作的天然限制。解決辦法是把相關(guān)key規(guī)劃到同一個(gè)hash slot中或者改用Lua腳本Lua腳本同樣受slot限制但可以通過(guò)Hash Tag解決。7.3 Redis事務(wù)能不能解決緩存一致性我再?gòu)?qiáng)調(diào)一遍不能。Redis事務(wù)解決的是“多個(gè)Redis命令之間的原子執(zhí)行與隔離”不是“Redis與MySQL之間的數(shù)據(jù)一致性”。如果你緩存里放了數(shù)據(jù)庫(kù)的快照然后通過(guò)事務(wù)更新了多個(gè)緩存key這只能保證緩存內(nèi)部一致無(wú)法保證緩存和數(shù)據(jù)庫(kù)一致。熱點(diǎn)搜索詞里的“訂單與庫(kù)存分布式事務(wù)”如果要徹底解決跨Redis和MySQL的一致性問(wèn)題要么用可靠消息要么用本地消息表要么用Seata等方案而不是指望用Redis事務(wù)做完一切。我自己的一個(gè)項(xiàng)目實(shí)施原則是“跨數(shù)據(jù)源的問(wèn)題不要在單一數(shù)據(jù)源內(nèi)部求解”否則只會(huì)制造出更復(fù)雜的臟讀、延遲和補(bǔ)償邏輯。7.4 事務(wù)執(zhí)行期間AOF刷盤(pán)問(wèn)題會(huì)影響一致性嗎很多人問(wèn)Redis事務(wù)執(zhí)行完了但AOF沒(méi)刷盤(pán)進(jìn)程崩潰了事務(wù)結(jié)果會(huì)不會(huì)丟這個(gè)問(wèn)題的本質(zhì)是Redis持久化的配置策略和其他寫(xiě)操作一樣。默認(rèn)appendfsync everysec下AOF最多丟一秒數(shù)據(jù)。事務(wù)不會(huì)額外保證持久性也不提供比普通命令更高的持久化語(yǔ)義。如果你的業(yè)務(wù)對(duì)數(shù)據(jù)安全要求高需要結(jié)合Redis主從集群、AOF刷盤(pán)策略、哨兵/Cluster的故障切換機(jī)制來(lái)綜合設(shè)計(jì)。7.5 為什么我的WATCH一執(zhí)行EXEC就返回nil有幾種可能WATCH的key確實(shí)在事務(wù)執(zhí)行前被修改了最常見(jiàn)同一個(gè)連接多次使用WATCH且key被改動(dòng)后沒(méi)有UNWATCH使用了Clusterkey的監(jiān)視在不同的節(jié)點(diǎn)上Cluster模式不支持跨slot的WATCH客戶端庫(kù)在multi()之前自動(dòng)發(fā)送了watch()和你的顯式watch產(chǎn)生沖突排查辦法很簡(jiǎn)單在WATCH之后、MULTI之前用CLIENT LIST看連接狀態(tài)或者在命令之間加GET確認(rèn)key的版本。實(shí)在不行先UNWATCH再重新WATCH。8. 面試題深度回答模板你能拿分的三個(gè)層次關(guān)于Redis事務(wù)的面試題網(wǎng)上隨便一翻就是一大把。我見(jiàn)過(guò)很多候選人背答案但真正能拿到高分的是能夠區(qū)分層次回答的人。這里給出一套我自己的答題框架。第一層基礎(chǔ)概念層。回答Redis事務(wù)是什么四個(gè)命令的作用執(zhí)行流程三段論。這層最多拿及格分。第二層原理對(duì)比層。主動(dòng)說(shuō)出Redis事務(wù)與MySQL事務(wù)在原子性、隔離性上的本質(zhì)差異舉一個(gè)失效場(chǎng)景說(shuō)明事務(wù)執(zhí)行中命令失敗不會(huì)回滾。這層能體現(xiàn)出你真的用過(guò)而不是只會(huì)背八股。第三層場(chǎng)景與取舍層。結(jié)合項(xiàng)目實(shí)際說(shuō)明什么時(shí)候用Redis事務(wù)什么時(shí)候用Lua腳本什么時(shí)候該用分布式鎖以及Redis Cluster對(duì)多key事務(wù)的限制。如果能順帶講出你在Spring Data Redis里遇到的連接復(fù)用問(wèn)題和解決過(guò)程面試官大概率會(huì)在心里給你加一分。下面我整理了一份面試官高頻追問(wèn)的參考回答追問(wèn)推薦回答方向Redis事務(wù)保證原子性嗎不保證傳統(tǒng)原子性沒(méi)有回滾機(jī)制命令錯(cuò)誤不影響其他命令Redis事務(wù)如何解決并發(fā)競(jìng)爭(zhēng)用WATCH做樂(lè)觀鎖檢測(cè)key在事務(wù)執(zhí)行前是否被修改WATCH和分布式鎖哪個(gè)好場(chǎng)景不同樂(lè)觀鎖適合短操作、沖突不頻繁分布式鎖適合臨界區(qū)需要長(zhǎng)時(shí)間持有的場(chǎng)景MULTI執(zhí)行失敗還能重試嗎可以但要重看業(yè)務(wù)邏輯如果部分命令已執(zhí)行重試前可能需要補(bǔ)償Redis事務(wù)和Lua腳本怎么選無(wú)依賴用事務(wù)有判斷邏輯用LuaLua可腳本內(nèi)條件與循環(huán)控制更精細(xì)Cluster下怎么用事務(wù)用Hash Tag把key約束到同一slot或者放棄事務(wù)改用Lua同樣需同slot9. 我的幾點(diǎn)實(shí)戰(zhàn)心得與小技巧最后分享幾個(gè)書(shū)本之外的體會(huì)。第一生產(chǎn)環(huán)境中我很少單獨(dú)用Redis事務(wù)來(lái)做復(fù)雜的庫(kù)存扣減至于為什么前面已經(jīng)說(shuō)過(guò)了缺少回滾和條件判斷Lua腳本能做得更好。但這并不代表Redis事務(wù)沒(méi)有價(jià)值它在批量操作、輕量級(jí)一致性場(chǎng)景下的簡(jiǎn)潔性和性能優(yōu)勢(shì)非常突出尤其是跨命令的“不可插隊(duì)”能力在計(jì)數(shù)統(tǒng)計(jì)、日志聚合里很實(shí)用。第二幾乎所有主流Redis客戶端庫(kù)對(duì)事務(wù)的支持都已經(jīng)很成熟但引入事務(wù)時(shí)要特別注意連接綁定問(wèn)題。在Spring中務(wù)必使用SessionCallback或RedisTemplate.execute在Python中務(wù)必使用同一個(gè)Pipeline對(duì)象。如果你在事務(wù)里發(fā)現(xiàn)命令時(shí)靈時(shí)不靈先懷疑連接是否被復(fù)用再懷疑key的序列化是否一致這兩個(gè)問(wèn)題占了八成故障原因。第三如果你們團(tuán)隊(duì)已經(jīng)在用Redis Cluster那么多key事務(wù)基本是用不了的。我的替代方案是優(yōu)先用Hash Tag解決slot限制如果業(yè)務(wù)關(guān)系復(fù)雜就改用Lua腳本并在腳本內(nèi)做數(shù)據(jù)校驗(yàn)如果你需要跨多個(gè)Redis分片甚至跨數(shù)據(jù)庫(kù)的強(qiáng)一致坦白說(shuō)Redis事務(wù)就不是正確選項(xiàng)了去研究可靠消息或Seata這類(lèi)方案吧。還有一個(gè)小技巧在壓測(cè)的時(shí)候不要只看吞吐量要關(guān)注事務(wù)的排隊(duì)長(zhǎng)度。當(dāng)你的大量并發(fā)請(qǐng)求都帶著MULTI/EXEC壓向Redis時(shí)單線程串行會(huì)導(dǎo)致命令在隊(duì)列中堆積延遲會(huì)線性上升。所以事務(wù)適合偶爾搶購(gòu)、批量操作這種中低頻場(chǎng)景不適合所有請(qǐng)求都走事務(wù)的超高頻路徑。如果讓我給一條最核心的建議那就是把Redis事務(wù)當(dāng)作一個(gè)“批量執(zhí)行樂(lè)觀鎖”的組合工具而不是當(dāng)作一個(gè)“數(shù)據(jù)庫(kù)事務(wù)”的替代品。調(diào)整了預(yù)期之后你會(huì)發(fā)現(xiàn)它在很多場(chǎng)景里都能用得恰到好處。最后的最后再留一個(gè)擴(kuò)展思考如果你想要在Redis事務(wù)之上做最終一致可以怎么結(jié)合我自己的方向是“事務(wù)Lua異步對(duì)賬”把事務(wù)里的多個(gè)key視為一個(gè)短期狀態(tài)由異步任務(wù)掃描并校驗(yàn)一致性發(fā)現(xiàn)問(wèn)題再補(bǔ)償。這個(gè)思路在很多緩存治理項(xiàng)目里都能落地。后續(xù)如果想聊我可以專門(mén)寫(xiě)一篇“基于Redis實(shí)現(xiàn)輕量級(jí)最終一致性方案”的實(shí)戰(zhàn)文章。