是什么
-
事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行，事務在執行的程序中，不會被其他客戶端發送來的命令請求所打斷，
-
事務是一個原子操作：事務中的命令要么全部被執行，要么全部都不執行，
Redis事務的三個階段
- 開始事務
- 命令入隊
- 執行事務
Redis 事務相關的命令及用法
MULTI 、 EXEC 、 DISCARD 和 WATCH
MULTI命令用于開啟一個事務，它總是回傳 OK ， MULTI 執行之后， 客戶端可以繼續向服務器發送任意多條命令， 這些命令不會立即被執行， 而是被放到一個佇列中， 當 EXEC命令被呼叫時， 所有佇列中的命令才會被執行，
DISCARD通過呼叫 DISCARD ， 客戶端可以清空事務佇列， 并放棄執行事務，
WATCH命令可以為 Redis 事務提供 check-and-set （CAS）行為，相當于加樂觀鎖，被 WATCH 的鍵會被監視，并會發覺這些鍵是否被改動過了， 如果有至少一個被監視的鍵在 EXEC 執行之前被修改了， 那么整個事務都會被取消， EXEC 回傳nil-reply來表示事務已經失敗，
EXEC命令負責觸發并執行事務中的所有命令：
- 如果客戶端在使用 MULTI開啟了一個事務之后，卻因為斷線而沒有成功執行EXEC ，那么事務中的所有命令都不會被執行，
- 另一方面，如果客戶端成功在開啟事務之后執行 EXEC，那么事務中的所有命令都會被執行，
事務中的錯誤
-
若在事務佇列中存在命令性錯誤，則執行EXEC命令時，所有命令都不會執行
-
若在事務佇列中存在語法性錯誤，則執行EXEC命令時，其他正確命令會被執行，錯誤命令拋出例外，
為什么 Redis 不支持回滾（roll back）
如果你有使用關系式資料庫的經驗， 那么 “Redis 在事務失敗時不進行回滾，而是繼續執行余下的命令”這種做法可能會讓你覺得有點奇怪，
以下是這種做法的優點：
- Redis 命令只會因為錯誤的語法而失敗（并且這些問題不能在入隊時發現），或是命令用在了錯誤型別的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發的程序中被發現，而不應該出現在生產環境中，
- 因為不需要對回滾進行支持，所以 Redis 的內部可以保持簡單且快速，
有種觀點認為 Redis 處理事務的做法會產生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯誤帶來的問題， 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤型別的鍵執行了 INCR ， 回滾是沒有辦法處理這些情況的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/196105.html
標籤：其他