一、概述：
和眾多其它數據庫一樣，Redis作為NoSQL數據庫也同樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現事務的基石。相信對有關系型數據庫開發經驗的開發者而言這一概念并不陌生，即便如此，我們還是會簡要的列出Redis中事務的實現特征：
1). 在事務中的所有命令都將會被串行化的順序執行，事務執行期間，Redis不會再為其它客戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行。
2). 和關系型數據庫中的事務相比，在Redis事務中如果有某一條命令執行失敗，其后的命令仍然會被繼續執行。
3). 我們可以通過MULTI命令開啟一個事務，有關系型數據庫開發經驗的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之后執行的命令都將被視為事務之內的操作，最后我們可以通過執行EXEC/DISCARD命令來提交/回滾該事務內的所有操作。這兩個Redis命令可被視為等同于關系型數據庫中的COMMIT/ROLLBACK語句。
4). 在事務開啟之前，如果客戶端與服務器之間出現通訊故障并導致網絡斷開，其后所有待執行的語句都將不會被服務器執行。然而如果網絡中斷事件是發生在客戶端執行EXEC命令之后，那么該事務中的所有命令都會被服務器執行。
5). 當使用Append-Only模式時，Redis會通過調用系統函數write將該事務內的所有寫操作在本次調用中全部寫入磁盤。然而如果在寫入的過程中出現系統崩潰，如電源故障導致的宕機，那么此時也許只有部分數據被寫入到磁盤，而另外一部分數據卻已經丟失。Redis服務器會在重新啟動時執行一系列必要的一致性檢測，一旦發現類似問題，就會立即退出并給出相應的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數據不一致的錯誤，并將已經寫入的部分數據進行回滾。修復之后我們就可以再次重新啟動Redis服務器了。
二、相關命令列表：
|
命令原型 |
時間復雜度 |
命令描述 |
返回值 |
|
MULTI |
|
用于標記事務的開始，其后執行的命令都將被存入命令隊列，直到執行EXEC時，這些命令才會被原子的執行。 |
始終返回OK |
|
EXEC |
|
執行在一個事務內命令隊列中的所有命令，同時將當前連接的狀態恢復為正常狀態，即非事務狀態。如果在事務中執行了WATCH命令，那么只有當WATCH所監控的Keys沒有被修改的前提下，EXEC命令才能執行事務隊列中的所有命令，否則EXEC將放棄當前事務中的所有命令。 |
原子性的返回事務中各條命令的返回結果。如果在事務中使用了WATCH，一旦事務被放棄，EXEC將返回NULL-multi-bulk回復。 |
|
DISCARD |
|
回滾事務隊列中的所有命令，同時再將當前連接的狀態恢復為正常狀態，即非事務狀態。如果WATCH命令被使用，該命令將UNWATCH所有的Keys。 |
始終返回OK。 |
|
WATCHkey [key ...] |
O(1) |
在MULTI命令執行之前，可以指定待監控的Keys，然而在執行EXEC之前，如果被監控的Keys發生修改，EXEC將放棄執行該事務隊列中的所有命令。 |
始終返回OK。 |
|
UNWATCH |
O(1) |
取消當前事務中指定監控的Keys，如果執行了EXEC或DISCARD命令，則無需再手工執行該命令了，因為在此之后，事務中所有被監控的Keys都將自動取消。 |
始終返回OK。 |
三、命令示例：
1. 事務被正常執行：
#在Shell命令行下執行Redis的客戶端工具。
/> redis-cli
#在當前連接上啟動一個新的事務。
redis 127.0.0.1:6379> multi
OK
#執行事務中的第一條命令，從該命令的返回結果可以看出，該命令并沒有立即執行，而是存于事務的命令隊列。
redis 127.0.0.1:6379> incr t1
QUEUED
#又執行一個新的命令，從結果可以看出，該命令也被存于事務的命令隊列。
redis 127.0.0.1:6379> incr t2
QUEUED
#執行事務命令隊列中的所有命令，從結果可以看出，隊列中命令的結果得到返回。
redis 127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1
2. 事務中存在失敗的命令：
#開啟一個新的事務。
redis 127.0.0.1:6379> multi
OK
#設置鍵a的值為string類型的3。
redis 127.0.0.1:6379> set a 3
QUEUED
#從鍵a所關聯的值的頭部彈出元素，由于該值是字符串類型，而lpop命令僅能用于List類型，因此在執行exec命令時，該命令將會失敗。
redis 127.0.0.1:6379> lpop a
QUEUED
#再次設置鍵a的值為字符串4。
redis 127.0.0.1:6379> set a 4
QUEUED
#獲取鍵a的值，以便確認該值是否被事務中的第二個set命令設置成功。
redis 127.0.0.1:6379> get a
QUEUED
#從結果中可以看出，事務中的第二條命令lpop執行失敗，而其后的set和get命令均執行成功，這一點是Redis的事務與關系型數據庫中的事務之間最為重要的差別。
redis 127.0.0.1:6379> exec
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
3) OK
4) "4"
3. 回滾事務：
#為鍵t2設置一個事務執行前的值。
redis 127.0.0.1:6379> set t2 tt
OK
#開啟一個事務。
redis 127.0.0.1:6379> multi
OK
#在事務內為該鍵設置一個新值。
redis 127.0.0.1:6379> set t2 ttnew
QUEUED
#放棄事務。
redis 127.0.0.1:6379> discard
OK
#查看鍵t2的值，從結果中可以看出該鍵的值仍為事務開始之前的值。
redis 127.0.0.1:6379> get t2
"tt"
四、WATCH命令和基于CAS的樂觀鎖：
在Redis的事務中，WATCH命令可用于提供CAS(check-and-set)功能。假設我們通過WATCH命令在事務執行之前監控了多個Keys，倘若在WATCH之后有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Null multi-bulk應答以通知調用者事務執行失敗。例如，我們再次假設Redis中并未提供incr命令來完成鍵值的原子性遞增，如果要實現該功能，我們只能自行編寫相應的代碼。其偽碼如下：
val = GET mykey
val = val + 1
SET mykey $val
以上代碼只有在單連接的情況下才可以保證執行結果是正確的，因為如果在同一時刻有多個客戶端在同時執行該段代碼，那么就會出現多線程程序中經常出現的一種錯誤場景--競態爭用(race condition)。比如，客戶端A和B都在同一時刻讀取了mykey的原有值，假設該值為10，此后兩個客戶端又均將該值加一后set回Redis服務器，這樣就會導致mykey的結果為11，而不是我們認為的12。為了解決類似的問題，我們需要借助WATCH命令的幫助，見如下代碼：
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
和此前代碼不同的是，新代碼在獲取mykey的值之前先通過WATCH命令監控了該鍵，此后又將set命令包圍在事務中，這樣就可以有效的保證每個連接在執行EXEC之前，如果當前連接獲取的mykey的值被其它連接的客戶端修改，那么當前連接的EXEC命令將執行失敗。這樣調用者在判斷返回值后就可以獲悉val是否被重新設置成功。
