我們都知道，OceanBase 是一個分布式數據庫，數據是打散到多臺服務器上的，當一個分布式事務要執行的時候，可能需要跨越多臺 OB Server，如果在執行過程中遇到各種各樣的異常情況，OceanBase 是如何確保 ACID 呢？這一章節我們就一起探討下。

首先介紹下 ACID。事務指邏輯上的一組操作，這些操作要么全部成功，要么全部不成功。典型場景就是轉賬，A 賬戶的扣減，與 B 賬戶的增加，必須一起完成或者都不完成。事務有ACID，四個基本要素：?A 指原子性，需要保證操作都發生或都不發生。這在傳統集中式數據庫中比較容易實現，因為不存在跨機操作的風險，如果服務器故障了，所有的操作都不會完成，一般不會出現部分提交的現象。
但在分布式環境中就比較復雜，一個事務 10 條 sql 語句，涉及 8 個分區，極端情況下，這 8 個分區的主副本可能分布在 8 臺服務器上，萬一出現一些異常，有些完成了，有些沒有完成，都會影響事務的原子性。OceanBase 是用兩階段提交協議保證原子性的。C 是指一致性，是指事務前后數據的完整性必須保持一致。OceanBase 通過保證主鍵唯一，全局快照等技術保證一致性。?I 是指隔離性，是指多個用戶并發訪問數據庫時，數據庫為每個用戶開啟的事務，不能被其他事務的操作所干擾。比如一個事務正在修改某個字段，這個字段是否允許其他事務讀或者寫呢？OceanBase 采用 MVCC 技術解決讀寫互斥的問題。D 是指持久性，一個事務一旦被成功提交，它對數據庫中數據的改變就是永久性的，即使數據庫發生故障也不應該對其有任何影響。這塊我們之前重點講了，OceanBase 使用 Paxos協議，通過在多副本之間同步 Redo-Log 和 Redo-Log 落盤來確保數據的持久性。接下來我們重點講下，A 和 I，即 OceanBase 如何在分布式場景下，保證事務的原子性和隔離性。

????首先看下如何保障 A，原子性。如果一個事務有 10 條 SQL 語句，涉及 8 個分區，極端情況下，這 8 個分區可能分布到 8 臺服務器上，這時就是分布式事務了。

對于應用而言，是否需要應用知道分區具體分布到哪臺服務器上，是不是需要應用采取一些技術手段，如兩階段提交，來保證事務的 ACID。答案是不需要的，對于 OceanBase 而言，OceanBase 內部是典型的分布式場景，很復雜。對外，對應用開發者來說，是一個簡單的一階段事務的場景，應用只要開啟事務，執行 10 條 SQL 語句，提交事務或者回滾事務即可，跟使用一個集中式數據庫差異不大。?

OceanBase 內部使用兩階段提交方式來保證事務的原子性，兩階段提交有兩個重要角色，協調者和參與者。兩階段的第一階段是投票階段，協調者向所有參與者發送 Prepare 請求與事務內容，詢問是否可以準備事務，并等待參與者的響應。參與者執行事務中的操作，向協調者返回事務操作的執行結果；兩階段的第二階段是執行階段，如果所有參與者都返回 OK，協調者向所有參與者發送提交請求，參與者收到后，完成事務的提交，并返回給協調者。協調者收到所有參與者的消息后，完成事務，返回給應用。如果有任何一個參與者返回 no 或者超時未返回，則需要回滾。那么在 OceanBase 內部，誰是參與者？誰是協調者呢？需要澄清的是，OB Proxy 不是協調者，它是無狀態的，也沒法持久化數據，如果讓它做協調者的話，一旦它宕機了，事務也無法恢復了。數據庫中間件架構中，一般中間件是協調者，下面的數據庫是參與者，參與者只知道協調者而不知道其他參與者的存在，一旦中間件故障，很難恢復事務。OceanBase 創新了二階段提交的方案，所有的參與者和協調者都是 OB Server，參與者和協調者都知道彼此的存在，參與者也知道其他參與者的存在，如圖中所示，Zone2 的一個服務器是協調者，當事務需要的數據在其他服務器上時，會由 Zone2 的服務器與 Zone1 和Zone3 的相關服務器(這些服務器做為參與者)通信。這個好處是，OB Server 是有高可用性保障的，事務執行期間，任何一臺 OB 服務器故障，即使是協調者所在的服務器故障了，其他服務器的從副本通過 Paxos 協議也可以很快的自動選舉新的主副本，新的主副本做為新的協調者，可以將事務恢復到宕機之前的狀態，不會有狀態和數據的丟失，可以確保分布式事務的強一致性，避免事務部分提交的現象。以上圖為例，如果協調者所在服務器故障了，P2 從副本所在的兩個服務器會選出新的主副本，新的主副本已經知曉該事務的存在(通過 Redo-Log 日志同步)，并擔任新的協調者的角色來恢復業務。

