揭祕！阿里實時數倉分佈式事務Scale Out設計

簡介：Hybrid Transaction Analytical Processing(HTAP) 是著名信息技術諮詢與分析公司Gartner在2014年提出的一個新的數據庫系統定義，特指一類兼具OLTP能力（事務能力）和OLAP能力（分析能力）的數據庫系統。

一 前言

Hybrid Transaction Analytical Processing(HTAP) 是著名信息技術諮詢與分析公司Gartner在2014年提出的一個新的數據庫系統定義，特指一類兼具OLTP能力（事務能力）和OLAP能力（分析能力）的數據庫系統。在傳統場景中，承擔OLTP任務和OLAP任務的數據庫是兩個不一樣的系統。典型的OLTP系統包括MySQL、PostgreSQL、PolarDB等，典型的OLAP系統包括Clickhouse、AnalyticDB等。在生產系統中，業務原始數據一般存儲在OLTP系統中，而後經過離線導入、ETL、DTS等方式以必定延遲同步到OLAP系統中，再進行後續的數據分析工做。

HTAP系統的一個直觀的優勢是能夠在一個系統中完成OLTP和OLAP任務，節約用戶的系統使用成本。並且，HTAP系統具有完整的ACID能力，讓開發者擁有更多的數據寫入方式，無論是實時插入、離線導入、數據單條更新，均可以輕鬆應對。另外，一個完備的HTAP產品，一樣是一個優秀的ETL工具，開發者能夠利用HTAP系統處理常見的數據加工需求。HTAP系統可以大大節約用戶的使用成本和開發成本，並影響上層業務系統的形態。目前，存儲計算分離、雲原生技術和HTAP等技術，被業界公認爲是數據庫系統目前的重要演進方向。
AnalyticDB PostgreSQL版是阿里雲的一款實時數倉產品（如下簡稱ADB PG）。ADB PG採用MPP水平擴展架構，支持標準SQL 2003，兼容PostgreSQL/Greenplum，高度兼容 Oracle 語法生態，也是一款HTAP產品。ADB PG已經經過了中國信息通訊研究院組織的分佈式分析型數據庫和分佈式事務數據庫功能和性能認證，是國內惟一一家同時經過這兩項認證的數據庫產品。ADB PG早期版本主打OLAP場景、具有OLTP能力。隨着HTAP的流行，ADB PG自6.0版本開始對OLTP性能在多個方面進行了大幅度優化，其中很重要的一個項目就是Multi-Master項目，經過Scale Out打破了原有架構的僅支持單個Master節點帶來的性能瓶頸問題，讓OLTP事務性能具有Scale out能力，更好地知足用戶的實時數倉和HTAP需求。

Multi-Master項目在2019年啓動後，經歷了一寫多讀和多寫多讀2個演進階段，極大的提高了ADB PG系統高併發能力、實時寫入/更新/查詢的能力，在阿里內部支撐了如數據銀行等多個核心業務，也通過了阿里2020年雙十一、雙12等大促的考驗。目前，產品的穩定性和性能都已經獲得了普遍驗證。在本文的以下部分，咱們首先介紹ADB PG原有的Single-Master架構致使的性能瓶頸及其緣由，並介紹Multi-Master的設計思路。而後咱們會詳細介紹Multi-Master架構的詳細設計。以後咱們會介紹咱們在Multi-Master項目中所解決的幾個關鍵技術問題和核心解決方案。最後，咱們會對Multi-Master架構的性能表現進行測試。

二 Single-Master架構 vs. Multi-Master架構

在數倉系統設計中，一般把系統中的節點分爲Master節點和Segment節點(計算節點)，Master節點和計算節點承擔不一樣類型的任務。以ADB PG爲例，Master節點主要負責接收用戶的請求、查詢優化、任務分發、元信息管理和事務管理等任務。Segment節點負責計算任務和存儲管理任務。對於查詢請求，Master節點須要對用戶提交的SQL進行解析和優化，而後將優化後的執行計劃分發到計算節點。計算節點須要對本地存儲的數據進行讀取，而後再完成計算和數據shuffle等任務，最後計算節點把計算結果返回到Master節點進行彙總。對於建表、寫入等請求，Master節點須要對元信息、事務等進行管理，並協調計算節點之間的工做。

