[[396205]]

一 前言

Hybrid Transaction Analytical Processing(HTAP) 是著名信息技術(shù)咨詢與分析公司Gartner在2014年提出的一個新的數(shù)據(jù)庫系統(tǒng)定義，特指一類兼具OLTP能力(事務(wù)能力)和OLAP能力(分析能力)的數(shù)據(jù)庫系統(tǒng)。在傳統(tǒng)場景中，承擔(dān)OLTP任務(wù)和OLAP任務(wù)的數(shù)據(jù)庫是兩個不同的系統(tǒng)。典型的OLTP系統(tǒng)包括MySQL、PostgreSQL、PolarDB等，典型的OLAP系統(tǒng)包括Clickhouse、AnalyticDB等。在生產(chǎn)系統(tǒng)中，業(yè)務(wù)原始數(shù)據(jù)通常存儲在OLTP系統(tǒng)中，然后通過離線導(dǎo)入、ETL、DTS等方式以一定延遲同步到OLAP系統(tǒng)中，再進行后續(xù)的數(shù)據(jù)分析工作。

HTAP系統(tǒng)的一個直觀的優(yōu)點是可以在一個系統(tǒng)中完成OLTP和OLAP任務(wù)，節(jié)約用戶的系統(tǒng)使用成本。而且，HTAP系統(tǒng)具備完整的ACID能力，讓開發(fā)者擁有更多的數(shù)據(jù)寫入方式，不管是實時插入、離線導(dǎo)入、數(shù)據(jù)單條更新，都可以輕松應(yīng)對。另外，一個完備的HTAP產(chǎn)品，同樣是一個優(yōu)秀的ETL工具，開發(fā)者可以利用HTAP系統(tǒng)處理常見的數(shù)據(jù)加工需求。HTAP系統(tǒng)能夠大大節(jié)約用戶的使用成本和開發(fā)成本，并影響上層業(yè)務(wù)系統(tǒng)的形態(tài)。目前，存儲計算分離、云原生技術(shù)和HTAP等技術(shù)，被業(yè)界公認為是數(shù)據(jù)庫系統(tǒng)目前的重要演進方向。

AnalyticDB PostgreSQL版是阿里云的一款實時數(shù)倉產(chǎn)品(以下簡稱ADB PG)。ADB PG采用MPP水平擴展架構(gòu)，支持標(biāo)準(zhǔn)SQL 2003，兼容PostgreSQL/Greenplum，高度兼容 Oracle 語法生態(tài)，也是一款HTAP產(chǎn)品。ADB PG已經(jīng)通過了中國信息通信研究院組織的分布式分析型數(shù)據(jù)庫和分布式事務(wù)數(shù)據(jù)庫功能和性能認證，是國內(nèi)唯一一家同時通過這兩項認證的數(shù)據(jù)庫產(chǎn)品。ADB PG早期版本主打OLAP場景、具備OLTP能力。隨著HTAP的流行，ADB PG自6.0版本開始對OLTP性能在多個方面進行了大幅度優(yōu)化，其中很重要的一個項目就是Multi-Master項目，通過Scale Out打破了原有架構(gòu)的僅支持單個Master節(jié)點帶來的性能瓶頸問題，讓OLTP事務(wù)性能具備Scale out能力，更好地滿足用戶的實時數(shù)倉和HTAP需求。

Multi-Master項目在2019年啟動后，經(jīng)歷了一寫多讀和多寫多讀2個演進階段，極大的提升了ADB PG系統(tǒng)高并發(fā)能力、實時寫入/更新/查詢的能力，在阿里內(nèi)部支撐了如數(shù)據(jù)銀行等多個核心業(yè)務(wù)，也經(jīng)過了阿里2020年雙11、雙12等大促的考驗。目前，產(chǎn)品的穩(wěn)定性和性能都已經(jīng)得到了廣泛驗證。在本文的如下部分，我們首先介紹ADB PG原有的Single-Master架構(gòu)導(dǎo)致的性能瓶頸及其原因，并介紹Multi-Master的設(shè)計思路。然后我們會詳細介紹Multi-Master架構(gòu)的詳細設(shè)計。之后我們會介紹我們在Multi-Master項目中所解決的幾個關(guān)鍵技術(shù)問題和核心解決方案。最后，我們會對Multi-Master架構(gòu)的性能表現(xiàn)進行測試。

