Table of Contents

事務處理

• ACID 理論。作者認為 A I D 是手段，C 是目的；前者是因，後者是果:
  • Consistency (一致性): 保證系統中所有數據都是符合期望，且相互關聯的數據之間不會產生矛盾。
  • Atomic (原子性): 對多個數據的修改，要嘛同時成功，要嘛同時失敗。
  • Isolation (隔離性): 各自業務在讀寫數據時都相互獨立，不會彼此影響。
  • Durability (持久性): 所有成功提交的數據修改都能正確地被持久化，不丟失數據。
• 所有需要保證數據一致性的應用場景，包括但不限於數據庫、事務內存、緩存、消息對列、分布式存儲等等，都可能會應用到事務 (Transaction)。
• 內部一致性：併發事務的讀寫在時間上的最終順序都是由數據源來確定的。
• 外部一致性：併發執行甚至是先後執行的多個事務，在時間上的順序並不由任何一個數據源來決定。

本地事務 (Local Transaction)

• “本地事務” 是指僅操作單一事務資源的、不需要全局事務管理器進行協調的事務。
  • 只適用於單個服務使用單個數據源的場景。
  • 直接依賴於數據源本身提供的事務能力來工作。
• “ARIES” 是現代數據庫的基礎理論。

實現原子性和持久性

• 原子性保證了事務的多個操作要嘛都生效、要嘛都不生效，不會存在中間狀態。持久性保證了一旦事務生效，就不會再因為任何原因而導致其修改的內容被撤銷或丟失。
• 如何實現 “持久性” ？：必須要成功寫入磁盤、磁帶等持久化存儲器。
• 實現原子性與持久性最大的困難：“寫入磁盤” 這個操作不是原子的，不僅有 “寫入” 與 “未寫入” 的狀態，還客觀的存在 “正在寫” 的中間狀態。
  • 未提交事務，寫入後崩潰：
    • 程式還沒修改完數據，數據庫已經寫入磁盤，此時出現崩潰，數據庫要有辦法得知崩潰前發生過一次不完整的操作，將已修改過的數據從磁盤中恢復成沒有改過的樣子。
    • 保證原子性。
  • 已提交事務，寫入前崩潰：
    • 程式修改完數據，但數據庫還沒寫入磁盤，此時出現崩潰，數據庫要有辦法得知崩潰前發生過一次完整的操作，將還沒來得及寫入磁盤的部分數據重新寫入。
    • 保證持久性。
• 由於寫入中間狀態與崩潰都是無法避免的，為了保證原子性和持久性，只能在崩潰後採取恢復的補救措施，這種數據恢復的操作稱為 “崩潰恢復 (Crash Recovery)”。
• 提交日誌 (Commit Logging):
  • 將修改數據這個操作所需的全部訊息，以日誌的形式先記錄到磁盤中。只有在日誌記錄全部都安全落盤，數據庫在日誌中看到代表事務成功提交的 “提交紀錄 (Commit Record)”，才會根據日誌上的訊息對真正的數據進行修改。修改完成後，在日誌中加入一條 “結束紀錄 (End Record)” 表示事務已完成持久化。
  • 先天缺點：所有對數據的真實修改都必須發生在事務提交之後。對於提升數據庫的性能十分不利。
• 為了解決上面那個問題，ARIES 提出 “Write-Ahead (提前寫入) Logging” 的改進方案。就是允許在事務提交之前，提前寫入變動數據。
  • FORCE: 當事務提交後，要求數據變動必須同時完成寫入。
  • NO-FORCE: 當事務提交後，不強制變動數據必須同時完成寫入。(現實中大多數的數據庫都是用這個策略)
  • STEAL: 當事務提交前，允許變動數據提前寫入。(有利於利用空閑的 I/O 資源，也有利於節省數據庫緩存區的內存)
  • NO-STEAL: 當事務提交前，不允許變動數據提前寫入。