Redis事務控制
1、Redis事務控制的相關命令匯總
| 命令名 | 作用 |
|---|---|
| MULTI | 表示開始收集命令，后面所有命令都不是馬上執行，而是加入到一個隊列中。 |
| EXEC | 執行MULTI后面命令隊列中的所有命令。 |
| DISCARD | 放棄執行隊列中的命令。 |
| WATCH | “觀察”、“監控”一個KEY,在當前隊列外的其他命令操作這個KEY時，放棄執行自己隊列的命令 |
| UNWATCH | 放棄監控一個KEY |
我們先測試一下
MULTI
SET number 100
INCR number
EXEC
執行效果如下所示：
當我們執行中間出錯時，整個事務都會失敗而且回滾。
這里如果我們之前學過數據庫的話，應該覺得很正常
但是當我們執行以下命令時
MULTI
SET number 1000
incr number
incr number
incriby number aaa
exec
運行結果如下
我們會發現整個事務並沒有回滾
對於此官方解釋了：
如果你有使用關系式數據庫的經驗， 那么 “Redis 在事務失敗時不進行回滾，而是繼續執行余下的命令”這種做法可能會讓你覺得有點奇怪。以下是這種做法的優點：
Redis 命令只會因為錯誤的語法而失敗（並且這些問題不能在入隊時發現），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發的過程中被發現，而不應該出現在生產環境中。
因為不需要對回滾進行支持，所以 Redis 的內部可以保持簡單且快速。
有種觀點認為 Redis 處理事務的做法會產生 bug ， 然而需要注意的是， 在通常情況下， 回滾並不能解決編程錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤類型的鍵執行了 INCR ， 回滾是沒有辦法處理這些情況的。
因我我們需要加強對生產環境中的錯誤異常處理
2、Redis樂觀鎖的體現
我們先來執行以下代碼
set num 100
get num
watch num
MULTI
incr num
incr num
get num
然后我們新開一個客戶端，設置了一下num的值
然后在剛才的界面執行EXEC
這時候我們會發現命令執行失敗了，整個事務回滾了。
這就是一個樂觀鎖的體現，
簡而言之就是、如果別人在我的隊列命令執行之前，修改了我的數據，那我就直接放棄了。
樂觀鎖和悲觀鎖需要依據具體的實現進行使用
- 悲觀鎖（數據庫中的行鎖和表鎖）
- 認為當前環境非常容易發生碰撞，所以執行操作前需要把數據鎖定，操作完成后釋放鎖其他操作才能繼續進行操作。
- 樂觀鎖
- 認為當前環境不容易發生碰撞，所以執行操作前不鎖定數據，萬一碰撞真的發生了，那么放棄自己的操作
Redis 內只有樂觀鎖，並無悲觀鎖，因為Redis對性能的要求很高。