二 Single-Master架構(gòu) vs. Multi-Master架構(gòu)

在數(shù)倉系統(tǒng)設(shè)計中，通常把系統(tǒng)中的節(jié)點分為Master節(jié)點和Segment節(jié)點(計算節(jié)點)，Master節(jié)點和計算節(jié)點承擔(dān)不同類型的任務(wù)。以ADB PG為例，Master節(jié)點主要負責(zé)接收用戶的請求、查詢優(yōu)化、任務(wù)分發(fā)、元信息管理和事務(wù)管理等任務(wù)。Segment節(jié)點負責(zé)計算任務(wù)和存儲管理任務(wù)。對于查詢請求，Master節(jié)點需要對用戶提交的SQL進行解析和優(yōu)化，然后將優(yōu)化后的執(zhí)行計劃分發(fā)到計算節(jié)點。計算節(jié)點需要對本地存儲的數(shù)據(jù)進行讀取，然后再完成計算和數(shù)據(jù)shuffle等任務(wù)，最后計算節(jié)點把計算結(jié)果返回到Master節(jié)點進行匯總。對于建表、寫入等請求，Master節(jié)點需要對元信息、事務(wù)等進行管理，并協(xié)調(diào)計算節(jié)點之間的工作。

如上圖所示，ADB PG是由Greenplum演化而來，早期的ADB PG版本和Greenplum一樣，是一種單Master架構(gòu)。也就是說，一個數(shù)據(jù)庫實例只有一個Main Master在工作，配置一個或者多個Standby Master節(jié)點作為高可用備份，只有當(dāng)Main Master節(jié)點宕機，才會切換到Standby Master進行工作。隨著業(yè)務(wù)的發(fā)展，尤其是實時數(shù)倉和HTAP場景需求的增加， Single Master的系統(tǒng)瓶頸問題也逐漸顯現(xiàn)。對于查詢鏈路，有些查詢的最后一個階段需要在Master節(jié)點上進行最終的數(shù)據(jù)處理，消耗一定的CPU/內(nèi)存資源。對于寫入場景，大量的實時插入/更新/刪除的需要高性能保證。而且Single Master架構(gòu)如何處理超大并發(fā)連接數(shù)也是個問題。以上問題可以通過提高Master節(jié)點的配置(Scale up)來緩解，但是無法從根本上解決。

ADB PG在2019年啟動了Multi-Master項目，目標(biāo)是通過節(jié)點擴展(Scale out)的方式來解決Master層的資源瓶頸問題，更好地滿足實時數(shù)倉及HTAP等業(yè)務(wù)場景的需求。上圖是Multi-master架構(gòu)的示意圖，通過增加多個Secondary Master節(jié)點來實現(xiàn)性能的Scale out，同時保留原有的Standby Master來保證高可用能力。為了保障ADB PG的事務(wù)能力，Multi-master項目需要克服一些其他不支持事務(wù)的實時數(shù)倉不會遇到的困難。一方面，ADB PG需要對分布式事務(wù)能力進行擴展，支持多個Master的場景。一方面，對于全局死鎖處理、DDL支持以及分布式表鎖支持方面，ADB PG需要進行算法的創(chuàng)新和修改。最后，ADB PG需要對更新之后的新架構(gòu)的集群容錯能力和高可用能力進行設(shè)計。在本文的余下部分，我們將對上述幾個議題進行介紹。

三 Multi-Master 架構(gòu)設(shè)計

