Redis 事務

用Multi(Start Transaction)、Exec(Commit)、Discard(Rollback)實現。 在事務提交前，不會執(zhí)行任何指令，只會把它們存到一個隊列里，不影響其他客戶端的操作。在事務提交時，批量執(zhí)行所有指令。 一般情況下redis在接受到一個client發(fā)來的命令后會立即處理并返回處理結果，但是當一個client在一個連接中發(fā)出multi命令后，這個連接會進入一個事務上下文，該連接后續(xù)的命令并不是立即執(zhí)行，而是先放到一個隊列中。當從此連接受到exec命令后，redis會順序的執(zhí)行隊列中的所有命令。并將所有命令的運行結果打包到一起返回給client.然后此連接就結束事務上下文。

Redis還提供了一個Watch功能，你可以對一個key進行Watch，然后再執(zhí)行Transactions，在這過程中，如果這個Watched的值進行了修改，那么這個Transactions會發(fā)現并拒絕執(zhí)行。

使用discard命令來取消一個事務。

注意：redis只能保證事務的每個命令連續(xù)執(zhí)行（因為是單線程架構，在執(zhí)行完事務內所有指令前是不可能再去同時執(zhí)行其他客戶端的請求的，也因此就不存在"事務內的查詢要看到事務里的更新，在事務外查詢不能看到"這個讓人萬分頭痛的問題），但是如果事務中的一個命令失敗了，并不回滾其他命令。另外，一個十分罕見的問題是當事務的執(zhí)行過程中，如果redis意外的掛了。只有部分命令執(zhí)行了，后面的也就被丟棄了。注意，如果是筆誤，語法出現錯誤，則整個事務都無法執(zhí)行。

一個簡單案例表明出錯也不會回滾：

127.0.0.1:6379> del q1
(integer) 0
127.0.0.1:6379> exists q1
(integer) 0
127.0.0.1:6379> multi
OK
127.0.0.1:6379> rpush q1 bar
QUEUED
127.0.0.1:6379> scard q1
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> exists q1
(integer) 1

當然如果我們使用的append-only file方式持久化，redis會用單個write操作寫入整個事務內容。即是是這種方式還是有可能只部分寫入了事務到磁盤。發(fā)生部分寫入事務的情況下，redis重啟時會檢測到這種情況，然后失敗退出?？梢允褂胷edis-check-aof工具進行修復，修復會刪除部分寫入的事務內容。修復完后就能夠重新啟動了。