天天看點

OceanBase 源碼解讀(四):事務的一生

OceanBase 源碼解讀(四):事務的一生

源碼是 OceanBase 的“方向盤”,本系列主要圍繞“源碼解讀”,通過文章闡述,幫助大家理清資料庫的内在本質。此前,帶你讀源碼第三篇《戳這裡回顧:

OceanBase 源碼解讀(三)分區的一生

》為大家介紹了OceanBase 的存儲層的相關内容。在第一節講通信協定 

obmp_query

 時,跳過了事務控制的細節,本文為 OceanBase 資料庫源碼解讀系列文章的第四篇,将主要為大家介紹事務的外部接口相關知識。

事務的外部接口

1.1. 協定層對事務層的封裝

協定層對事務層提供的原始接口進行了封裝,源碼位置:sql/ob_sql_trans_control.h,截圖如下。這層封裝維護了 

TransState

 狀态,且便于 SQL 層調用,語句執行結束時在統一的位置根據 

TransState

 調用正确的事務接口,保證在任何異常狀态下事務資源不洩露。

OceanBase 源碼解讀(四):事務的一生

2.2. 原始的事務接口

原始的事務接口位于源碼檔案 storage/transaction/ob_trans_service.h,主要接口為:

  • start_trans

     & 

    end_trans

     (參見截圖)
  • start_stmt

    end_stmt

  • start_participant

    end_participant

它們分别對應事務、語句、語句内參與者(分區)的通路生命周期。

start trans

 開啟事務後,傳回一個 

ObTransDesc

 對象。該對象作為事務唯一辨別,會被儲存到 

session

 對象中,其他事務接口和後續語句執行都需要它,也常用于問題診斷。

OceanBase 源碼解讀(四):事務的一生
OceanBase 源碼解讀(四):事務的一生

3.3. 分布式事務

開始執行前,根據語句涉及分區資訊從 

location cache

 中擷取主副本(leader)位置,選擇對應類别的執行計劃。一般的,一個 SQL 查詢或 DML 會産生三類執行計劃(

ObPhyPlanType

):

  • local

     計劃表示所有該語句執行需通路分區的 leader 都在本節點
  • remote

     計劃表示所有分區 leader 都在遠端一個節點上
  • distributed

     計劃表示分區 leader 在多節點上的情況。

location cache

 是一個整體架構上的重要元件,用于高效查找分區副本資訊,它對外提供統一接口,屏蔽了很多分布式細節。它的主體實作位于 share/partition_table目錄(參見截圖),而源檔案 sql/ob_sql_partition_location_cache.h 對它進行了封裝,同時統一了虛拟表的處理。

事務控制調用往往要綜合考慮多種因素:

  • 語句類型(是否隻讀)
  • 事務類型(是否自動送出,是否弱一緻性讀)
  • 目前事務狀态和執行計劃類型等

例如,本地計劃自動送出,在本節點順序執行 

start_trans

 ➡︎ 

start_stmt

start_participant

end_participant

end_stmt

end trans

;遠端計劃自動送出,上述接口都在遠端節點執行。而對于分布式執行計劃,

start/end_stmt

 在本節點執行,

start/end_participant

 在每個分區 leader 所在節點上執行。這組接口設計目的是在簡化事務接口與分場景優化事務性能間取得一定的平衡。

OceanBase 源碼解讀(四):事務的一生
OceanBase 源碼解讀(四):事務的一生

以上就是 OceanBase 事務的一生,在後續的源碼解讀第五篇我們将會為大家解析 OceanBase 資料庫多租戶架構的相關内容,敬請期待。