相對于原Single-Master架構(gòu)，Multi-Master架構(gòu)在Main Master/Standby Master的基礎(chǔ)之上新增實現(xiàn)了Secondary Master的角色，Secondary Master(s)支持承接和Main Master一樣的DDL，DML等請求，同時用戶可以按需擴展來提升系統(tǒng)整體能力。下面是各個Master角色及對應(yīng)主要能力的簡單介紹。

Main Master：承接用戶業(yè)務(wù)請求，并把任務(wù)分發(fā)到各個計算節(jié)點進行分布式處理。除此之外，Main Master還承擔(dān)了GTM，F(xiàn)TS和全局元信息服務(wù)的角色，這些組件與Multi-Master的實現(xiàn)密切相關(guān)。

• GTM：全局事務(wù)管理(Global Transaction Manager)，維護了全局的事務(wù)id及快照信息，是實現(xiàn)分布式事務(wù)的核心組件。
• FTS：容錯服務(wù)(Fault-Tolerance Service), 檢測計算節(jié)點及輔協(xié)調(diào)節(jié)點的健康狀態(tài)，并在計算節(jié)點發(fā)生故障時進行計算節(jié)點的Primary與Mirror角色的切換。
• Catalog：以系統(tǒng)表Catalog等信息為代表的全局元信息存儲。
• Standby Master：和Main Master組成典型的主備關(guān)系，在原Main Master故障的時候可以接替成為新的Main Master。
• Secondary Master：可以視為"弱化的Main Master"，和Main Master一樣可以承接業(yè)務(wù)請求并將任務(wù)分發(fā)到各個計算節(jié)點進行處理。Secondary Master會通過GTM Proxy與Main Master上的GTM以及計算節(jié)點交互來實現(xiàn)分布式事務(wù)。

需要注意的是，Main Master與Secondary Master通過上層的SLB來做基于權(quán)重的負載均衡管理。如果是在Main Master和Secondary Master相同的規(guī)格配置下，Main Master會通過權(quán)重設(shè)置來承擔(dān)相對少的業(yè)務(wù)請求負載，從而為GTM，F(xiàn)TS等預(yù)留足夠的處理能力。

四 Multi-Master關(guān)鍵技術(shù)

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

1 分布式事務(wù)管理

ADB PG的分布式事務(wù)實現(xiàn)

ADB PG的分布式事務(wù)是使用二階段提交(2PC)協(xié)議來實現(xiàn)的，同時使用了分布式快照來保證Master和不同Segment間的數(shù)據(jù)一致性，具體實現(xiàn)實現(xiàn)要點如下。

分布式事務(wù)由Main Master發(fā)起，并通過2PC協(xié)議提交到Segments。2PC是分布式系統(tǒng)的經(jīng)典協(xié)議，將整體事務(wù)的提交過程拆分成了Prepare和Commit/Abort兩個階段，如上面的簡單示意圖所示，只有參與事務(wù)的所有Segments都成功提交整體事務(wù)才會成功提交。如果在第一階段有存在Prepare失敗的Segment，則整體事務(wù)會Abort掉;如果在第二階段有Commit失敗的Segment，而且Master已經(jīng)成功記錄了PREPARED日志，則會發(fā)起重試來Retry失敗的Commits。需要說明的是，如果一個事務(wù)僅僅牽涉到1個Segment，系統(tǒng)會優(yōu)化為按照1PC的方式來提交事務(wù)從而提升性能，具體來說就是將上圖中Master參與協(xié)調(diào)的Prepare和Commit兩個階段合二為一，最終由唯一參與的Segment來保證事務(wù)執(zhí)行的原子性。

Main Master上的GTM全局事務(wù)管理組件會維護全局的分布式事務(wù)狀態(tài)，每一個事務(wù)都會產(chǎn)生一個新的分布式事務(wù)id、設(shè)置時間戳及相應(yīng)的狀態(tài)信息，在獲取快照時，創(chuàng)建分布式快照并保存在當(dāng)前快照中。如下是分布式快照記錄的核心信息：

