ACID 中關(guān)于原子性的定義：

原子性：一個(gè)事務(wù)(transaction)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤，會(huì)被恢復(fù)(Rollback)到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)一樣。

[[258328]]

那么 Redis 的事務(wù)到底符不符合原子性的特征呢?官方文檔對(duì)事務(wù)的描述如下：

事務(wù)可以一次執(zhí)行多個(gè)命令， 并且?guī)в幸韵聝蓚€(gè)重要的保證：

• 事務(wù)是一個(gè)單獨(dú)的隔離操作：事務(wù)中的所有命令都會(huì)序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過(guò)程中，不會(huì)被其他客戶(hù)端發(fā)送來(lái)的命令請(qǐng)求所打斷。
• 事務(wù)是一個(gè)原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。
• EXEC 命令負(fù)責(zé)觸發(fā)并執(zhí)行事務(wù)中的所有命令：如果客戶(hù)端在使用 MULTI 開(kāi)啟了一個(gè)事務(wù)之后，卻因?yàn)閿嗑€(xiàn)而沒(méi)有成功執(zhí)行 EXEC ，那么事務(wù)中的所有命令都不會(huì)被執(zhí)行。
• 另一方面，如果客戶(hù)端成功在開(kāi)啟事務(wù)之后執(zhí)行 EXEC ，那么事務(wù)中的所有命令都會(huì)被執(zhí)行。

當(dāng)使用 AOF 方式做持久化的時(shí)候， Redis 會(huì)使用單個(gè) write(2) 命令將事務(wù)寫(xiě)入到磁盤(pán)中。

然而，如果 Redis 服務(wù)器因?yàn)槟承┰虮还芾韱T殺死，或者遇上某種硬件故障，那么可能只有部分事務(wù)命令會(huì)被成功寫(xiě)入到磁盤(pán)中。

如果 Redis 在重新啟動(dòng)時(shí)發(fā)現(xiàn) AOF 文件出了這樣的問(wèn)題，那么它會(huì)退出，并匯報(bào)一個(gè)錯(cuò)誤。

使用 redis-check-aof 程序可以修復(fù)這一問(wèn)題：它會(huì)移除 AOF 文件中不完整事務(wù)的信息，確保服務(wù)器可以順利啟動(dòng)。

但是在另一篇文章寫(xiě)到 Redis 的事務(wù)不是原子性的，他強(qiáng)調(diào)的是 Redis 事務(wù)在執(zhí)行失敗的時(shí)候不會(huì)進(jìn)行任何重試或回滾，因此不具備原子性。

使用事務(wù)可能會(huì)遇到以下兩種錯(cuò)誤。

• 事務(wù)在執(zhí)行 EXEC 之前，入隊(duì)的命令可能會(huì)出錯(cuò)。比如說(shuō)，命令可能會(huì)產(chǎn)生語(yǔ)法錯(cuò)誤(參數(shù)數(shù)量錯(cuò)誤，參數(shù)名錯(cuò)誤，等等)，或者其他更嚴(yán)重的錯(cuò)誤，比如內(nèi)存不足(如果服務(wù)器使用 maxmemory 設(shè)置了***內(nèi)存限制的話(huà))。
• 命令可能在 EXEC 調(diào)用之后失敗。舉個(gè)例子，事務(wù)中的命令可能處理了錯(cuò)誤類(lèi)型的鍵，比如將列表命令用在了字符串鍵上面，諸如此類(lèi)。

示例：

Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 
  
MULTI 
+OK 
  
SET a 3 
abc 
  
+QUEUED 
LPOP a 
  
+QUEUED 
EXEC 
  
*2 
+OK 
-ERR Operation against a key holding the wrong kind of value 

對(duì)于 EXEC 執(zhí)行之前的錯(cuò)誤，Redis 會(huì)檢查出來(lái)并返回錯(cuò)誤自動(dòng)放棄事務(wù)，但是對(duì)于在 EXEC 調(diào)用后執(zhí)行失敗的情況，該條語(yǔ)句會(huì)執(zhí)行失敗，但事務(wù)中的其他命令仍會(huì)執(zhí)行。

因此嚴(yán)格來(lái)說(shuō)，Redis 事務(wù)確實(shí)不具備原子性的特征。

Redis 為什么不支持回滾

如果你有使用關(guān)系式數(shù)據(jù)庫(kù)的經(jīng)驗(yàn)， 那么 “Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾，而是繼續(xù)執(zhí)行余下的命令”這種做法可能會(huì)讓你覺(jué)得有點(diǎn)奇怪。

以下是這種做法的優(yōu)點(diǎn)：

• Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語(yǔ)法而失敗(并且這些問(wèn)題不能在入隊(duì)時(shí)發(fā)現(xiàn))，或是命令用在了錯(cuò)誤類(lèi)型的鍵上面：這也就是說(shuō)，從實(shí)用性的角度來(lái)說(shuō)，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開(kāi)發(fā)的過(guò)程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
• 因?yàn)椴恍枰獙?duì)回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速。

有種觀點(diǎn)認(rèn)為 Redis 處理事務(wù)的做法會(huì)產(chǎn)生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯(cuò)誤帶來(lái)的問(wèn)題。 舉個(gè)例子， 如果你本來(lái)想通過(guò) INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對(duì)錯(cuò)誤類(lèi)型的鍵執(zhí)行了 INCR ， 回滾是沒(méi)有辦法處理這些情況的。

鑒于沒(méi)有任何機(jī)制能避免程序員自己造成的錯(cuò)誤， 并且這類(lèi)錯(cuò)誤通常不會(huì)在生產(chǎn)環(huán)境中出現(xiàn)， 所以 Redis 選擇了更簡(jiǎn)單、更快速的無(wú)回滾方式來(lái)處理事務(wù)。

本文是對(duì)以下參考資料的整理。

參考資料

http://redisdoc.com/topic/transaction.html

http://redisbook.readthedocs.io/en/latest/feature/transaction.html

https://zh.wikipedia.org/wiki/ACID