對於 redis 而言，不單單需要注意其事務處理的過程，其回滾的能力也和資料庫不太一樣，這也是需要特別注意的乙個問題一redis 事務遇到的命令格式正確而資料型別不符合，如下所示。
127.0
.0.1
:6379
> flushdb
ok127.0
.0.1
:6379
> multi
ok127.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) ok3)
(error) err value is not an integer or out of range4)
(integer)
1127.0
.0.1
:6379
> get key1
"value1"
127.0
.0.1
:6379
> get key2
(nil)
127.0
.0.1
:6379
>
當 exec 命令執行後，之前進入佇列的命令就依次執行，當遇到 incr 時發生命令操作的資料型別錯誤，所以顯示出了錯誤，而其之前和之後的命令都會被正常執行.
注意，這裡命令格式是正確的，問題在於資料型別，對於命令格式是錯誤的卻是另外一種情形如下所示
127.0
.0.1
:6379
> flushdb
ok127.0
.0.1
:6379
> multi
ok127.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
>
通過上面兩個例子，可以看出redis在執行事務命令的時候，在命令入隊的時候， redis 就會檢測事務的命令是否正確，如果不正確則會產生錯誤。無論之前和之後的命令都會被事務所回滾，就變為什麼都沒有執行。
當命令格式正確，而因為運算元據結構引起的錯誤，則該命令執行出現錯誤，而其之前和之後的命令都會被正常執行。這點和資料庫很不一樣，這是需注意的地方。
對於一些重要的操作，我們必須通過程式去檢測資料的正確性，以保證 redis 事務的正確執行，避免出現資料不一致的情況。 redis 之所以保持這樣簡易的事務，完全是為了保證移動網際網路的核心問題一----效能。
Redis（四）redis的事務
可以一次執行多個命令，本質是一組命令的集合。乙個事務中的 所有命令都會序列化，按順序地序列化執行而不會被其它命令插入，不許加塞。乙個佇列中，一次性 順序性 排它性的執行一系列命令。開啟 以multi開始乙個事務 入隊 將多個命令入隊到事務中，接到這些命令並不會立即執行，而是放到等待執行的事務佇列裡面...
redis事務 redis 優化
redis提供許多批量操作的命令，如mset mget hmset hmget等等，這些命令存在的意義是減少維護網路連線和傳輸資料所消耗的資源和時間。例如連續使用5次set命令設定5個不同的key，比起使用一次mset命令設定5個不同的key，效果是一樣的，但前者會消耗更多的rtt round tr...
Redis（十三）redis事務
redis作為乙個非關係型資料庫，其也是有事務操作的。redis 事務可以一次執行多個命令，並且帶有以下三個重要的保證 1 批量操作在傳送 exec 命令前被放入佇列快取。2 收到 exec 命令後進入事務執行，事務中任意命令執行失敗，其餘的命令依然被執行。3 在事務執行過程，其他客戶端提交的命令請...