如上圖所示，ADB PG是由Greenplum演化而來，早期的ADB PG版本和Greenplum同樣，是一種單Master架構。也就是說，一個數據庫實例只有一個Main Master在工做，配置一個或者多個Standby Master節點做爲高可用備份，只有當Main Master節點宕機，纔會切換到Standby Master進行工做。隨着業務的發展，尤爲是實時數倉和HTAP場景需求的增長， Single Master的系統瓶頸問題也逐漸顯現。對於查詢鏈路，有些查詢的最後一個階段須要在Master節點上進行最終的數據處理，消耗必定的CPU/內存資源。對於寫入場景，大量的實時插入/更新/刪除的須要高性能保證。並且Single Master架構如何處理超大併發鏈接數也是個問題。以上問題能夠經過提升Master節點的配置(Scale up)來緩解，可是沒法從根本上解決。

ADB PG在2019年啓動了Multi-Master項目，目標是經過節點擴展(Scale out)的方式來解決Master層的資源瓶頸問題，更好地知足實時數倉及HTAP等業務場景的需求。上圖是Multi-master架構的示意圖，經過增長多個Secondary Master節點來實現性能的Scale out，同時保留原有的Standby Master來保證高可用能力。爲了保障ADB PG的事務能力，Multi-master項目須要克服一些其餘不支持事務的實時數倉不會遇到的困難。一方面，ADB PG須要對分佈式事務能力進行擴展，支持多個Master的場景。一方面，對於全局死鎖處理、DDL支持以及分佈式表鎖支持方面，ADB PG須要進行算法的創新和修改。最後，ADB PG須要對更新以後的新架構的集羣容錯能力和高可用能力進行設計。在本文的餘下部分，咱們將對上述幾個議題進行介紹。

三 Multi-Master 架構設計

相對於原Single-Master架構，Multi-Master架構在Main Master/Standby Master的基礎之上新增實現了Secondary Master的角色，Secondary Master(s)支持承接和Main Master同樣的DDL，DML等請求，同時用戶能夠按需擴展來提高系統總體能力。下面是各個Master角色及對應主要能力的簡單介紹。

• Main Master：承接用戶業務請求，並把任務分發到各個計算節點進行分佈式處理。除此以外，Main Master還承擔了GTM，FTS和全局元信息服務的角色，這些組件與Multi-Master的實現密切相關。
• GTM：全局事務管理(Global Transaction Manager)，維護了全局的事務id及快照信息，是實現分佈式事務的核心組件。
• FTS：容錯服務(Fault-Tolerance Service), 檢測計算節點及輔協調節點的健康狀態，並在計算節點發生故障時進行計算節點的Primary與Mirror角色的切換。
• Catalog：以系統表Catalog等信息爲表明的全局元信息存儲。
• Standby Master：和Main Master組成典型的主備關係，在原Main Master故障的時候能夠接替成爲新的Main Master。
• Secondary Master：能夠視爲"弱化的Main Master"，和Main Master同樣能夠承接業務請求並將任務分發到各個計算節點進行處理。Secondary Master會經過GTM Proxy與Main Master上的GTM以及計算節點交互來實現分佈式事務。

• 須要注意的是，Main Master與Secondary Master經過上層的SLB來作基於權重的負載均衡管理。若是是在Main Master和Secondary Master相同的規格配置下，Main Master會經過權重設置來承擔相對少的業務請求負載，從而爲GTM，FTS等預留足夠的處理能力。

  四 Multi-Master關鍵技術

  本章將對Multi-Master的一些關鍵技術點進行詳細的介紹，主要包括分佈式事務處理、全局死鎖處理、DDL支持、分佈式表鎖支持、集羣容錯和高可用能力。

1 分佈式事務管理

ADB PG的分佈式事務實現

ADB PG的分佈式事務是使用二階段提交(2PC)協議來實現的，同時使用了分佈式快照來保證Master和不一樣Segment間的數據一致性，具體實現實現要點以下。

分佈式事務由Main Master發起，並經過2PC協議提交到Segments。2PC是分佈式系統的經典協議，將總體事務的提交過程拆分紅了Prepare和Commit/Abort兩個階段，如上面的簡單示意圖所示，只有參與事務的全部Segments都成功提交總體事務纔會成功提交。若是在第一階段有存在Prepare失敗的Segment，則總體事務會Abort掉；若是在第二階段有Commit失敗的Segment，並且Master已經成功記錄了PREPARED日誌，則會發起重試來Retry失敗的Commits。須要說明的是，若是一個事務僅僅牽涉到1個Segment，系統會優化爲按照1PC的方式來提交事務從而提高性能，具體來講就是將上圖中Master參與協調的Prepare和Commit兩個階段合二爲一，最終由惟一參與的Segment來保證事務執行的原子性。

