mysql-redis事務的比較
最近剛好回去看redis的源代碼,不得不說這個源代碼寫的真心不錯,很有味道.剛好之前系統學了MySQL,於是就到了和redis進行對比作爲本週博客主題.
—
mysql acid
提到mysql的事務(transaction),必然要提到無論那那一本數據庫叫教科書裏面必然提到關係型數據庫的acid.這也是記牢數據庫事務的核心
- 原子性（Atomicity）
原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾.實現事務的原子性,要支持回滾操作，在某個操作失敗後，回滾到事務執行之前的狀態。
- 一致性（Consistency）
一致性是指事務必須使數據庫從一個一致的狀態變到另外一個一致的狀態，也就是執行事務之前和之後的狀態都必須處於一致的狀態。MySQL數據庫innodb的事務，是通過redo log（innodb log)，undo log，鎖機制，來維護這個一致性的
在事務T開始時，此時數據庫有一種狀態，這個狀態是所有的MySQL對象處於一致的狀態，例如數據庫完整性約束正確，日誌狀態一致等，當事務T提交後，這時數據庫又有了一個新的狀態，不同的數據，不同的索引，不同的日誌等，但此時，約束，數據，索引，日誌等MySQL各種對象還是要保持一致性（正確性）。 這就是 從一個一致性的狀態，變到另一個一致性的狀態。也就是事務執行後，並沒有破壞數據庫的完整性約束（一切都是對的）。
- 隔離性(Isolation)
隔離性是指當多個用戶併發訪問數據庫時，比如操作同一張表時，數據庫爲每一個用戶開啓的事務，不能被其他事務的操作所幹擾，多個併發事務之間要相互隔離
即要達到這麼一種效果：對於任意兩個併發的事務T1和T2，在事務T1看來，T2要麼在T1開始之前就已經結束，要麼在T1結束之後纔開始，這樣每個事務都感覺不到有其他事務在併發地執行。
- 持久性(Durability)
持久性是指一個事務一旦被提交了，那麼對於數據庫中的數據改變就是永久性的，即便是在數據庫系統遭遇到故障的情況下也不會丟失提交事務的操作。
在提交事務方法後，提示用戶事務操作完成，當我們程序執行完成直到看到提示後，就可以認定事務以及正確提交，即使這時候數據庫出現了問題，也必須要將我們的事務完全執行完成，否則就會造成我們看到提示事務處理完畢，但是數據庫因爲故障而沒有執行事務的重大錯誤。
mysql事務的擴展討論
除卻mysql事務中最基本的acid之外,還需要了解事務的隔離等級,數據庫系統要能進行隔離操作,實質是包括複製環境下的通過日誌如何達成事務.
除此之外還需要了解mysql的鎖機制與日誌機制.本人博客一貫秉持儘量推薦優秀的博客和官方文檔,而不是作者自己似懂非懂瞎幾把寫和複製.關於mysql事務的進一步討論,我推薦讀者自己去閱讀官方文檔,與下面這兩篇博客
- MySQL中事務的實現
- 理解事務 - MySQL 事務處理機制
redis的事務
我們看看redis的事務.
事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。
對於發生在 EXEC 執行之前的錯誤，客戶端以前的做法是檢查命令入隊所得的返回值：如果命令入隊時返回 QUEUED ，那麼入隊成功；否則，就是入隊失敗。如果有命令在入隊時失敗，那麼大部分客戶端都會停止並取消這個事務。
不過，從 Redis 2.6.5 開始，服務器會對命令入隊失敗的情況進行記錄，並在客戶端調用 EXEC 命令時，拒絕執行並自動放棄這個事務。
Redis 不支持回滾（roll back）
redis並不像關係型數據庫那麼複雜(這也是因爲redis非常快的原因,他的每一個操作都是原子化的網絡模型也是io複用不支持多線程,簡單而快速是redis的特性).它的事務和mysql最大的區別就在於不支持回滾.同時由於redis是操作原子化的,每一步操作結束後纔會進行下一步操作,所以也就不需要考慮隔離級別,不需要考慮髒讀.
- Redis 命令只會因爲錯誤的語法而失敗（並且這些問題不能在入隊時發現），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發的過程中被發現，而不應該出現在生產環境中。
- 因爲不需要對回滾進行支持，所以 Redis 的內部可以保持簡單且快速。
關於redis的事務更詳細的介紹我推薦大家閱讀文檔