文章目錄

• 概述
• 場景一: 命令格正確,數據類型錯誤
• 場景二：命令格式錯誤
• 總結

概述

對于 Redis 而言，不單單需要注意其事務處理的過程，其回滾的能力也和數據庫不太一樣，這也是需要特別注意的一個問題一Redis 事務遇到的命令格式正確而數據類型不符合 ，如下所示。

場景一: 命令格正確,數據類型錯誤

127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET key1 value1 QUEUED 127.0.0.1:6379> SET key2 value2 QUEUED 127.0.0.1:6379> INCR key1 QUEUED 127.0.0.1:6379> DEL key2 QUEUED 127.0.0.1:6379> EXEC 1) OK 2) OK 3) (error) ERR value is not an integer or out of range 4) (integer) 1 127.0.0.1:6379> GET key1 "value1" 127.0.0.1:6379> GET key2 (nil) 127.0.0.1:6379>

我們將 key1 設置為字符串，而使用命令 incr 對其自增，但是命令只會進入事務隊列，而沒有被執行，所以它不會有任何的錯誤發生，而是等待 exec 命令的執行。

當 exec 命令執行后，之前進入隊列的命令就依次執行，當遇到 incr 時發生命令操作的數據類型錯誤，所以顯示出了錯誤，而其之前和之后的命令都會被正常執行.

---

場景二：命令格式錯誤

注意，這里命令格式是正確的，問題在于數據類型，對于命令格式是錯誤的卻是另外一種情形 如下所示

127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set key1 value1 QUEUED 127.0.0.1:6379> incr (error) ERR wrong number of arguments for 'incr' command 127.0.0.1:6379> set key2 value2 QUEUED 127.0.0.1:6379> EXEC (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> GET key1 (nil) 127.0.0.1:6379> GET key2 (nil) 127.0.0.1:6379>

可以看到我們使用的 incr 命令格式是錯誤的，這個時候 Redis 會立即檢測出來并產生錯誤，而在此之前我們設置了 keyl ， 在此之后我們設置了 key2 a 當事務執行的時候，我們發現 keyl 和 key2 的值都為空，說明被 Redis 事務回滾了。

---

總結

通過上面兩個例子，可以看出Redis在執行事務命令的時候，在命令入隊的時候， Redis 就會檢測事務的命令是否正確，如果不正確則會產生錯誤。無論之前和之后的命令都會被事務所回滾，就變為什么都沒有執行。

當命令格式正確，而因為操作數據結構引起的錯誤 ，則該命令執行出現錯誤，而其之前和之后的命令都會被正常執行。這點和數據庫很不一樣，這是需注意的地方。

對于一些重要的操作，我們必須通過程序去檢測數據的正確性，以保證 Redis 事務的正確執行，避免出現數據不一致的情況。 Redis 之所以保持這樣簡易的事務，完全是為了保證移動互聯網的核心問題一----性能。

總結

以上是生活随笔為你收集整理的Redis-10Redis的事务回滚的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。