Main Master上的GTM全局事務管理組件會維護全局的分佈式事務狀態，每個事務都會產生一個新的分佈式事務id、設置時間戳及相應的狀態信息，在獲取快照時，建立分佈式快照並保存在當前快照中。以下是分佈式快照記錄的核心信息：

執行查詢時，Main Master將分佈式事務和快照等信息序列化，經過libpq協議發送給Segment上來執行。Segment反序列化後，得到對應分佈式事務和快照信息，並以此爲依據來斷定查詢到的元組的可見性。全部參與該查詢的Segments都使用同一份分佈式事務和快照信息判斷元組的可見性，於是保證了整個集羣數據的一致性。另外，和 PostgreSQL 的提交日誌clog相似，ADB PG會保存全局事務的提交日誌，以判斷某個事務是否已經提交。這些信息保存在共享內存中並持久化存儲在distributedlog目錄下。另外，ADB PG實現了本地事務-分佈式事務提交緩存來幫助快速查到本地事務id(xid)和分佈式全局事務id(gxid)的映射關係。下面讓咱們經過一個例子來具體理解一下：

如上圖所示，Txn A在插入一條數據後，Txn B對該數據進行了更新。基於PostgreSQL的MVCC機制，當前Heap表中會存在兩條對應的記錄，Txn B更新完數據後會將原來tuple對應的xmax改成自身的本地xid值(由0改成4)。此後，Txn C和Txn D兩個查詢會結合本身的分佈式快照信息來作可見性判斷，具體規則是：

1. 若是 gxid < distribedSnapshot->xmin，則元組可見
2. 若是 gxid > distribedSnapshot->xmax，則元組不可見
3. 若是 distribedSnapshot->inProgressXidArray 包含 gxid，則元組不可見
4. 不然元組可見。若是不能根據分佈式快照判斷可見性，或者不須要根據分佈式快照判斷可見性，則使用本地快照信息判斷，這個邏輯和PostgreSQL的判斷可見性邏輯同樣。

基於上述規則，Txn C查到兩條tuple記錄後，經過xid和gxid映射關係找到兩條記錄對應的gxid值(分別爲100, 105)，規則c會限定Txn B的更新對Txn C不可見，因此Txn C查詢到的結果是'foo'；而Txn D基於規則則對Txn B更新後的tuple可見，因此查詢到的是'bar'。

Multi-Master的分佈式事務實現

Multi-Master的分佈式事務本質是在原有分佈式事務基礎之上進行了加強。如上圖所示，Postmaster是守護進程，Main Master的Backend業務處理進程和GTM Server之間經過共享內存通訊，但Secondary Master是沒法直接經過共享內存與Main Master上的GTM Server通訊的，爲此，咱們在Secondary Master和Main Master之間新增了一條通道並實現了一套GTM交互協議。另外，爲了減小Secondary Master和Main Master之間的鏈接並提高網絡通訊效率，咱們新增實現了GTM Proxy來代理同一個Secondary Master上多個Backend進程的GTM請求。下面，本文將從GTM交互協議 、GTM Proxy和分佈事務恢復三個方面來系統的闡述一下Multi-Master分佈式事務實現的技術細節。
（1）GTM交互協議
GTM交互協議是Secondary Master和Main Master之間事務交互的核心協議，具體協議的消息和說明以下表所示：

能夠看到，消息的核心仍是在交換GXID，SNAPSHOT等信息，同時作BEGIN/PREPARE/COMMIT/ABORT等事務操做，此處就再也不作一一說明。值得特別指出的是，跨節點的消息交互成本是很高的，考慮到OLAP用戶的特色和需求，咱們配合協議提供了不一樣的一致性選項，從而讓用戶能夠在性能和一致性上進行權衡和選擇：

• 會話一致：同一個會話知足可預期的一致性要求，包括單調讀，單調寫，讀本身所寫，讀後寫的一致性。
• 強一致：線性一致性，一旦操做完成，全部會話可見。也基於不一樣的一致性模式進行了定製和精簡。
如上表所示，若是用戶須要更高的性能而對於一致性能夠作出必定妥協，則能夠選擇會話一致模式，相對強一致，會話一致對協議交互進行了大幅度精簡，僅僅保留了 GET_GXID和 GET_GXID_MULTI ：

（2）GTM Proxy的實現

在Multi-Master的實現中，GTM Proxy是做爲Postmaster的子進程來管理的，這樣作的好處是：1) 無需新增新的角色，配套管控更簡單；2) GTM Proxy和Backend之間是自然認證和互信的；3) GTM Proxy能夠經過共享內存和Backend進程通訊，這樣相比Tcp Loopback更高效，既能夠減小內存拷貝，也無Network Stack開銷。

