Redis 的事務到底是不是原子性的
ACID 中關于原子性的定義：
原子性：一個事務(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被恢復(Rollback)到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
那么 Redis 的事務到底符不符合原子性的特征呢?官方文檔對事務的描述如下：
事務可以一次執行多個命令， 并且帶有以下兩個重要的保證：
- 事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。
- 事務是一個原子操作：事務中的命令要么全部被執行，要么全部都不執行。
- EXEC 命令負責觸發并執行事務中的所有命令：如果客戶端在使用 MULTI 開啟了一個事務之后，卻因為斷線而沒有成功執行 EXEC ，那么事務中的所有命令都不會被執行。
- 另一方面，如果客戶端成功在開啟事務之后執行 EXEC ，那么事務中的所有命令都會被執行。
當使用 AOF 方式做持久化的時候， Redis 會使用單個 write(2) 命令將事務寫入到磁盤中。
然而，如果 Redis 服務器因為某些原因被管理員殺死，或者遇上某種硬件故障，那么可能只有部分事務命令會被成功寫入到磁盤中。
如果 Redis 在重新啟動時發現 AOF 文件出了這樣的問題，那么它會退出，并匯報一個錯誤。
使用 redis-check-aof 程序可以修復這一問題：它會移除 AOF 文件中不完整事務的信息，確保服務器可以順利啟動。
但是在另一篇文章寫到 Redis 的事務不是原子性的，他強調的是 Redis 事務在執行失敗的時候不會進行任何重試或回滾，因此不具備原子性。
使用事務可能會遇到以下兩種錯誤。
- 事務在執行 EXEC 之前，入隊的命令可能會出錯。比如說，命令可能會產生語法錯誤(參數數量錯誤，參數名錯誤，等等)，或者其他更嚴重的錯誤，比如內存不足(如果服務器使用 maxmemory 設置了***內存限制的話)。
- 命令可能在 EXEC 調用之后失敗。舉個例子，事務中的命令可能處理了錯誤類型的鍵，比如將列表命令用在了字符串鍵上面，諸如此類。
示例：
- 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
對于 EXEC 執行之前的錯誤，Redis 會檢查出來并返回錯誤自動放棄事務，但是對于在 EXEC 調用后執行失敗的情況，該條語句會執行失敗，但事務中的其他命令仍會執行。
因此嚴格來說，Redis 事務確實不具備原子性的特征。
Redis 為什么不支持回滾
如果你有使用關系式數據庫的經驗， 那么 “Redis 在事務失敗時不進行回滾，而是繼續執行余下的命令”這種做法可能會讓你覺得有點奇怪。
以下是這種做法的優點：
- Redis 命令只會因為錯誤的語法而失敗(并且這些問題不能在入隊時發現)，或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發的過程中被發現，而不應該出現在生產環境中。
- 因為不需要對回滾進行支持，所以 Redis 的內部可以保持簡單且快速。
有種觀點認為 Redis 處理事務的做法會產生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤類型的鍵執行了 INCR ， 回滾是沒有辦法處理這些情況的。
鑒于沒有任何機制能避免程序員自己造成的錯誤， 并且這類錯誤通常不會在生產環境中出現， 所以 Redis 選擇了更簡單、更快速的無回滾方式來處理事務。
本文是對以下參考資料的整理。
參考資料
http://redisdoc.com/topic/transaction.html
http://redisbook.readthedocs.io/en/latest/feature/transaction.html
https://zh.wikipedia.org/wiki/ACID