執(zhí)行查詢時，Main Master將分布式事務(wù)和快照等信息序列化，通過libpq協(xié)議發(fā)送給Segment上來執(zhí)行。Segment反序列化后，獲得對應(yīng)分布式事務(wù)和快照信息，并以此為依據(jù)來判定查詢到的元組的可見性。所有參與該查詢的Segments都使用同一份分布式事務(wù)和快照信息判斷元組的可見性，因而保證了整個集群數(shù)據(jù)的一致性。另外，和 PostgreSQL 的提交日志clog類似，ADB PG會保存全局事務(wù)的提交日志，以判斷某個事務(wù)是否已經(jīng)提交。這些信息保存在共享內(nèi)存中并持久化存儲在distributedlog目錄下。另外，ADB PG實現(xiàn)了本地事務(wù)-分布式事務(wù)提交緩存來幫助快速查到本地事務(wù)id(xid)和分布式全局事務(wù)id(gxid)的映射關(guān)系。下面讓我們通過一個例子來具體理解一下：

如上圖所示，Txn A在插入一條數(shù)據(jù)后，Txn B對該數(shù)據(jù)進行了更新。基于PostgreSQL的MVCC機制，當(dāng)前Heap表中會存在兩條對應(yīng)的記錄，Txn B更新完數(shù)據(jù)后會將原來tuple對應(yīng)的xmax改為自身的本地xid值(由0改為4)。此后，Txn C和Txn D兩個查詢會結(jié)合自己的分布式快照信息來做可見性判斷，具體規(guī)則是：

• 如果 gxid < distribedSnapshot->xmin，則元組可見
• 如果 gxid > distribedSnapshot->xmax，則元組不可見
• 如果 distribedSnapshot->inProgressXidArray 包含 gxid，則元組不可見
• 否則元組可見。如果不能根據(jù)分布式快照判斷可見性，或者不需要根據(jù)分布式快照判斷可見性，則使用本地快照信息判斷，這個邏輯和PostgreSQL的判斷可見性邏輯一樣。

基于上述規(guī)則，Txn C查到兩條tuple記錄后，通過xid和gxid映射關(guān)系找到兩條記錄對應(yīng)的gxid值(分別為100, 105)，規(guī)則c會限定Txn B的更新對Txn C不可見，所以Txn C查詢到的結(jié)果是'foo';而Txn D基于規(guī)則則對Txn B更新后的tuple可見，所以查詢到的是'bar'。

Multi-Master的分布式事務(wù)實現(xiàn)

Multi-Master的分布式事務(wù)本質(zhì)是在原有分布式事務(wù)基礎(chǔ)之上進行了增強。如上圖所示，Postmaster是守護進程，Main Master的Backend業(yè)務(wù)處理進程和GTM Server之間通過共享內(nèi)存通信，但Secondary Master是無法直接通過共享內(nèi)存與Main Master上的GTM Server通信的，為此，我們在Secondary Master和Main Master之間新增了一條通道并實現(xiàn)了一套GTM交互協(xié)議。另外，為了減少Secondary Master和Main Master之間的連接并提升網(wǎng)絡(luò)通信效率，我們新增實現(xiàn)了GTM Proxy來代理同一個Secondary Master上多個Backend進程的GTM請求。下面，本文將從GTM交互協(xié)議 、GTM Proxy和分布事務(wù)恢復(fù)三個方面來系統(tǒng)的闡述一下Multi-Master分布式事務(wù)實現(xiàn)的技術(shù)細節(jié)。

(1)GTM交互協(xié)議

GTM交互協(xié)議是Secondary Master和Main Master之間事務(wù)交互的核心協(xié)議，具體協(xié)議的消息和說明如下表所示：

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

• 會話一致：同一個會話滿足可預(yù)期的一致性要求，包括單調(diào)讀，單調(diào)寫，讀自己所寫，讀后寫的一致性。
• 強一致：線性一致性，一旦操作完成，所有會話可見。也基于不同的一致性模式進行了定制和精簡。

