一 前言

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年雙11、雙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兩個查詢會結合自己的分散式快照資訊來做可見性判斷，具體規則是：

如果 gxiddistribedSnapshot-xmin，則元組可見

如果 gxiddistribedSnapshot-xmax，則元組不可見

如果 distribedSnapshot-inProgressXidArray 包含 gxid，則元組不可見

否則元組可見。如果不能根據分散式快照判斷可見性，或者不需要根據分散式快照判斷可見性，則使用本地快照資訊判斷，這個邏輯和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 ：

其中， GET_GXID_MULTI本質就是 GET_GXID的批次操作。在會話一致模式下，Secondary Master只需要從Main Master獲取全域性的GXID資訊，然後結合本地快照並配合重試及GDD全域性死鎖檢測（後面會講到）來獨立處理事務，從而大幅度簡化與Master之間的訊息互動提升效能。當然，這裡的代價就是在一致性上做出的讓步，事實上，會話一致可以滿足絕大部分OLAP/HTAP客戶的訴求。

（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大步驟：

Main Master回放xlog，找出所有已經Prepared但是尚未Committed的事務；

命令所有Segments提交所有需要Committed的事務；

收集所有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在後臺負責監控與主備切換。如上圖中的流程：

Main Master到Standby Master的流複製；

Primary Segment到Mirror segment的流複製；

Main Master的FTS Probe程序發包探活Primary Segment；

Main Master的FTS Probe程序發包探活Secondary Master；

Main Master重啟後，其FTS Probe程序向GTM Server通報所有Master；

Secondary Master的FTS Probe發包探活Main Master，獲取最新叢集配置和狀態資訊並存在本地；

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等業務場景的需求。

作者 | 澤賢