原子性(Atomicity)
原子意味著操作的不可再分，要麼執行要麼不執行。Redis 本身提供的所有 API 都是原子操作，那麼 Redis 事務其實是要保證批量操作的原子性。Redis 實現批量操作的原理是在一個事務上下文中（通過 MULTI命令開啟），所有提交的操作請求都先被放入佇列中快取，在 EXEC 命令提交時一次性批量執行。這樣保證了批量操作的一次性執行過程，但 Redis 在事務執行過程的錯誤情況做出了權衡取捨，那就是放棄了回滾。
Redis 官方文件對此給出的解釋是：

1. Redis 操作失敗的原因只可能是語法錯誤或者錯誤的資料庫型別操作，這些都是在開發層面能發現的問題不會進入到生產環境，因此不需要回滾。
2. Redis 內部設計推崇簡單和高效能，因此不需要回滾能力。

據實而說第一條說法感覺有點站不住腳，可以想象得到 Redis 操作失敗的原因絕對不止語法層面的錯誤，特別是一些像依賴作業系統、檔案系統的操作。第二條說法更實在，Redis 的應用場景明顯不是為了資料儲存的高可靠而設計的，而是為了資料訪問的高效能而設計，設計者為了簡單性和高效能而部分放棄了原子性。 出於以上考慮 Redis 的事務執行有以下特點：

1. 批量操作在傳送 EXEC 命令前被放入佇列快取
2. 收到 EXEC 命令後進入事務執行，事務中任意命令執行失敗，其餘的命令依然被執行
3. 在事務執行過程，其他客戶端提交的命令請求不會插入到事務執行命令序列中

一致性(Consistency) 一致性意味著事務結束後系統的資料依然保證一致。在事務開始之前，資料保持有效的狀態，事務結束後也如此。顯然在前面討論原子性時，Redis 捨棄了回滾的設計，基本上也就捨棄對資料一致性的有效保證。不過對於一個高效的 key-value store 或 data structure server，資料操作一致性很多時候更多應該依賴應用層面，事實也是我們使用 Redis 時很多時候都是分片和叢集的，資料一致性無法依靠任何事務機制。 隔離性(Isolation) 隔離性保證了在事務完成之前，該事務外部不能看到事務裡的資料改變。也不能訪問一些中間狀態，因為假如事務終止的話，這些狀態將永遠不會發生。

Redis 採用單執行緒設計，在一個事務完成之前，其他客戶端提交的各種操作都無法執行因此自然沒法看見事務執行的中間狀態，隔離性得到保證。 永續性(Durability) Redis 一般情況下都只進行記憶體計算和操作，永續性無法保證。但 Redis 也提供了2種資料持久化模式，SNAPSHOT 和 AOF，SNAPSHOT的持久化操作與命令操作是不同步的，無法保證事務的永續性。而AOF模式意味著每條命令的執行都需要進行系統呼叫操作磁碟寫入檔案，可以保證永續性，但會大大降低 Redis 的訪問效能。 Redis 在2.6版本開始提供指令碼（Lua scripting）能力，一種更靈活的批量命令組織方式用於取代目前的事務機制。指令碼提供了更強大和靈活的程式設計能力，但也是一把雙刃劍，由於 Redis 需要保證指令碼執行的原子性和隔離性，指令碼執行期間會阻塞其他命令的執行，因此建議寫一些高效的指令碼。不過從開發者的角度來說使用Lua指令碼的成本（學習成本、開發成本、維護成本）都要更大，特別是一些開發者如果將應用的業務邏輯放入指令碼中來執行，是不是讓人想起了資料庫的儲存過程。