redis事務是否支持原子性

redis事務是否支持原子性

ACID 中關於原子性的定義:

原子性:一個事務(transaction)中的所有操作,或者全部完成,或者全部不完成,不會結束在中間某個環節。事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。即,事務不可分割、不可約簡。

redis事務測試

使用事務可能會遇到以下兩種錯誤。

  • 事務在執行 EXEC 之前,入隊的命令可能會出錯。比如說,命令可能會產生語法錯誤(參數數量錯誤,參數名錯誤,等等),或者其他更嚴重的錯誤,比如內存不足(如果服務器使用 maxmemory 設置了最大內存限制的話)。
  • 命令可能在 EXEC 調用之後失敗。舉個例子,事務中的命令可能處理了錯誤類型的鍵,比如將列表命令用在了字符串鍵上面,諸如此類。

代碼測試

  • 第一種情況,語句格式語法錯誤,命令入隊時就出錯
127.0.0.1:6379> multi
OK
127.0.0.1:6379> hset test:hash id 10
QUEUED
127.0.0.1:6379> hset test:hash name zhangsan
QUEUED
127.0.0.1:6379> hset test:hash
(error) ERR wrong number of arguments for 'hset' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> hgetall test:hash
(empty list or set)
127.0.0.1:6379>

可以看到這種情況在最後執行exec命令的時候提示事務錯誤,而且查看上面的的hash結構並沒有設置成功

  • 第二種情況,命令入隊時成功,執行時失敗
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 2
QUEUED
127.0.0.1:6379> set c 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
127.0.0.1:6379> get a
"1"
127.0.0.1:6379> get b
"2"
127.0.0.1:6379> get c
"3"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 11
QUEUED
127.0.0.1:6379> lpush b 22 22 33 44
QUEUED
127.0.0.1:6379> set c 33
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get a
"11"
127.0.0.1:6379> get b
"2"
127.0.0.1:6379> get c
"33"

我們可以看到“lpush b 22 22 33 44”命令之前的“set a 11”、“set c 33”都執行成功了

對於 EXEC 執行之前的錯誤,Redis 會檢查出來並返回錯誤自動放棄事務,但是對於在 EXEC 調用後執行失敗的情況,該條語句會執行失敗,但事務中的其他命令仍會執行。

因此嚴格來說,Redis 事務確實不具備原子性的特徵。

爲什麼Redis不支持回滾?

如果你有使用關係式數據庫的經驗, 那麼 “Redis 在事務失敗時不進行回滾,而是繼續執行餘下的命令”這種做法可能會讓你覺得有點奇怪。

以下是這種做法的優點:

  • Redis 命令只會因爲錯誤的語法而失敗(並且這些問題不能在入隊時發現),或是命令用在了錯誤類型的鍵上面:這也就是說,從實用性的角度來說,失敗的命令是由編程錯誤造成的,而這些錯誤應該在開發的過程中被發現,而不應該出現在生產環境中。
  • 因爲不需要對回滾進行支持,所以 Redis 的內部可以保持簡單且快速。

有種觀點認爲 Redis 處理事務的做法會產生 bug , 然而需要注意的是, 在通常情況下, 回滾並不能解決編程錯誤帶來的問題。 舉個例子, 如果你本來想通過 INCR 命令將鍵的值加上 1 , 卻不小心加上了 2 , 又或者對錯誤類型的鍵執行了 INCR , 回滾是沒有辦法處理這些情況的。

鑑於沒有任何機制能避免程序員自己造成的錯誤, 並且這類錯誤通常不會在生產環境中出現, 所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務。

參考資料:https://redis.io/topics/transactions

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章