如上表所示，如果用戶需要更高的性能而對于一致性可以做出一定妥協(xié)，則可以選擇會話一致模式，相對強一致，會話一致對協(xié)議交互進行了大幅度精簡，僅僅保留了 GET_GXID和 GET_GXID_MULTI ：

其中， GET_GXID_MULTI本質(zhì)就是 GET_GXID的批量操作。在會話一致模式下，Secondary Master只需要從Main Master獲取全局的GXID信息，然后結(jié)合本地快照并配合重試及GDD全局死鎖檢測(后面會講到)來獨立處理事務(wù)，從而大幅度簡化與Master之間的消息交互提升性能。當(dāng)然，這里的代價就是在一致性上做出的讓步，事實上，會話一致可以滿足絕大部分OLAP/HTAP客戶的訴求。

(2)GTM Proxy的實現(xiàn)

在Multi-Master的實現(xiàn)中，GTM Proxy是作為Postmaster的子進程來管理的，這樣做的好處是：1) 無需新增新的角色，配套管控更簡單;2) GTM Proxy和Backend之間是天然認證和互信的;3) GTM Proxy可以通過共享內(nèi)存和Backend進程通信，這樣相比Tcp Loopback更高效，既可以減少內(nèi)存拷貝，也無Network Stack開銷。

每個GTM Proxy進程會和GTM server建立一個網(wǎng)絡(luò)連接，并會服務(wù)多個本地的backend進程，將它們的GTM請求轉(zhuǎn)發(fā)給GTM server。GTM Proxy還針對性的做一些請求優(yōu)化處理，如：

• Backends間共享Snapshot，從而減少Snapshot請求數(shù)
• 合并和批處理Backends的并發(fā)GTM請求
• 批量獲取gxid(會話一致)

GTM Proxy是減少Secondary Master和Main Master之間連接并提升網(wǎng)絡(luò)通信效率的關(guān)鍵。事實上，在實現(xiàn)中，如果用戶開啟了強一致模式，我們在Main Master上會默認開啟GTM Proxy來代理Main Master上多個Backend進程與GTM Server之間的請求，從而進一步降低GTM Server的壓力。

(3)分布式事務(wù)的恢復(fù)

在很多情況下系統(tǒng)都需要做分布式事務(wù)的恢復(fù)處理，比如系統(tǒng)/Master重啟，Main Master/Standby Master切換等，當(dāng)不考慮Multi-Master，分布式事務(wù)的恢復(fù)可以簡單劃分為如下3大步驟：

1. Main Master回放xlog，找出所有已經(jīng)Prepared但是尚未Committed的事務(wù);
2. 命令所有Segments提交所有需要Committed的事務(wù);
3. 收集所有Segments上未Committed而且不在“Main Master”需要提交的事務(wù)列表中的事務(wù)，Abort掉這些事務(wù)。

上面的流程如果進一步考慮Multi-Master，那么一些新的問題就引入了進來，核心需要解決的有：1)Secondary Master發(fā)起的事務(wù)的恢復(fù);2) Segments和Secondary Master上殘留Prepared階段的事務(wù)在Secondary Master或者Master重啟等情況下的恢復(fù)/清理等等。為此，針對Multi-Master，我們對二階段事務(wù)的提交和分布式事務(wù)的恢復(fù)流程都做了增強，如下主要講一下二階段事務(wù)提交的增強和Secondary Master被刪除及第一次啟動時對應(yīng)的清理流程：

此外，Main Master/Secondary Master重啟的流程也進行了增強，這里面和原Main Master重啟恢復(fù)的主要差別是需要區(qū)分出屬于自己發(fā)起的分布式事務(wù)，具體的區(qū)分是通過增強GXID來實現(xiàn)的。我們在原本GXID的基本信息之上添加了masterid信息，這樣{GXID}-MasterID結(jié)合起來，就可以基于GXID來區(qū)分出具體的Master了。