每一個GTM Proxy進程會和GTM server創建一個網絡鏈接，並會服務多個本地的backend進程，將它們的GTM請求轉發給GTM server。GTM Proxy還針對性的作一些請求優化處理，如：

• Backends間共享Snapshot，從而減小Snapshot請求數
• 合併和批處理Backends的併發GTM請求
• 批量獲取gxid（會話一致）
GTM Proxy是減小Secondary Master和Main Master之間鏈接並提高網絡通訊效率的關鍵。事實上，在實現中，若是用戶開啓了強一致模式，咱們在Main Master上會默認開啓GTM Proxy來代理Main Master上多個Backend進程與GTM Server之間的請求，從而進一步下降GTM Server的壓力。

（3）分佈式事務的恢復

在不少狀況下系統都須要作分佈式事務的恢復處理，好比系統/Master重啓，Main Master/Standby Master切換等，當不考慮Multi-Master，分佈式事務的恢復能夠簡單劃分爲以下3大步驟：

1. Main Master回放xlog，找出全部已經Prepared可是還沒有Committed的事務；
2. 命令全部Segments提交全部須要Committed的事務；
3. 收集全部Segments上未Committed並且不在「Main Master」須要提交的事務列表中的事務，Abort掉這些事務。
   上面的流程若是進一步考慮Multi-Master，那麼一些新的問題就引入了進來，核心須要解決的有：1）Secondary Master發起的事務的恢復；2) Segments和Secondary Master上殘留Prepared階段的事務在Secondary Master或者Master重啓等狀況下的恢復/清理等等。爲此，針對Multi-Master，咱們對二階段事務的提交和分佈式事務的恢復流程都作了加強，以下主要講一下二階段事務提交的加強和Secondary Master被刪除及第一次啓動時對應的清理流程：
   

此外，Main Master/Secondary Master重啓的流程也進行了加強，這裏面和原Main Master重啓恢復的主要差異是須要區分出屬於本身發起的分佈式事務，具體的區分是經過加強GXID來實現的。咱們在本來GXID的基本信息之上添加了masterid信息，這樣{GXID}-MasterID結合起來，就能夠基於GXID來區分出具體的Master了。

2 全局死鎖檢測

ADB PG 4.3版本是經過對錶加寫鎖來避免執行UPDATE和DELETE時出現全局死鎖。這個方法雖然避免了全局死鎖，可是併發更新的性能不好。ADB PG從6.0開始引入了全局死鎖檢測。該檢測進程收集並分析集羣中的鎖等待信息，若是發現了死鎖則殺死形成死鎖的進程來解除死鎖，這樣極大地提升了高併發狀況下簡單查詢、插入、刪除和更新操做的性能。ADB PG 6實現全局死鎖檢測的要點以下：
• 全局死鎖檢測服務進程（GDD）運行在Main Master上
• GDD會週期性獲取全部segment上的分佈式事務的gxid及其等待關係
• GDD構造全局的事務等待關係圖，檢測是否成環，若是成環，則回滾環中一個事務，破解死鎖
ADB PG Multi-Master的全局死鎖檢測總體也是ADB PG 6.0版本的實現來加強的，以下圖所示：

ADB PG Multi-Master的GDD也運行在Main Master之上，主要新增了兩個Master-to-Master的RPC調用來採集由Secondary Master發起的分佈式事務gxid列表以及通知Secondary Master去破解負責分佈式事務的死鎖。
• Get_gxids: 從每一個secondary master獲取gxid列表，以判斷致使死鎖的事務各屬於哪些master
• Cancel_deadlock_txn: 若是致使死鎖的事務屬於某個secondary master，則請求該master回滾掉該事務

3 DDL支持

在ADB PG的原生實現中，Main Master對DDL的支持和與Segments上Catalog的修改同步是經過2PC的方式實現的，ADBPG Multi-Master擴展了這一實現來支持對Secondary Master上Catalog的同步。

此外, Secondary Master也支持處理DDL，簡單說來，咱們在Secondary Master內部實現了一個簡單的代理，Secondary Master若是收到DDL請求，會將請求轉發給Main Master來處理。具體以下圖所示：

DDL的實現很是複雜，真實的落地其實要比上面複雜不少，也牽涉到不少細節，好比VACCUM/CLUSTER/ANALYZE等相對特殊的DDL處理，但總體的實現方案都基本聽從上面的原則。

4 分佈式表鎖

衆所周知，在數據庫的實現裏，爲支持對錶數據的併發訪問，通常都會經過鎖來實現。ADB PG的鎖模型和PostgreSQL是兼容的，具體以下表所示：

