揭秘！阿里实时数仓分布式事务Scale Out设计
簡(jiǎn)介： Hybrid Transaction Analytical Processing(HTAP) 是著名信息技術(shù)咨詢與分析公司Gartner在2014年提出的一個(gè)新的數(shù)據(jù)庫(kù)系統(tǒng)定義，特指一類兼具OLTP能力（事務(wù)能力）和OLAP能力（分析能力）的數(shù)據(jù)庫(kù)系統(tǒng)。
一 ?前言
Hybrid Transaction Analytical Processing(HTAP) 是著名信息技術(shù)咨詢與分析公司Gartner在2014年提出的一個(gè)新的數(shù)據(jù)庫(kù)系統(tǒng)定義，特指一類兼具OLTP能力（事務(wù)能力）和OLAP能力（分析能力）的數(shù)據(jù)庫(kù)系統(tǒng)。在傳統(tǒng)場(chǎng)景中，承擔(dān)OLTP任務(wù)和OLAP任務(wù)的數(shù)據(jù)庫(kù)是兩個(gè)不同的系統(tǒng)。典型的OLTP系統(tǒng)包括MySQL、PostgreSQL、PolarDB等，典型的OLAP系統(tǒng)包括Clickhouse、AnalyticDB等。在生產(chǎn)系統(tǒng)中，業(yè)務(wù)原始數(shù)據(jù)通常存儲(chǔ)在OLTP系統(tǒng)中，然后通過(guò)離線導(dǎo)入、ETL、DTS等方式以一定延遲同步到OLAP系統(tǒng)中，再進(jìn)行后續(xù)的數(shù)據(jù)分析工作。
HTAP系統(tǒng)的一個(gè)直觀的優(yōu)點(diǎn)是可以在一個(gè)系統(tǒng)中完成OLTP和OLAP任務(wù)，節(jié)約用戶的系統(tǒng)使用成本。而且，HTAP系統(tǒng)具備完整的ACID能力，讓開發(fā)者擁有更多的數(shù)據(jù)寫入方式，不管是實(shí)時(shí)插入、離線導(dǎo)入、數(shù)據(jù)單條更新，都可以輕松應(yīng)對(duì)。另外，一個(gè)完備的HTAP產(chǎn)品，同樣是一個(gè)優(yōu)秀的ETL工具，開發(fā)者可以利用HTAP系統(tǒng)處理常見的數(shù)據(jù)加工需求。HTAP系統(tǒng)能夠大大節(jié)約用戶的使用成本和開發(fā)成本，并影響上層業(yè)務(wù)系統(tǒng)的形態(tài)。目前，存儲(chǔ)計(jì)算分離、云原生技術(shù)和HTAP等技術(shù)，被業(yè)界公認(rèn)為是數(shù)據(jù)庫(kù)系統(tǒng)目前的重要演進(jìn)方向。
AnalyticDB PostgreSQL版是阿里云的一款實(shí)時(shí)數(shù)倉(cāng)產(chǎn)品（以下簡(jiǎn)稱ADB PG）。ADB PG采用MPP水平擴(kuò)展架構(gòu)，支持標(biāo)準(zhǔn)SQL 2003，兼容PostgreSQL/Greenplum，高度兼容 Oracle 語(yǔ)法生態(tài)，也是一款HTAP產(chǎn)品。ADB PG已經(jīng)通過(guò)了中國(guó)信息通信研究院組織的分布式分析型數(shù)據(jù)庫(kù)和分布式事務(wù)數(shù)據(jù)庫(kù)功能和性能認(rèn)證，是國(guó)內(nèi)唯一一家同時(shí)通過(guò)這兩項(xiàng)認(rèn)證的數(shù)據(jù)庫(kù)產(chǎn)品。ADB PG早期版本主打OLAP場(chǎng)景、具備OLTP能力。隨著HTAP的流行，ADB PG自6.0版本開始對(duì)OLTP性能在多個(gè)方面進(jìn)行了大幅度優(yōu)化，其中很重要的一個(gè)項(xiàng)目就是Multi-Master項(xiàng)目，通過(guò)Scale Out打破了原有架構(gòu)的僅支持單個(gè)Master節(jié)點(diǎn)帶來(lái)的性能瓶頸問(wèn)題，讓OLTP事務(wù)性能具備Scale out能力，更好地滿足用戶的實(shí)時(shí)數(shù)倉(cāng)和HTAP需求。
Multi-Master項(xiàng)目在2019年啟動(dòng)后，經(jīng)歷了一寫多讀和多寫多讀2個(gè)演進(jìn)階段，極大的提升了ADB PG系統(tǒng)高并發(fā)能力、實(shí)時(shí)寫入/更新/查詢的能力，在阿里內(nèi)部支撐了如數(shù)據(jù)銀行等多個(gè)核心業(yè)務(wù)，也經(jīng)過(guò)了阿里2020年雙11、雙12等大促的考驗(yàn)。目前，產(chǎn)品的穩(wěn)定性和性能都已經(jīng)得到了廣泛驗(yàn)證。在本文的如下部分，我們首先介紹ADB PG原有的Single-Master架構(gòu)導(dǎo)致的性能瓶頸及其原因，并介紹Multi-Master的設(shè)計(jì)思路。然后我們會(huì)詳細(xì)介紹Multi-Master架構(gòu)的詳細(xì)設(shè)計(jì)。之后我們會(huì)介紹我們?cè)贛ulti-Master項(xiàng)目中所解決的幾個(gè)關(guān)鍵技術(shù)問(wèn)題和核心解決方案。最后，我們會(huì)對(duì)Multi-Master架構(gòu)的性能表現(xiàn)進(jìn)行測(cè)試。
?
二 ?Single-Master架構(gòu) vs. Multi-Master架構(gòu)
在數(shù)倉(cāng)系統(tǒng)設(shè)計(jì)中，通常把系統(tǒng)中的節(jié)點(diǎn)分為Master節(jié)點(diǎn)和Segment節(jié)點(diǎn)(計(jì)算節(jié)點(diǎn))，Master節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)承擔(dān)不同類型的任務(wù)。以ADB PG為例，Master節(jié)點(diǎn)主要負(fù)責(zé)接收用戶的請(qǐng)求、查詢優(yōu)化、任務(wù)分發(fā)、元信息管理和事務(wù)管理等任務(wù)。Segment節(jié)點(diǎn)負(fù)責(zé)計(jì)算任務(wù)和存儲(chǔ)管理任務(wù)。對(duì)于查詢請(qǐng)求，Master節(jié)點(diǎn)需要對(duì)用戶提交的SQL進(jìn)行解析和優(yōu)化，然后將優(yōu)化后的執(zhí)行計(jì)劃分發(fā)到計(jì)算節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)需要對(duì)本地存儲(chǔ)的數(shù)據(jù)進(jìn)行讀取，然后再完成計(jì)算和數(shù)據(jù)shuffle等任務(wù)，最后計(jì)算節(jié)點(diǎn)把計(jì)算結(jié)果返回到Master節(jié)點(diǎn)進(jìn)行匯總。對(duì)于建表、寫入等請(qǐng)求，Master節(jié)點(diǎn)需要對(duì)元信息、事務(wù)等進(jìn)行管理，并協(xié)調(diào)計(jì)算節(jié)點(diǎn)之間的工作。
如上圖所示，ADB PG是由Greenplum演化而來(lái)，早期的ADB PG版本和Greenplum一樣，是一種單Master架構(gòu)。也就是說(shuō)，一個(gè)數(shù)據(jù)庫(kù)實(shí)例只有一個(gè)Main Master在工作，配置一個(gè)或者多個(gè)Standby Master節(jié)點(diǎn)作為高可用備份，只有當(dāng)Main Master節(jié)點(diǎn)宕機(jī)，才會(huì)切換到Standby Master進(jìn)行工作。隨著業(yè)務(wù)的發(fā)展，尤其是實(shí)時(shí)數(shù)倉(cāng)和HTAP場(chǎng)景需求的增加， Single Master的系統(tǒng)瓶頸問(wèn)題也逐漸顯現(xiàn)。對(duì)于查詢鏈路，有些查詢的最后一個(gè)階段需要在Master節(jié)點(diǎn)上進(jìn)行最終的數(shù)據(jù)處理，消耗一定的CPU/內(nèi)存資源。對(duì)于寫入場(chǎng)景，大量的實(shí)時(shí)插入/更新/刪除的需要高性能保證。而且Single Master架構(gòu)如何處理超大并發(fā)連接數(shù)也是個(gè)問(wèn)題。以上問(wèn)題可以通過(guò)提高M(jìn)aster節(jié)點(diǎn)的配置(Scale up)來(lái)緩解，但是無(wú)法從根本上解決。
ADB PG在2019年啟動(dòng)了Multi-Master項(xiàng)目，目標(biāo)是通過(guò)節(jié)點(diǎn)擴(kuò)展(Scale out)的方式來(lái)解決Master層的資源瓶頸問(wèn)題，更好地滿足實(shí)時(shí)數(shù)倉(cāng)及HTAP等業(yè)務(wù)場(chǎng)景的需求。上圖是Multi-master架構(gòu)的示意圖，通過(guò)增加多個(gè)Secondary Master節(jié)點(diǎn)來(lái)實(shí)現(xiàn)性能的Scale out，同時(shí)保留原有的Standby Master來(lái)保證高可用能力。為了保障ADB PG的事務(wù)能力，Multi-master項(xiàng)目需要克服一些其他不支持事務(wù)的實(shí)時(shí)數(shù)倉(cāng)不會(huì)遇到的困難。一方面，ADB PG需要對(duì)分布式事務(wù)能力進(jìn)行擴(kuò)展，支持多個(gè)Master的場(chǎng)景。一方面，對(duì)于全局死鎖處理、DDL支持以及分布式表鎖支持方面，ADB PG需要進(jìn)行算法的創(chuàng)新和修改。最后，ADB PG需要對(duì)更新之后的新架構(gòu)的集群容錯(cuò)能力和高可用能力進(jìn)行設(shè)計(jì)。在本文的余下部分，我們將對(duì)上述幾個(gè)議題進(jìn)行介紹。
?
三 ?Multi-Master 架構(gòu)設(shè)計(jì)
相對(duì)于原Single-Master架構(gòu)，Multi-Master架構(gòu)在Main Master/Standby Master的基礎(chǔ)之上新增實(shí)現(xiàn)了Secondary Master的角色，Secondary Master(s)支持承接和Main Master一樣的DDL，DML等請(qǐng)求，同時(shí)用戶可以按需擴(kuò)展來(lái)提升系統(tǒng)整體能力。下面是各個(gè)Master角色及對(duì)應(yīng)主要能力的簡(jiǎn)單介紹。
- Main Master：承接用戶業(yè)務(wù)請(qǐng)求，并把任務(wù)分發(fā)到各個(gè)計(jì)算節(jié)點(diǎn)進(jìn)行分布式處理。除此之外，Main Master還承擔(dān)了GTM，FTS和全局元信息服務(wù)的角色，這些組件與Multi-Master的實(shí)現(xiàn)密切相關(guān)。
?
- GTM：全局事務(wù)管理(Global Transaction Manager)，維護(hù)了全局的事務(wù)id及快照信息，是實(shí)現(xiàn)分布式事務(wù)的核心組件。
?
- FTS：容錯(cuò)服務(wù)(Fault-Tolerance Service), 檢測(cè)計(jì)算節(jié)點(diǎn)及輔協(xié)調(diào)節(jié)點(diǎn)的健康狀態(tài)，并在計(jì)算節(jié)點(diǎn)發(fā)生故障時(shí)進(jìn)行計(jì)算節(jié)點(diǎn)的Primary與Mirror角色的切換。
?
- Catalog：以系統(tǒng)表Catalog等信息為代表的全局元信息存儲(chǔ)。
?
- Standby Master：和Main Master組成典型的主備關(guān)系，在原Main Master故障的時(shí)候可以接替成為新的Main Master。
?
- Secondary Master：可以視為"弱化的Main Master"，和Main Master一樣可以承接業(yè)務(wù)請(qǐng)求并將任務(wù)分發(fā)到各個(gè)計(jì)算節(jié)點(diǎn)進(jìn)行處理。Secondary Master會(huì)通過(guò)GTM Proxy與Main Master上的GTM以及計(jì)算節(jié)點(diǎn)交互來(lái)實(shí)現(xiàn)分布式事務(wù)。
?
需要注意的是，Main Master與Secondary Master通過(guò)上層的SLB來(lái)做基于權(quán)重的負(fù)載均衡管理。如果是在Main Master和Secondary Master相同的規(guī)格配置下，Main Master會(huì)通過(guò)權(quán)重設(shè)置來(lái)承擔(dān)相對(duì)少的業(yè)務(wù)請(qǐng)求負(fù)載，從而為GTM，FTS等預(yù)留足夠的處理能力。
四 ?Multi-Master關(guān)鍵技術(shù)
本章將對(duì)Multi-Master的一些關(guān)鍵技術(shù)點(diǎn)進(jìn)行詳細(xì)的介紹，主要包括分布式事務(wù)處理、全局死鎖處理、DDL支持、分布式表鎖支持、集群容錯(cuò)和高可用能力。
1 ?分布式事務(wù)管理
ADB PG的分布式事務(wù)實(shí)現(xiàn)
ADB PG的分布式事務(wù)是使用二階段提交(2PC)協(xié)議來(lái)實(shí)現(xiàn)的，同時(shí)使用了分布式快照來(lái)保證Master和不同Segment間的數(shù)據(jù)一致性，具體實(shí)現(xiàn)實(shí)現(xiàn)要點(diǎn)如下。
分布式事務(wù)由Main Master發(fā)起，并通過(guò)2PC協(xié)議提交到Segments。2PC是分布式系統(tǒng)的經(jīng)典協(xié)議，將整體事務(wù)的提交過(guò)程拆分成了Prepare和Commit/Abort兩個(gè)階段，如上面的簡(jiǎn)單示意圖所示，只有參與事務(wù)的所有Segments都成功提交整體事務(wù)才會(huì)成功提交。如果在第一階段有存在Prepare失敗的Segment，則整體事務(wù)會(huì)Abort掉；如果在第二階段有Commit失敗的Segment，而且Master已經(jīng)成功記錄了PREPARED日志，則會(huì)發(fā)起重試來(lái)Retry失敗的Commits。需要說(shuō)明的是，如果一個(gè)事務(wù)僅僅牽涉到1個(gè)Segment，系統(tǒng)會(huì)優(yōu)化為按照1PC的方式來(lái)提交事務(wù)從而提升性能，具體來(lái)說(shuō)就是將上圖中Master參與協(xié)調(diào)的Prepare和Commit兩個(gè)階段合二為一，最終由唯一參與的Segment來(lái)保證事務(wù)執(zhí)行的原子性。
?
Main Master上的GTM全局事務(wù)管理組件會(huì)維護(hù)全局的分布式事務(wù)狀態(tài)，每一個(gè)事務(wù)都會(huì)產(chǎn)生一個(gè)新的分布式事務(wù)id、設(shè)置時(shí)間戳及相應(yīng)的狀態(tài)信息，在獲取快照時(shí)，創(chuàng)建分布式快照并保存在當(dāng)前快照中。如下是分布式快照記錄的核心信息：
執(zhí)行查詢時(shí)，Main Master將分布式事務(wù)和快照等信息序列化，通過(guò)libpq協(xié)議發(fā)送給Segment上來(lái)執(zhí)行。Segment反序列化后，獲得對(duì)應(yīng)分布式事務(wù)和快照信息，并以此為依據(jù)來(lái)判定查詢到的元組的可見性。所有參與該查詢的Segments都使用同一份分布式事務(wù)和快照信息判斷元組的可見性，因而保證了整個(gè)集群數(shù)據(jù)的一致性。另外，和 PostgreSQL 的提交日志clog類似，ADB PG會(huì)保存全局事務(wù)的提交日志，以判斷某個(gè)事務(wù)是否已經(jīng)提交。這些信息保存在共享內(nèi)存中并持久化存儲(chǔ)在distributedlog目錄下。另外，ADB PG實(shí)現(xiàn)了本地事務(wù)-分布式事務(wù)提交緩存來(lái)幫助快速查到本地事務(wù)id(xid)和分布式全局事務(wù)id(gxid)的映射關(guān)系。下面讓我們通過(guò)一個(gè)例子來(lái)具體理解一下：
如上圖所示，Txn A在插入一條數(shù)據(jù)后，Txn B對(duì)該數(shù)據(jù)進(jìn)行了更新。基于PostgreSQL的MVCC機(jī)制，當(dāng)前Heap表中會(huì)存在兩條對(duì)應(yīng)的記錄，Txn B更新完數(shù)據(jù)后會(huì)將原來(lái)tuple對(duì)應(yīng)的xmax改為自身的本地xid值(由0改為4)。此后，Txn C和Txn D兩個(gè)查詢會(huì)結(jié)合自己的分布式快照信息來(lái)做可見性判斷，具體規(guī)則是：
?
基于上述規(guī)則，Txn C查到兩條tuple記錄后，通過(guò)xid和gxid映射關(guān)系找到兩條記錄對(duì)應(yīng)的gxid值(分別為100, 105)，規(guī)則c會(huì)限定Txn B的更新對(duì)Txn C不可見，所以Txn C查詢到的結(jié)果是'foo'；而Txn D基于規(guī)則則對(duì)Txn B更新后的tuple可見，所以查詢到的是'bar'。
Multi-Master的分布式事務(wù)實(shí)現(xiàn)
Multi-Master的分布式事務(wù)本質(zhì)是在原有分布式事務(wù)基礎(chǔ)之上進(jìn)行了增強(qiáng)。如上圖所示，Postmaster是守護(hù)進(jìn)程，Main Master的Backend業(yè)務(wù)處理進(jìn)程和GTM Server之間通過(guò)共享內(nèi)存通信，但Secondary Master是無(wú)法直接通過(guò)共享內(nèi)存與Main Master上的GTM Server通信的，為此，我們?cè)赟econdary Master和Main Master之間新增了一條通道并實(shí)現(xiàn)了一套GTM交互協(xié)議。另外，為了減少Secondary Master和Main Master之間的連接并提升網(wǎng)絡(luò)通信效率，我們新增實(shí)現(xiàn)了GTM Proxy來(lái)代理同一個(gè)Secondary Master上多個(gè)Backend進(jìn)程的GTM請(qǐng)求。下面，本文將從GTM交互協(xié)議 、GTM Proxy和分布事務(wù)恢復(fù)三個(gè)方面來(lái)系統(tǒng)的闡述一下Multi-Master分布式事務(wù)實(shí)現(xiàn)的技術(shù)細(xì)節(jié)。
?
（1）GTM交互協(xié)議
GTM交互協(xié)議是Secondary Master和Main Master之間事務(wù)交互的核心協(xié)議，具體協(xié)議的消息和說(shuō)明如下表所示：
| 協(xié)議核心消息 | 說(shuō)明 |
| GET_GXID | 分配gxid |
| SNAPSHOT_GET | 取分布式快照 |
| TXN_BEGIN | 創(chuàng)建新事務(wù) |
| TXN_BEGIN_GETGXID | 創(chuàng)建新事務(wù)并分配gxid |
| TXN_PREPARE | 給定的事務(wù)完成2pc的prepare階段 |
| TXN_COMMIT | 提交給定的事務(wù) |
| TXN_ROLLBACK | 回滾給定的事務(wù) |
| TXN_GET_STATUS | 取屬于指定master的所有事務(wù)狀態(tài)信息 |
| GET_GTM_READY | 檢查GTM server是否可服務(wù)正常事務(wù)請(qǐng)求 |
| SET_GTM_READY | 設(shè)置GTM server可服務(wù)正常事務(wù)請(qǐng)求 |
| TXN_COMMIT_RECOVERY | master恢復(fù)階段提交給定的事務(wù) |
| TXN_ROLLBACK_RECOVERY | master恢復(fù)階段回滾給定的事務(wù) |
| CLEANUP_MASTER_TRANS | 恢復(fù)完時(shí)清除master的剩余事務(wù) |
可以看到，消息的核心還是在交換GXID，SNAPSHOT等信息，同時(shí)做BEGIN/PREPARE/COMMIT/ABORT等事務(wù)操作，此處就不再做一一說(shuō)明。值得特別指出的是，跨節(jié)點(diǎn)的消息交互成本是很高的，考慮到OLAP用戶的特點(diǎn)和需求，我們配合協(xié)議提供了不同的一致性選項(xiàng)，從而讓用戶可以在性能和一致性上進(jìn)行權(quán)衡和選擇：
- 會(huì)話一致：同一個(gè)會(huì)話滿足可預(yù)期的一致性要求，包括單調(diào)讀，單調(diào)寫，讀自己所寫，讀后寫的一致性。
- 強(qiáng)一致：線性一致性，一旦操作完成，所有會(huì)話可見。也基于不同的一致性模式進(jìn)行了定制和精簡(jiǎn)。
如上表所示，如果用戶需要更高的性能而對(duì)于一致性可以做出一定妥協(xié)，則可以選擇會(huì)話一致模式，相對(duì)強(qiáng)一致，會(huì)話一致對(duì)協(xié)議交互進(jìn)行了大幅度精簡(jiǎn)，僅僅保留了 GET_GXID和 GET_GXID_MULTI ：
| 協(xié)議核心消息 | 說(shuō)明 |
| GET_GXID | 分配gxid |
| GET_GXID_MULTI | 批量分配gxid |
?
（2）GTM Proxy的實(shí)現(xiàn)
在Multi-Master的實(shí)現(xiàn)中，GTM Proxy是作為Postmaster的子進(jìn)程來(lái)管理的，這樣做的好處是：1) 無(wú)需新增新的角色，配套管控更簡(jiǎn)單；2) ?GTM Proxy和Backend之間是天然認(rèn)證和互信的；3) GTM Proxy可以通過(guò)共享內(nèi)存和Backend進(jìn)程通信，這樣相比Tcp Loopback更高效，既可以減少內(nèi)存拷貝，也無(wú)Network Stack開銷。
每個(gè)GTM Proxy進(jìn)程會(huì)和GTM server建立一個(gè)網(wǎng)絡(luò)連接，并會(huì)服務(wù)多個(gè)本地的backend進(jìn)程，將它們的GTM請(qǐng)求轉(zhuǎn)發(fā)給GTM server。GTM Proxy還針對(duì)性的做一些請(qǐng)求優(yōu)化處理，如：
- Backends間共享Snapshot，從而減少Snapshot請(qǐng)求數(shù)
- 合并和批處理Backends的并發(fā)GTM請(qǐng)求
- 批量獲取gxid（會(huì)話一致）
?
GTM Proxy是減少Secondary Master和Main Master之間連接并提升網(wǎng)絡(luò)通信效率的關(guān)鍵。事實(shí)上，在實(shí)現(xiàn)中，如果用戶開啟了強(qiáng)一致模式，我們?cè)贛ain Master上會(huì)默認(rèn)開啟GTM Proxy來(lái)代理Main Master上多個(gè)Backend進(jìn)程與GTM Server之間的請(qǐng)求，從而進(jìn)一步降低GTM Server的壓力。
（3）分布式事務(wù)的恢復(fù)
在很多情況下系統(tǒng)都需要做分布式事務(wù)的恢復(fù)處理，比如系統(tǒng)/Master重啟，Main Master/Standby Master切換等，當(dāng)不考慮Multi-Master，分布式事務(wù)的恢復(fù)可以簡(jiǎn)單劃分為如下3大步驟：
?
上面的流程如果進(jìn)一步考慮Multi-Master，那么一些新的問(wèn)題就引入了進(jìn)來(lái)，核心需要解決的有：1）Secondary Master發(fā)起的事務(wù)的恢復(fù)；2) Segments和Secondary Master上殘留Prepared階段的事務(wù)在Secondary Master或者M(jìn)aster重啟等情況下的恢復(fù)/清理等等。為此，針對(duì)Multi-Master，我們對(duì)二階段事務(wù)的提交和分布式事務(wù)的恢復(fù)流程都做了增強(qiáng)，如下主要講一下二階段事務(wù)提交的增強(qiáng)和Secondary Master被刪除及第一次啟動(dòng)時(shí)對(duì)應(yīng)的清理流程：
此外，Main Master/Secondary Master重啟的流程也進(jìn)行了增強(qiáng)，這里面和原Main Master重啟恢復(fù)的主要差別是需要區(qū)分出屬于自己發(fā)起的分布式事務(wù)，具體的區(qū)分是通過(guò)增強(qiáng)GXID來(lái)實(shí)現(xiàn)的。我們?cè)谠綠XID的基本信息之上添加了masterid信息，這樣{GXID}-MasterID結(jié)合起來(lái)，就可以基于GXID來(lái)區(qū)分出具體的Master了。
?
2 ?全局死鎖檢測(cè)
ADB PG 4.3版本是通過(guò)對(duì)表加寫鎖來(lái)避免執(zhí)行UPDATE和DELETE時(shí)出現(xiàn)全局死鎖。這個(gè)方法雖然避免了全局死鎖，但是并發(fā)更新的性能很差。ADB PG從6.0開始引入了全局死鎖檢測(cè)。該檢測(cè)進(jìn)程收集并分析集群中的鎖等待信息，如果發(fā)現(xiàn)了死鎖則殺死造成死鎖的進(jìn)程來(lái)解除死鎖，這樣極大地提高了高并發(fā)情況下簡(jiǎn)單查詢、插入、刪除和更新操作的性能。ADB PG 6實(shí)現(xiàn)全局死鎖檢測(cè)的要點(diǎn)如下：
- 全局死鎖檢測(cè)服務(wù)進(jìn)程（GDD）運(yùn)行在Main Master上
- GDD會(huì)周期性獲取所有segment上的分布式事務(wù)的gxid及其等待關(guān)系
- GDD構(gòu)造全局的事務(wù)等待關(guān)系圖，檢測(cè)是否成環(huán)，如果成環(huán)，則回滾環(huán)中一個(gè)事務(wù)，破解死鎖
?
ADB PG Multi-Master的全局死鎖檢測(cè)整體也是ADB PG 6.0版本的實(shí)現(xiàn)來(lái)增強(qiáng)的，如下圖所示：
ADB PG Multi-Master的GDD也運(yùn)行在Main Master之上，主要新增了兩個(gè)Master-to-Master的RPC調(diào)用來(lái)采集由Secondary Master發(fā)起的分布式事務(wù)gxid列表以及通知Secondary Master去破解負(fù)責(zé)分布式事務(wù)的死鎖。
- Get_gxids: 從每個(gè)secondary master獲取gxid列表，以判斷導(dǎo)致死鎖的事務(wù)各屬于哪些master
- Cancel_deadlock_txn: 如果導(dǎo)致死鎖的事務(wù)屬于某個(gè)secondary master，則請(qǐng)求該master回滾掉該事務(wù)
?
3 ?DDL支持
在ADB PG的原生實(shí)現(xiàn)中，Main Master對(duì)DDL的支持和與Segments上Catalog的修改同步是通過(guò)2PC的方式實(shí)現(xiàn)的，ADBPG Multi-Master擴(kuò)展了這一實(shí)現(xiàn)來(lái)支持對(duì)Secondary Master上Catalog的同步。
此外, Secondary Master也支持處理DDL，簡(jiǎn)單說(shuō)來(lái)，我們?cè)赟econdary Master內(nèi)部實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的代理，Secondary Master如果收到DDL請(qǐng)求，會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給Main Master來(lái)處理。具體如下圖所示：
DDL的實(shí)現(xiàn)非常復(fù)雜，真實(shí)的落地其實(shí)要比上面復(fù)雜很多，也牽涉到很多細(xì)節(jié)，比如VACCUM/CLUSTER/ANALYZE等相對(duì)特殊的DDL處理，但整體的實(shí)現(xiàn)方案都基本遵從上面的原則。
4 ?分布式表鎖
眾所周知，在數(shù)據(jù)庫(kù)的實(shí)現(xiàn)里，為支持對(duì)表數(shù)據(jù)的并發(fā)訪問(wèn)，一般都會(huì)通過(guò)鎖來(lái)實(shí)現(xiàn)。ADB PG的鎖模型和PostgreSQL是兼容的，具體如下表所示：
Multi-Master對(duì)ADB PG的表鎖協(xié)議進(jìn)行了增強(qiáng)和適配，總結(jié)起來(lái)，我們定義了一套新的分布式表鎖協(xié)議來(lái)規(guī)范Main Master及Secondary Master上加鎖的順序和規(guī)則：
任意Master上的進(jìn)程請(qǐng)求1-3級(jí)鎖
- 本地請(qǐng)求該表鎖
- 在所有Segments上請(qǐng)求該表鎖
- 事務(wù)結(jié)束時(shí)所有節(jié)點(diǎn)釋放鎖
Main Mater上的進(jìn)程請(qǐng)求4-8級(jí)鎖
- 本地請(qǐng)求該表鎖
- 在所有Secondary master上請(qǐng)求該表鎖
- 在所有Segments上請(qǐng)求該表鎖
- 事務(wù)結(jié)束時(shí)所有節(jié)點(diǎn)釋放鎖
Secondary Master上的進(jìn)程請(qǐng)求4-8級(jí)鎖
- 在Main Master上請(qǐng)求該表鎖
- 本地請(qǐng)求該表鎖
- 在所有其他Secondary Master上請(qǐng)求該表鎖
- 在所有Segments上請(qǐng)求該表鎖
- 事務(wù)結(jié)束時(shí)所有節(jié)點(diǎn)釋放鎖
?
基于上述規(guī)則，我們可以實(shí)現(xiàn)任何的表鎖請(qǐng)求會(huì)最終在某個(gè)Master或者Segment得到裁決，從而保證了對(duì)ADB PG的原表鎖協(xié)議的兼容。
?
5 ?集群容錯(cuò)與高可用
ADB PG是通過(guò)復(fù)制和監(jiān)控來(lái)實(shí)現(xiàn)容錯(cuò)和高可用的，主要包括：1）Standby Master和Mirror Segment分別為Main Master和Primary Segment提供副本(通過(guò)PG流復(fù)制實(shí)現(xiàn))；2）FTS在后臺(tái)負(fù)責(zé)監(jiān)控與主備切換。如上圖中的流程：
?
簡(jiǎn)單說(shuō)來(lái)，ADBPG Multi-Master在原ADB PG的容錯(cuò)和高可用基礎(chǔ)之上進(jìn)行了增強(qiáng)，讓系統(tǒng)能夠進(jìn)一步對(duì)Secondary Master進(jìn)行兼容。另外，Secondary Master如果故障，則會(huì)進(jìn)一步由管控系統(tǒng)看護(hù)并做實(shí)時(shí)修復(fù)。
五 ?Multi-master 擴(kuò)展性能評(píng)測(cè)
ADB PG單Master實(shí)例在高并發(fā)點(diǎn)查、導(dǎo)入等偏OLTP的場(chǎng)景往往會(huì)存在單Master瓶頸，而Multi-Master的引入很好的解決了問(wèn)題。為了驗(yàn)證Multi-Master在OLTP負(fù)載下橫向擴(kuò)展的能力，本章節(jié)對(duì)ADB PG Multi-Master在默認(rèn)的會(huì)話一致模式下的TPC-B/C兩種典型負(fù)載進(jìn)行了性能測(cè)試。
1 ?TPC-C性能測(cè)試
TPC-C是事務(wù)處理性能委員會(huì)(TPC)旗下一的一個(gè)主流性能測(cè)試Benchmark集合，主要是測(cè)試數(shù)據(jù)庫(kù)系統(tǒng)的事務(wù)能力。TPC-C測(cè)試過(guò)程中，會(huì)實(shí)現(xiàn)多種事務(wù)處理并發(fā)執(zhí)行、在線與離線事務(wù)混合執(zhí)行等方式，能夠比較全面地考察數(shù)據(jù)庫(kù)系統(tǒng)的事務(wù)能力。我們采用的測(cè)試環(huán)境是基于阿里云ECS的ADB PG實(shí)例，具體參數(shù)如下：
- Master（Main Master/Secondary Master)：8c64g
- 節(jié)點(diǎn)規(guī)格(segment)：4C32G
- 節(jié)點(diǎn)數(shù)量(segment): 32
- 存儲(chǔ)類型：ESSD云盤
- 節(jié)點(diǎn)存儲(chǔ)容量(segment): 1000GB
可以看到，在只有1個(gè)Master時(shí)，當(dāng)并發(fā)數(shù)到達(dá)64時(shí)，TPC-C的性能基本達(dá)到峰值，無(wú)法再隨著并發(fā)數(shù)增加而增加，但是當(dāng)有4個(gè)Masters時(shí)，隨著并發(fā)數(shù)的增加TPC-C的性能依舊可以非常好的線性擴(kuò)展。
2 ?TPC-B性能測(cè)試
TPC-B是TPC旗下另一個(gè)性能測(cè)試Benchmark集合，主要用于衡量一個(gè)系統(tǒng)每秒能夠處理的并發(fā)事務(wù)數(shù)。我們采用的測(cè)試環(huán)境是基于阿里云ECS的ADB PG實(shí)例，具體參數(shù)如下：
- Master（Main Master/Secondary Master)：8c64g
- 節(jié)點(diǎn)規(guī)格(segment)：4C32G
- 節(jié)點(diǎn)數(shù)量(segment): 32
- 存儲(chǔ)類型：ESSD云盤
- 節(jié)點(diǎn)存儲(chǔ)容量(segment): 1000GB
可以看到，和TPC-C類似，在只有1個(gè)Master時(shí)，當(dāng)并發(fā)數(shù)到達(dá)64時(shí)，TPC-B的性能基本達(dá)到峰值，無(wú)法再隨著并發(fā)數(shù)增加而增加，但是當(dāng)有4個(gè)Masters時(shí)，隨著并發(fā)數(shù)的增加TPC-B的性能依舊可以非常好的線性擴(kuò)展。
六 ?總結(jié)
ADB PG Multi-Master通過(guò)水平擴(kuò)展Master節(jié)點(diǎn)很好的突破了原架構(gòu)單Master的限制，配合計(jì)算節(jié)點(diǎn)的彈性，系統(tǒng)整體能力尤其是連接數(shù)及讀寫性能得到進(jìn)一步提升，可以更好的滿足實(shí)時(shí)數(shù)倉(cāng)及HTAP等業(yè)務(wù)場(chǎng)景的需求。
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的揭秘！阿里实时数仓分布式事务Scale Out设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 从理念到实践跳跃式演进！ 云的原生“免疫
- 下一篇： 用 Mars Remote API 轻松