2 全局死鎖檢測

ADB PG 4.3版本是通過對表加寫鎖來避免執(zhí)行UPDATE和DELETE時出現(xiàn)全局死鎖。這個方法雖然避免了全局死鎖，但是并發(fā)更新的性能很差。ADB PG從6.0開始引入了全局死鎖檢測。該檢測進程收集并分析集群中的鎖等待信息，如果發(fā)現(xiàn)了死鎖則殺死造成死鎖的進程來解除死鎖，這樣極大地提高了高并發(fā)情況下簡單查詢、插入、刪除和更新操作的性能。ADB PG 6實現(xiàn)全局死鎖檢測的要點如下：

• 全局死鎖檢測服務(wù)進程(GDD)運行在Main Master上
• GDD會周期性獲取所有segment上的分布式事務(wù)的gxid及其等待關(guān)系
• GDD構(gòu)造全局的事務(wù)等待關(guān)系圖，檢測是否成環(huán)，如果成環(huán)，則回滾環(huán)中一個事務(wù)，破解死鎖

ADB PG Multi-Master的全局死鎖檢測整體也是ADB PG 6.0版本的實現(xiàn)來增強的，如下圖所示：

ADB PG Multi-Master的GDD也運行在Main Master之上，主要新增了兩個Master-to-Master的RPC調(diào)用來采集由Secondary Master發(fā)起的分布式事務(wù)gxid列表以及通知Secondary Master去破解負責(zé)分布式事務(wù)的死鎖。

• Get_gxids: 從每個secondary master獲取gxid列表，以判斷導(dǎo)致死鎖的事務(wù)各屬于哪些master
• Cancel_deadlock_txn: 如果導(dǎo)致死鎖的事務(wù)屬于某個secondary master，則請求該master回滾掉該事務(wù)

3 DDL支持

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

此外, Secondary Master也支持處理DDL，簡單說來，我們在Secondary Master內(nèi)部實現(xiàn)了一個簡單的代理，Secondary Master如果收到DDL請求，會將請求轉(zhuǎn)發(fā)給Main Master來處理。具體如下圖所示：

DDL的實現(xiàn)非常復(fù)雜，真實的落地其實要比上面復(fù)雜很多，也牽涉到很多細節(jié)，比如VACCUM/CLUSTER/ANALYZE等相對特殊的DDL處理，但整體的實現(xiàn)方案都基本遵從上面的原則。

4 分布式表鎖

眾所周知，在數(shù)據(jù)庫的實現(xiàn)里，為支持對表數(shù)據(jù)的并發(fā)訪問，一般都會通過鎖來實現(xiàn)。ADB PG的鎖模型和PostgreSQL是兼容的，具體如下表所示：

Multi-Master對ADB PG的表鎖協(xié)議進行了增強和適配，總結(jié)起來，我們定義了一套新的分布式表鎖協(xié)議來規(guī)范Main Master及Secondary Master上加鎖的順序和規(guī)則：

任意Master上的進程請求1-3級鎖

• 本地請求該表鎖
• 在所有Segments上請求該表鎖
• 事務(wù)結(jié)束時所有節(jié)點釋放鎖

Main Mater上的進程請求4-8級鎖

• 本地請求該表鎖
• 在所有Secondary master上請求該表鎖
• 在所有Segments上請求該表鎖
• 事務(wù)結(jié)束時所有節(jié)點釋放鎖

Secondary Master上的進程請求4-8級鎖

• 在Main Master上請求該表鎖
• 本地請求該表鎖
• 在所有其他Secondary Master上請求該表鎖
• 在所有Segments上請求該表鎖
• 事務(wù)結(jié)束時所有節(jié)點釋放鎖

基于上述規(guī)則，我們可以實現(xiàn)任何的表鎖請求會最終在某個Master或者Segment得到裁決，從而保證了對ADB PG的原表鎖協(xié)議的兼容。