Multi-Master對ADB PG的表鎖協議進行了加強和適配，總結起來，咱們定義了一套新的分佈式表鎖協議來規範Main Master及Secondary Master上加鎖的順序和規則：
任意Master上的進程請求1-3級鎖
• 本地請求該表鎖
• 在全部Segments上請求該表鎖
• 事務結束時全部節點釋放鎖
Main Mater上的進程請求4-8級鎖
• 本地請求該表鎖
• 在全部Secondary master上請求該表鎖
• 在全部Segments上請求該表鎖
• 事務結束時全部節點釋放鎖
Secondary Master上的進程請求4-8級鎖
• 在Main Master上請求該表鎖
• 本地請求該表鎖
• 在全部其餘Secondary Master上請求該表鎖
• 在全部Segments上請求該表鎖
• 事務結束時全部節點釋放鎖

基於上述規則，咱們能夠實現任何的表鎖請求會最終在某個Master或者Segment獲得裁決，從而保證了對ADB PG的原表鎖協議的兼容。

5 集羣容錯與高可用

ADB PG是經過複製和監控來實現容錯和高可用的，主要包括：1）Standby Master和Mirror Segment分別爲Main Master和Primary Segment提供副本(經過PG流複製實現)；2）FTS在後臺負責監控與主備切換。如上圖中的流程：

1. Main Master到Standby Master的流複製；
2. Primary Segment到Mirror segment的流複製；
3. Main Master的FTS Probe進程發包探活Primary Segment；
4. Main Master的FTS Probe進程發包探活Secondary Master；
5. Main Master重啓後，其FTS Probe進程向GTM Server通報全部Master；
6. Secondary Master的FTS Probe發包探活Main Master，獲取最新集羣配置和狀態信息並存在本地；
7. Secondary Master的FTS Probe沒法鏈接Main Master後嘗試探活Standby master，若成功則更新其爲新的Main Master；不然繼續探活原Main Master。
   簡單說來，ADBPG Multi-Master在原ADB PG的容錯和高可用基礎之上進行了加強，讓系統可以進一步對Secondary Master進行兼容。另外，Secondary Master若是故障，則會進一步由管控系統看護並作實時修復。

五 Multi-master 擴展性能評測

ADB PG單Master實例在高併發點查、導入等偏OLTP的場景每每會存在單Master瓶頸，而Multi-Master的引入很好的解決了問題。爲了驗證Multi-Master在OLTP負載下橫向擴展的能力，本章節對ADB PG Multi-Master在默認的會話一致模式下的TPC-B/C兩種典型負載進行了性能測試。

1 TPC-C性能測試

TPC-C是事務處理性能委員會(TPC)旗下一的一個主流性能測試Benchmark集合，主要是測試數據庫系統的事務能力。TPC-C測試過程當中，會實現多種事務處理併發執行、在線與離線事務混合執行等方式，可以比較全面地考察數據庫系統的事務能力。咱們採用的測試環境是基於阿里雲ECS的ADB PG實例，具體參數以下：
• Master（Main Master/Secondary Master)：8c64g
• 節點規格(segment)：4C32G
• 節點數量(segment): 32
• 存儲類型：ESSD雲盤
• 節點存儲容量(segment): 1000GB

能夠看到，在只有1個Master時，當併發數到達64時，TPC-C的性能基本達到峯值，沒法再隨着併發數增長而增長，可是當有4個Masters時，隨着併發數的增長TPC-C的性能依舊能夠很是好的線性擴展。

2 TPC-B性能測試

TPC-B是TPC旗下另外一個性能測試Benchmark集合，主要用於衡量一個系統每秒可以處理的併發事務數。咱們採用的測試環境是基於阿里雲ECS的ADB PG實例，具體參數以下：

• Master（Main Master/Secondary Master)：8c64g
• 節點規格(segment)：4C32G
• 節點數量(segment): 32
• 存儲類型：ESSD雲盤
• 節點存儲容量(segment): 1000GB

能夠看到，和TPC-C相似，在只有1個Master時，當併發數到達64時，TPC-B的性能基本達到峯值，沒法再隨着併發數增長而增長，可是當有4個Masters時，隨着併發數的增長TPC-B的性能依舊能夠很是好的線性擴展。

六 總結

ADB PG Multi-Master經過水平擴展Master節點很好的突破了原架構單Master的限制，配合計算節點的彈性，系統總體能力尤爲是鏈接數及讀寫性能獲得進一步提高，能夠更好的知足實時數倉及HTAP等業務場景的需求。
原文連接

本文爲阿里雲原創內容，未經容許不得轉載。