糾結了一個下午，在想到底要不要寫這篇文章，理由是這篇文章寫的很棒很細(文章鏈接地址：https://redisbook.readthedocs.io/en/latest/feature/transaction.html)，以至於糾結到現在，當然好在順藤摸瓜，發現了這個網站 -- redis 設計與實現( 鏈接：http://redisbook.com/ )，從源碼角度分析了 redis 各種功能的實現，特此向在學習 redis 的朋友推薦下。這裏從使用的角度說下 redis 事務及使用場景 。
redis 事務
在 redis 中開啓事務用 multi 命令，事務提交用 exec 命令 ，回滾事務用 discard 命令。
127.0.0.1:6379> set wang 100
OK
127.0.0.1:6379> set zhang 900
OK
127.0.0.1:6379> mget zhang wang
1) "900"
2) "100"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby wang 200
QUEUED
127.0.0.1:6379> decrby zhang 200
QUEUED
127.0.0.1:6379>
可以看到，在開啓事務後 ，後面的命令服務端會返回 QUEUED 給客戶端( 前提是該命令是正確的，否則會返回錯誤信息 )，表示該條命令已放到要執行的事務隊列中。
跟傳統關係型數據庫一樣，在事務未提交之前，事務內所作的更改不生效
事務未提交前，在其它客戶端讀取到內容是事務未提交前的值
提交事務 / 回滾事務
這裏着重說下事務提交，redis 事務和傳統數據庫事務是有差別的，在傳統關係型數據庫中事務執行出錯，整個事務回滾，但在redis 中，會跳過出錯命令，繼續往下執行直到該事務執行完畢。
正常事務操作
執行事務過程中出現錯誤
跳過出錯命令，繼續往下執行該事務直到事務執行完畢。
一般語法出錯，redis 會放棄此次事務的執行( 既不會出現此類現象 )，像這種對不恰到的數據類型進行的錯誤操作導致的問題，應該由開發者來自行迴避。
場景
秒殺，搶票。
模擬米9 搶購場景
如果在事務提交前，有人手速比你快，搶走了最後一部mi9
而當你這邊事務提交的後，
會發現，扣款成功了，但你告訴我沒貨了，這尼瑪明顯不合理嘛！！！！！
在redis 事務中，使用樂觀鎖，常配合watch 命令來完成事務操作。
WATCH 命令用於在事務開始之前監視任意數量的鍵： 當調用 EXEC 命令執行事務時， 如果任意一個被監視的鍵已經被其他客戶端修改了， 那麼整個事務不再執行， 直接返回失敗。
既然有watch ，那麼就有unwatch ，unwatch 是取消監視的key 。
下面再模擬一次，搶購場景
嗯，這次雖然沒搶到，但錢款沒扣，只能怪運氣不好嘍。