概述
相信學過Mysql等其他數據庫的同學對事務這個詞都不陌生，事務表示的是壹組動作，這組動作要麽全部執行，要麽全部不執行。為什麽會有這樣的需求呢？看看下面的場景：
微博是壹個弱關系型社交網絡，用戶之間有關註和被關註兩種關系，比如兩個用戶A和B，如果A關註B，則B的粉絲中就應該有A。關註這個動作需要兩個步驟完成：在A的關註者中添加B；在B的粉絲中添加A。 這兩個動作要麽都執行成功，要麽都不執行。否則就可能會出現A關註了B，但是B的粉絲中沒有A的不可容忍的情況。
轉賬匯款，假設現在有兩個賬戶A和B，現在需要將A中的壹萬塊大洋轉到B的賬戶中，這個動作也需要兩個步驟完成：從A的賬戶中劃走壹萬塊；在B的賬戶中增加壹萬塊。這兩個動作要麽全部執行成功，要麽全部不執行，否則自會有人問候妳的！！！
Redis作為壹種高效的分布式數據庫，同樣支持事務。
Redis事務
Redis中的事務(transaction)是壹組命令的集合。事務同命令壹樣都是Redis最小的執行單位，壹個事務中的命令要麽都執行，要麽都不執行。Redis事務的實現需要用到?MULTI?和?EXEC?兩個命令，事務開始的時候先向Redis服務器發送?MULTI?命令，然後依次發送需要在本次事務中處理的命令，最後再發送?EXEC?命令表示事務命令結束。
舉個例子，使用redis-cli連接redis，然後在命令行工具中輸入如下命令：
1234567891011121314151617181920
127.0.0.1:6379> MULTIOK127.0.0.1:6379> set url g.meQUEUED127.0.0.1:6379> set title winwill2012QUEUED127.0.0.1:6379> set desc javaQUEUED127.0.0.1:6379> EXEC1) OK2) OK3) OK127.0.0.1:6379>127.0.0.1:6379> get url"h.me"127.0.0.1:6379> get title"winwill2012"127.0.0.1:6379> get desc"java"127.0.0.1:6379>
從輸出中可以看到，當輸入MULTI命令後，服務器返回OK表示事務開始成功，然後依次輸入需要在本次事務中執行的所有命令，每次輸入壹個命令服務器並不會馬上執行，而是返回”QUEUED”，這表示命令已經被服務器接受並且暫時保存起來，最後輸入EXEC命令後，本次事務中的所有命令才會被依次執行，可以看到最後服務器壹次性返回了三個OK，這裏返回的結果與發送的命令是按順序壹壹對應的，這說明這次事務中的命令全都執行成功了。
再舉個例子，在命令行工具中輸入如下命令：
1234567891011121314151617
127.0.0.1:6379> MULTIOK127.0.0.1:6379> set a aQUEUED127.0.0.1:6379> sett b b(error) ERR unknown command 'sett'127.0.0.1:6379> set c cQUEUED127.0.0.1:6379> EXEC(error) EXECABORT Transaction discarded because of previous errors.127.0.0.1:6379> get a(nil)127.0.0.1:6379> get b(nil)127.0.0.1:6379> get c(nil)127.0.0.1:6379>
和前面的例子壹樣，先輸入MULTI最後輸入EXEC表示中間的命令屬於壹個事務，不同的是中間輸入的命令有壹個錯誤(set寫成了sett)，這樣因為有壹個錯誤的命令導致事務中的其他命令都不執行了(通過後續的get命令可以驗證)，可見事務中的所有命令式同呼吸***命運的。
如果客戶端在發送EXEC命令之前斷線了，則服務器會清空事務隊列，事務中的所有命令都不會被執行。而壹旦客戶端發送了EXEC命令之後，事務中的所有命令都會被執行，即使此後客戶端斷線也沒關系，因為服務器已經保存了事務中的所有命令。
除了保證事務中的所有命令要麽全執行要麽全不執行外，Redis的事務還能保證壹個事務中的命令依次執行而不會被其他命令插入。試想壹個客戶端A需要執行幾條命令，同時客戶端B發送了幾條命令，如果不使用事務，則客戶端B的命令有可能會插入到客戶端A的幾條命令中，如果想避免這種情況發生，也可以使用事務。
Redis事務錯誤處理
如果壹個事務中的某個命令執行出錯，Redis會怎樣處理呢？要回答這個問題，首先要搞清楚是什麽原因導致命令執行出錯：
語法錯誤?就像上面的例子壹樣，語法錯誤表示命令不存在或者參數錯誤
這種情況需要區分Redis的版本，Redis 2.6.5之前的版本會忽略錯誤的命令，執行其他正確的命令，2.6.5之後的版本會忽略這個事務中的所有命令，都不執行，就比如上面的例子(使用的Redis版本是2.8的)
運行錯誤?運行錯誤表示命令在執行過程中出現錯誤，比如用GET命令獲取壹個散列表類型的鍵值。
這種錯誤在命令執行之前Redis是無法發現的，所以在事務裏這樣的命令會被Redis接受並執行。如果食物裏有壹條命令執行錯誤，其他命令依舊會執行（包括出錯之後的命令）。比如下例：
1234567891011121314
127.0.0.1:6379> MULTIOK127.0.0.1:6379> set key 1QUEUED127.0.0.1:6379> SADD key 2QUEUED127.0.0.1:6379> set key 3QUEUED127.0.0.1:6379> EXEC1) OK2) (error) WRONGTYPE Operation against a key holding the wrong kind of value3) OK127.0.0.1:6379> get key"3"
Redis中的事務並沒有關系型數據庫中的事務回滾(rollback)功能，因此使用者必須自己收拾剩下的爛攤子。不過由於Redis不支持事務回滾功能，這也使得Redis的事務簡潔快速。
回顧上面兩種類型的錯誤，語法錯誤完全可以在開發的時候發現並作出處理，另外如果能很好地規劃Redis數據的鍵的使用，也是不會出現命令和鍵不匹配的問題的。
WATCH命令
從上面的例子我們可以看到，事務中的命令要全部執行完之後才能獲取每個命令的結果，但是如果壹個事務中的命令B依賴於他上壹個命令A的結果的話該怎麽辦呢？就比如說實現類似Java中的i++的功能，先要獲取當前值，才能在當前值的基礎上做加壹操作。這種場合僅僅使用上面介紹的MULTI和EXEC是不能實現的，因為MULTI和EXEC中的命令是壹起執行的，並不能將其中壹條命令的執行結果作為另壹條命令的執行參數，所以這個時候就需要引進Redis事務家族中的另壹成員：WATCH命令
換個角度思考上面說到的實現i++的方法，可以這樣實現：
監控i的值，保證i的值不被修改
獲取i的原值
如果過程中i的值沒有被修改，則將當前的i值+1，否則不執行
這樣就能夠避免競態條件，保證i++能夠正確執行。
WATCH命令可以監控壹個或多個鍵，壹旦其中有壹個鍵被修改（或刪除），之後的事務就不會執行，監控壹直持續到EXEC命令（事務中的命令是在EXEC之後才執行的，EXEC命令執行完之後被監控的鍵會自動被UNWATCH）
舉個例子：
123456789101112131415
127.0.0.1:6379> set mykey 1OK127.0.0.1:6379> WATCH mykeyOK127.0.0.1:6379> set mykey 2OK127.0.0.1:6379> MULTIOK127.0.0.1:6379> set mykey 3QUEUED127.0.0.1:6379> EXEC(nil)127.0.0.1:6379> get mykey"2"127.0.0.1:6379>
上面的例子中，首先設置mykey的鍵值為1，然後使用WATCH命令監控mykey，隨後更改mykey的值為2，然後進入事務，事務中設置mykey的值為3，然後執行EXEC運行事務中的命令，最後使用get命令查看mykey的值，發現mykey的值還是2，也就是說事務中的命令根本沒有執行（因為WATCH監控mykey的過程中，mykey被修改了，所以隨後的事務便會被取消）。
有了WATCH命令，我們就可以自己實現i++功能了，偽代碼如下：
1234567891011
def incr($key): WATCH $key $value = GET $key if not $value $value = 0 $value = $value + 1 MULTI SET $key $value result = EXEC return result[0]
因為EXEC返回的是多行字符串，使用result[0]表示返回值的第壹個字符串。
註意：由於WATCH命令的作用只是當被監控的鍵被修改後取消之後的事務，並不能保證其他客戶端不修改監控的值，所以當EXEC命令執行失敗之後需要手動重新執行整個事務。
執行EXEC命令之後會取消監控使用WATCH命令監控的鍵，如果不想執行事務中的命令，也可以使用UNWATCH命令來取消監控。