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