5 集群容錯與高可用

ADB PG是通過復(fù)制和監(jiān)控來實現(xiàn)容錯和高可用的，主要包括：1)Standby Master和Mirror Segment分別為Main Master和Primary Segment提供副本(通過PG流復(fù)制實現(xiàn));2)FTS在后臺負責(zé)監(jiān)控與主備切換。如上圖中的流程：

• Main Master到Standby Master的流復(fù)制;
• Primary Segment到Mirror segment的流復(fù)制;
• Main Master的FTS Probe進程發(fā)包探活Primary Segment;
• Main Master的FTS Probe進程發(fā)包探活Secondary Master;
• Main Master重啟后，其FTS Probe進程向GTM Server通報所有Master;
• Secondary Master的FTS Probe發(fā)包探活Main Master，獲取最新集群配置和狀態(tài)信息并存在本地;
• Secondary Master的FTS Probe無法連接Main Master后嘗試探活Standby master，若成功則更新其為新的Main Master;否則繼續(xù)探活原Main Master。

簡單說來，ADBPG Multi-Master在原ADB PG的容錯和高可用基礎(chǔ)之上進行了增強，讓系統(tǒng)能夠進一步對Secondary Master進行兼容。另外，Secondary Master如果故障，則會進一步由管控系統(tǒng)看護并做實時修復(fù)。

五 Multi-master 擴展性能評測

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

1 TPC-C性能測試

TPC-C是事務(wù)處理性能委員會(TPC)旗下一的一個主流性能測試Benchmark集合，主要是測試數(shù)據(jù)庫系統(tǒng)的事務(wù)能力。TPC-C測試過程中，會實現(xiàn)多種事務(wù)處理并發(fā)執(zhí)行、在線與離線事務(wù)混合執(zhí)行等方式，能夠比較全面地考察數(shù)據(jù)庫系統(tǒng)的事務(wù)能力。我們采用的測試環(huán)境是基于阿里云ECS的ADB PG實例，具體參數(shù)如下：

• Master(Main Master/Secondary Master)：8c64g
• 節(jié)點規(guī)格(segment)：4C32G
• 節(jié)點數(shù)量(segment): 32
• 存儲類型：ESSD云盤
• 節(jié)點存儲容量(segment): 1000GB

可以看到，在只有1個Master時，當(dāng)并發(fā)數(shù)到達64時，TPC-C的性能基本達到峰值，無法再隨著并發(fā)數(shù)增加而增加，但是當(dāng)有4個Masters時，隨著并發(fā)數(shù)的增加TPC-C的性能依舊可以非常好的線性擴展。

2 TPC-B性能測試

TPC-B是TPC旗下另一個性能測試Benchmark集合，主要用于衡量一個系統(tǒng)每秒能夠處理的并發(fā)事務(wù)數(shù)。我們采用的測試環(huán)境是基于阿里云ECS的ADB PG實例，具體參數(shù)如下：

• Master(Main Master/Secondary Master)：8c64g
• 節(jié)點規(guī)格(segment)：4C32G
• 節(jié)點數(shù)量(segment): 32
• 存儲類型：ESSD云盤
• 節(jié)點存儲容量(segment): 1000GB

可以看到，和TPC-C類似，在只有1個Master時，當(dāng)并發(fā)數(shù)到達64時，TPC-B的性能基本達到峰值，無法再隨著并發(fā)數(shù)增加而增加，但是當(dāng)有4個Masters時，隨著并發(fā)數(shù)的增加TPC-B的性能依舊可以非常好的線性擴展。

六 總結(jié)

ADB PG Multi-Master通過水平擴展Master節(jié)點很好的突破了原架構(gòu)單Master的限制，配合計算節(jié)點的彈性，系統(tǒng)整體能力尤其是連接數(shù)及讀寫性能得到進一步提升，可以更好的滿足實時數(shù)倉及HTAP等業(yè)務(wù)場景的需求。