Redis的事務實例分析

Redis 中的使用

Redis 透過 multi，exec，discard，watch 實作交易功能。

• multi：開始交易

• exec：提交交易並執行

• discard：取消事務

• watch：事務開始前監視任意數量的鍵

> multi
OK
> set bookName "Redis"
QUEUED
> get bookName
QUEUED
> sadd tag "Redis" "New Book"
QUEUED
> smembers tag
QUEUED
> exec
1) OK
2) "Redis"
3) (integer) 2
4) 1) "Redis"
   2) "New Book"

開始事務

> multi
OK

這個指令將Redis_multi 選項打開，讓客戶端從非事務狀態變成事務狀態

命令入隊

> set bookName "Redis"
QUEUED
> get bookName
QUEUED
> sadd tag "Redis" "New Book"
QUEUED
> smembers tag
QUEUED

Redis指令不會立即執行，而是先進入一個先進先出的事務佇列，直到事務被提交。 QUEUED 表示這個指令已經入了事務隊列。

執行交易

> exec
1) OK
2) "Redis"
3) (integer) 2
4) 1) "Redis"
   2) "New Book"

當執行exec 指令時，Redis 會依照客戶端所儲存的交易佇列， 以先進先出的方式執行事務佇列中的指令：最先入隊的指令最先執行， 而最後入隊的命令最後執行。執行 exec 命令後，Redis 將結果儲存在回覆佇列中並將該佇列傳送給客戶端。客戶端從事務狀態退出，一個事務執行完畢。

discard 指令

> multi
OK
> set author "lisi"
QUEUED
> discard
OK
> get author
(nil)

discard 取消一個交易的指令，表示這個交易被取消。當客戶端結束交易狀態，回到非交易狀態時，需要關閉 Redis_multi 選項。

watch 指令

# Redis 客户端1
> watch letter
OK
> multi
OK
> set letter a
QUEUED
> exec
(nil)


# Redis 客户端2
> set letter b
OK

# Redis 客户端1
> get letter
"b"

在客戶端1進入交易時，監控設定了letter鍵，並將其值設為a，但該交易尚未提交。客戶端2設定 letter 的 value 為 b。客戶端1提交事務後傳回的結果為 nil，但呼叫 get 指令可以得到 letter 的值為 b。這表示當 letter 鍵被其他客戶端改變後，事務將被取消，不會執行，並傳回失敗。

watch 指令在事務開始之前監視任意數量的鍵：當呼叫exce 指令執行事務時，如果任意一個被監視的鍵已經被其他客戶端修改了，那麼整個事務不再執行，直接傳回失敗。

交易異常

命令錯誤

> set letter ac
QUEUED
> get letter ac
(error) ERR wrong number of arguments for 'get' command
> exec
(error) EXECABORT Transaction discarded because of previous errors.

交易中命令異常屬於語法錯誤，將導致交易無法執行。

運行時異常

> multi
OK
> lpush books "Redis"
QUEUED
> incr books
QUEUED
> lpush books "Python"
QUEUED
> lrange books 0 -1
QUEUED
> exec
1) (integer) 1
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 2
4) 1) "Python"
   2) "Redis"

上面的範例是事務執行到中間遇到失敗了，因為不能對一個字串進行incr 命令，事務在遇到命令執行失敗後，後續的指令還繼續執行，所以books 的值可以繼續設定。這種異常只有程式設計師在程式碼中避免。

事務的 ACID

原子性

原子意味著要麼一起成功執行，要麼一起失敗回滾。 Redis 提供的所有 API 都是原子操作。那麼Redis 事務只要保證在一批操作中保證原子性，但是在運行時異常中，在一個事務中一個命令出現異常，其他命令還是會繼續執行，事務沒有回滾機制，所以Redis 事務是不保證原子性的。

一致性

交易異常

如果命令錯誤交易無法執行，如果是執行時期異常，Redis 會將錯誤包含在傳回結果中，並不會影響後續執行，所以事務是一致性的。

Redis 程序被終結

在純記憶體模式下，Redis 沒有做持久化，重啟之後資料庫是空白的，所以是交易一致性的。

在 RDB 模式下，事務並不會在中途執行保存 RDB 檔案的工作，只有在事務執行完後，RDB 工作才可能會開始。所以在事務執行過程中 Redis 進程被殺死，不管成功多少都不會儲存到 RDB 檔案中，所以是一致性的。

在 AOF 模式下，事務部分語句被寫入 AOF 文件並保存成功，不完整的事務被保存到了 AOF 文件，當重啟 Redis 時，檢查 AOF 文件不完整，Redis 退出並報錯。需要把這段不完整的事務刪除後才能重啟成功，所以是一致性的。

在 AOF 模式下，事務並未被寫入 AOF 文件，所以重新啟動後 Redis 資料庫是最近一次成功儲存到 AOF 文件中的資料。並沒有這次事務的數據，所以是以一致性的。

隔離性

Redis 是單一進程程序，並且它保證在執行事務時，不會對事務進行中斷，事務可以運行直到執行完所有事務佇列中的命令為止。所以交易是帶有隔離性的。

持久

在純記憶體模式下，交易肯定不是持續性的。

在 RDB 模式下，伺服器可能在交易執行之後、RDB 檔案更新之前的這段時間都失敗，所以 RDB 模式下的交易也是不持久的。

在 AOF 模式下，將指令加入 AOF 檔案中，但對檔案進行寫入並不會馬上寫到磁碟上，而是先儲存到緩衝區。所以資料保存到磁碟上有一段非常小的時間間隔。這種模式下交易也不是持久的。

以上是Redis的事務實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！