1. 副本集事務實現(4.0+)?
- ?非嚴格依賴二階段提交?
MongoDB 4.0 在副本集環境中通過 ?全局邏輯時鐘(Logical Clock)? 和 ?快照隔離(Snapshot Isolation)? 實現多文檔事務,事務提交時通過原子性協議(如 Raft 共識算法)協調副本集成員,而非傳統 2PC 模式?。
事務提交時,主節點將事務操作日志(?oplog 條目?)廣播至副本集成員。成員需通過 ?多數派確認協議?(類似 Raft 的日志復制機制)達成共識,確保日志持久化后才標記事務為已提交?。 - ?ACID 保障?
事務操作在提交時通過 WiredTiger 存儲引擎的 MVCC(多版本并發控制)和日志持久化機制,確保原子性和持久性,且讀操作基于一致性快照?。
2. 分片集群事務實現(4.2+)?
- ?依賴二階段提交?
4.2 版本引入的分布式事務(跨分片操作)需通過 ?兩階段提交協議? 協調多個分片:- ?準備階段?:各分片節點預提交事務并記錄狀態;
- ?提交階段?:事務協調器確認所有分片就緒后,全局提交事務?。
- ?擴展性優化?
通過減少跨節點鎖競爭和優化狀態管理,降低 2PC 對性能的影響,但跨分片事務仍存在更高的延遲?
?
然而,MySQL 的 MVCC 機制 ?會保留舊版本數據?,但其實現方式與 MongoDB 存在顯著差異。以下從底層設計、數據存儲與清理角度解釋其工作原理:
3. MVCC 的核心機制:undo log 與版本鏈?
- ?舊版本數據存儲方式?
MySQL InnoDB 引擎通過 ?undo log(回滾日志)? 保留舊版本數據。每次更新操作時,原始數據會被復制到 undo log 中形成版本鏈,新數據直接寫入主數據頁?13。
示例:事務 A 修改某行數據時,該行原始值會被寫入 undo log,新值更新到主數據頁,形成兩個版本。 - ?版本可見性規則?
事務通過 ?Read View?(一致性視圖)判斷可見性。每個事務啟動時生成一個 Read View,記錄當前活躍事務 ID 列表,僅能讀取 ?已提交且版本時間戳 ≤ 事務快照時間戳? 的數據?。 - ?2. 舊版本數據的生命周期?
- ?臨時性保留?
舊版本數據僅在 ?活躍事務需要訪問? 時保留。例如,若事務 B 在事務 A 提交前啟動,事務 B 需通過 undo log 讀取事務 A 修改前的舊版本數據?。 - ?自動清理機制?
InnoDB 后臺的 ?purge 線程? 會定期清理 ?無活躍事務依賴的舊版本數據?(如 undo log 中已提交且無其他事務引用的舊記錄),避免長期堆積導致存儲膨脹?。
?4. 用戶感知的“未保留舊數據”現象?
- ?快速清理與隱式存儲?
由于 undo log 的設計,舊版本數據對用戶透明(不直接體現在數據文件中),且清理效率高。用戶通常感知不到舊版本的存在,誤認為 MySQL 未保留舊數據?。 - ?與 MongoDB 的差異?
MongoDB 的 WiredTiger 引擎通過 ?顯式版本鏈? 存儲舊數據(如 B+ 樹多版本節點),而 MySQL 依賴 ?undo log 的日志結構? 實現版本管理,兩者底層存儲方式不同?。
6. MongoDB 事務有沒有像MySQL一樣,實現WAL(Journal 日志) 和oplog 的二階段提交?
因為Journal 和?oplog 沒有能聯系起來的標識位(xid).
?6.1. WAL(Write-Ahead Logging)的作用?
- ?存儲引擎層持久化?
MongoDB 的 WiredTiger 存儲引擎通過 WAL(Journal 日志)?實現數據持久化。所有事務操作會先寫入 WAL 日志,確保在崩潰恢復時能通過重放日志恢復未提交的事務或已提交但未落盤的數據?。 - ?檢查點機制?
WiredTiger 定期(默認每分鐘)創建檢查點(Checkpoint),將內存中的臟頁(Dirty Page)批量寫入磁盤,并清理已持久化的 WAL 日志,減少恢復時間?。
?6.2. oplog 的副本集同步機制?
- ?操作日志(oplog)的核心功能?
oplog 是 MongoDB 副本集的核心組件,記錄所有數據變更操作(如插入、更新、刪除)。事務提交時,主節點將事務內的操作打包為 ?原子性 oplog 條目? 廣播至副本集成員,成員通過重放 oplog 實現數據同步?。 - ?原子性提交協議?
事務提交依賴 ?多數派確認機制?(類似 Raft 的日志復制流程),而非傳統 2PC。主節點需等待多數副本集成員確認 oplog 持久化后,才標記事務為已提交,確保數據一致性?。