• 為了保證多條命令組合的原子性，Redis提供了簡單的事務(wù)功能以及集成Lua腳本來解決這個問題，本文介紹Redis事務(wù)，Lua在下一篇文章介紹

一、事務(wù)概述

• 簡單地說，事務(wù)表示一組動作，要么全部執(zhí)行，要么全部不執(zhí)行。例如在社交網(wǎng)站上用戶A關(guān)注了用戶B，那么需要在用戶A的關(guān)注表中加入用戶B，并且在用戶B的粉絲表中添加用戶A，這兩個行為要么全部執(zhí)行，要么全部不執(zhí)行，否則會出現(xiàn)數(shù)據(jù)不一致的情況

• Redis只提供了四個命令管理事務(wù)：

• • MULTI：用來開啟一個事務(wù)。開啟一個事務(wù)之后，輸入的命令不會被立即執(zhí)行，而是進(jìn)入事務(wù)隊列中（入隊），所以可以看見輸入命令的結(jié)果顯示為“QUEUED”

  • WATCH：是一個樂觀鎖。它可以在EXEC命令執(zhí)行之前，監(jiān)視任意數(shù)量的數(shù)據(jù)庫鍵，并在EXEC命令執(zhí)行時，檢查被監(jiān)視的鍵是否至少有一個已經(jīng)被修改過了，如果是的話，服務(wù)器將拒絕執(zhí)行事務(wù)，并向客戶端返回代表事務(wù)執(zhí)行失敗的空回復(fù)

  • DISCARD：用于取消本次事務(wù)，放棄執(zhí)行事務(wù)塊內(nèi)的所有命令。如果使用了WATCH，DISCARD將取消監(jiān)視連接監(jiān)視的所有鍵

  • EXEC：提交一個事務(wù)

• 所以Redis的事務(wù)比較簡單，主要是因為它不支持事務(wù)中的回滾特性，同時無法實現(xiàn)命令之間的邏輯關(guān)系計算，當(dāng)然也體現(xiàn)了Redis的“keep it simple”的特性

二、事務(wù)演示案例

MULTI+EXEC

• 下面使用MULTI開啟一個事務(wù)，并且執(zhí)行相關(guān)操作，最后使用EXEC提交執(zhí)行事務(wù)內(nèi)的操作

• 備注：可以看到事務(wù)開啟之后，每次執(zhí)行的命令結(jié)果都會顯示QUEUED，表示命令入隊，但是沒有被執(zhí)行

MULTI+DISCARD

• 下面使用MULTI開啟一個事務(wù)，并且執(zhí)行相關(guān)操作，最后使用DISCARD終止本次事務(wù)，并且事務(wù)內(nèi)的操作全部放棄執(zhí)行

• 備注：因為discard已經(jīng)結(jié)束事務(wù)了，所以再次輸入exec會顯示沒有匹配的multi

MULTI+WATCH+EXEC

• 客戶端1：先設(shè)置一個字符串，鍵名為key，然后使用watch監(jiān)聽該鍵。然后開啟事務(wù)

• 客戶端2：在客戶端1事務(wù)還未結(jié)束的時候，修改key

• 客戶端1：操作key，并提交事務(wù)。因為key被其他客戶端修改，所以EXEC返回nil，事務(wù)沒有被執(zhí)行。然后獲取key，key沒有被改變

三、事務(wù)錯誤的處理

• 如果事務(wù)中出現(xiàn)錯誤，那么Reiis的處理機(jī)制也不盡相同

①命令錯誤

• 如果一個事務(wù)在入隊命令的過程中，出現(xiàn)了命令不存在，或者命令的格式不正確等情況，那么Redis將拒絕執(zhí)行這個事務(wù)

• 例如：下面操作錯將set寫成了sett，屬于語法錯誤，會造成整個事務(wù)無法執(zhí)行，key和counter的值未發(fā)生變化：

????? ?根據(jù)文檔記錄，在Redis 2.6.5以前的版本，即使有命令在入隊過程中發(fā)生了錯誤， 事務(wù)一樣可以執(zhí)行，不過被執(zhí)行的命令只包括那些正確入隊的命令，以下這段代碼是 在Redis 2.6.4版本上測試的，可以看到事務(wù)可以正常執(zhí)行，但只有成功入隊的SET命令 和GET命令被執(zhí)行了，而錯誤的YAH000O則被忽略了:

redis> MULTI OK redis> SET msg "hello" QUEUED redis> YAH000O (error) ERR unknown command ' YAH000O' redis> GET msg QUEUED redis> EXEC 11 OK 2) "hello"

②運(yùn)行時錯誤（執(zhí)行錯誤）

• 有些事務(wù)輸入的命令沒有錯誤，但是語法或邏輯有錯誤，這類錯誤不會被立即檢測出來，只有當(dāng)事務(wù)提交時才會被檢測出來

• 即使在事務(wù)的執(zhí)行過程中發(fā)生了錯誤，服務(wù)器也不會中斷事務(wù)的執(zhí)行，它會繼續(xù)執(zhí)行事務(wù)中余下的其他命令，并且已執(zhí)行的命令（包括執(zhí)行命令所產(chǎn)生的結(jié)果）不會被出錯的命令影響

• 因為在事務(wù)執(zhí)行的過程中，出錯的命令會被服務(wù)器識別出來，并進(jìn)行相應(yīng)的錯誤處理， 所以這些出錯命令不會對數(shù)據(jù)庫做任何修改，也不會對事務(wù)的一致性產(chǎn)生任何影響

③服務(wù)器停機(jī)

• 如果Redis服務(wù)器在執(zhí)行事務(wù)的過程中停機(jī)，那么根據(jù)服務(wù)器所使用的持久化模式，可能有以下情況出現(xiàn)：

• • 如果服務(wù)器運(yùn)行在無持久化的內(nèi)存模式下，那么重啟之后的數(shù)據(jù)庫將是空白的，因此數(shù)據(jù)總是一致的

  • 如果服務(wù)器運(yùn)行在RDB模式下，那么在事務(wù)中途停機(jī)不會導(dǎo)致不一致性，因為服務(wù)器可以根據(jù)現(xiàn)有的RDB文件來恢復(fù)數(shù)據(jù)，從而將數(shù)據(jù)庫還原到一個一致的狀態(tài)。如果找不到可供使用的RDB文件，那么重啟之后的數(shù)據(jù)庫將是空白的，而空白數(shù)據(jù)庫總是一致的

  • 如果服務(wù)器運(yùn)行在AOF模式下，那么在事務(wù)中途停機(jī)不會導(dǎo)致不一致性，因為服務(wù)器可以根據(jù)現(xiàn)有的AOF文件來恢復(fù)數(shù)據(jù)，從而將數(shù)據(jù)庫還原到一個一致的狀態(tài)。如果找不到可供使用的AOF文件，那么重啟之后的數(shù)據(jù)庫將是空白的，而空白數(shù)據(jù)庫總是一致的

• 綜上所述，無論Redis服務(wù)器運(yùn)行在哪種持久化模式下，事務(wù)執(zhí)行中途發(fā)生的停機(jī)都不會影響數(shù)據(jù)庫的一致性

總結(jié)

以上是生活随笔為你收集整理的Redis:17---常用功能之（事务）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。