关于数据:揭秘阿里实时数仓分布式事务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 年双 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 两个查问会联合本人的分布式快照信息来做可见性判断，具体规定是：

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 等业务场景的需要。
原文链接

本文为阿里云原创内容，未经容许不得转载。