OceanBase 分布式事務的能力在 TPC-C 測試中也得到了充分的驗證：

• TPC-C 測試要求 40%的訂單需要跨倉庫執行，這個時候，如果是一個分布式事務，需要以倉庫為單位把數據打散，大概率很多事務是需要跨機器執行的。如此多的事務執行完成后，如何判定有沒有事務存在部分提交的現象呢？審計員會掃描所有的數據(OceanBase 測試時候，大概掃了約 1 萬億條數據)，算一個 SUM 值，跟其他幾個值來對比，如果數值不等的話，肯定有一些分布式事務有問題，測試是不會通過的。

• 為了更好的測試 OceanBase 的分布式事務，審計員也人工制造了一些故障，登陸一臺阿里云 ECS 服務器后，直接把服務器 shutdown，這個服務器上肯定運行了大量的事務，接下來應用會報錯和重連。審計員最后會再檢查完整性和一致性，一旦有不一致的，測試也不會通過。傳統數據庫也可以完成上述測試，但往往是依靠底層的高端硬件來實現的，而 OceanBase 是完全依賴自身軟件實現的。?

采用鎖機制控制讀寫沖突時，對數據加鎖后，往往其他事務將無法讀，導致讀寫競爭，影響讀的并發性，OceanBase 支持 MVCC 特性，可以有效解決該問題。如圖上舉例，張三的賬戶余額是 100 元。A1 時間，T1 事務想要更改張三的賬戶余額為 50 元，此時會加鎖，避免數據被其他事務改寫。由于事務沒有正式提交，系統以時間戳為版本號，記錄兩個版本的數據，新版本為 50，舊版本為 100.A2 時間，T2 事務想查詢張三的賬戶余額，由于新版本數據還未正式提交，存在回滾的風險，T2 事務可以讀取小于等于當前版本號的數據，且是已提交的數據，讀取金額為舊版本的數據，100.A3 時間，T1 事務完成提交，張三的余額變為了 50.A4 時間，T3 事務想要讀取張三的余額，由于 T1 事務已經提交完成，此時 T3 事務可以讀取新版本的數據，讀取到的金額為 50。總結下，OceanBase 使用 MVCC 技術解決了讀寫互斥的問題，提高了讀的性能。同時，OceanBase 提供了全局唯一的時間戳服務，消除機器時鐘差異帶來的影響，方便全局管理版本號。?

• 當修改數據時：首先需要獲取行鎖，然后再修改數據。事務未提交前，數據的新舊版本共存，通過不同的版本號區分。事務提交后，只有新的數據。

• 當讀取數據時：不需要加鎖，也不需要關注數據是否已被加鎖。先獲取版本號，再去查找小于等于當前版本號的已提交的數據。

這一頁我們講下事務隔離級別，先講幾個概念。

• 第一是臟讀，也就是讀取了未提交的數據，最后這數據又回滾到了，導致讀了錯的數據。

• 二是不可重復讀，在一個事務內，不同的時刻讀同一批數據，結果不一樣。

  也就第二次讀之前，期間被別的事務更新了數據。

• 三是幻讀，指的是在同一個事務內，在操作過程中進行兩次查詢，第二次查詢的結果包含了第一次查詢中未出現的數據或者缺少了第一次查詢中出現的數據，期間被別的事務插入或者刪除了數據。?

OceanBase 支持多種事務隔離級別，基于全局一致的數據版本號管理，以不同的版本號策略實現不同的隔離級別。OceanBase 支持兩種隔離級別，一種是 Read-Committed，可以避免臟讀，但存在不可重復讀和幻讀(默認)；另外一種是 Serializable，可以避免臟讀、不可重復讀和幻讀，這是最嚴格的隔離級別，但會影響性能。OceanBase 不支持臟讀，事務能夠讀取的數據肯定都是已提交的數據，不可能是未提交的數據，但有可能是已提交的舊數據。

總結

以上是生活随笔為你收集整理的服务器无法执行该事务_分布式事务、MVCC、事务隔离级别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。