文章目錄

• 概述
• 場景一: 命令格正確,數(shù)據(jù)類型錯誤
• 場景二：命令格式錯誤
• 總結(jié)

概述

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

場景一: 命令格正確,數(shù)據(jù)類型錯誤

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 對其自增，但是命令只會進入事務隊列，而沒有被執(zhí)行，所以它不會有任何的錯誤發(fā)生，而是等待 exec 命令的執(zhí)行。

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

---

場景二：命令格式錯誤

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

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 會立即檢測出來并產(chǎn)生錯誤，而在此之前我們設置了 keyl ， 在此之后我們設置了 key2 a 當事務執(zhí)行的時候，我們發(fā)現(xiàn) keyl 和 key2 的值都為空，說明被 Redis 事務回滾了。

---

總結(jié)

通過上面兩個例子，可以看出Redis在執(zhí)行事務命令的時候，在命令入隊的時候， Redis 就會檢測事務的命令是否正確，如果不正確則會產(chǎn)生錯誤。無論之前和之后的命令都會被事務所回滾，就變?yōu)槭裁炊紱]有執(zhí)行。

當命令格式正確，而因為操作數(shù)據(jù)結(jié)構(gòu)引起的錯誤 ，則該命令執(zhí)行出現(xiàn)錯誤，而其之前和之后的命令都會被正常執(zhí)行。這點和數(shù)據(jù)庫很不一樣，這是需注意的地方。

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

總結(jié)

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

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