金融行业核心系统最佳搭档｜如何基于 PolarDB 分布式版打造两地三中心架构？
作者：阿里云数据库 PolarDB 分布式团队 七锋
本文是《PolarDB-X 致数据库行内人》专栏系列的第二篇，本系列其他文章：《数据库内核那些事｜分布式数据库，挂掉两台机器会发生什么》
缘起
在今年云栖大会的数字金融论坛上，我们分享了大型金融机构核心系统如何采用云原生数据库 PolarDB 分布式版（PolarDB for Xscale，以下简称 PolarDB-X），实现多个系统升级和改造，并详细介绍并总结了 PolarDB 分布式版在大型银行、股份制银行、证券系统、保险业务等应用场景的落地与最佳实践。
视频回放详见《数智金融 数字金融核心技术硬核实践》
本篇文章是对我们在云栖大会所分享内容的技术补充，期望从数据库架构设计的视角，分享 PolarDB 分布式版在大型银行的落地经验，介绍 Paxos 多副本+传统两地三中心上的技术思考。
金融行业的容灾需求
在金融行业中，容灾是非常重要的，因为金融交易和金融数据的安全性和连续性对于银行和金融机构来说至关重要。金融行业一般有 4 级和 5 级容灾需求，分别代表了不同的容灾级别和要求。
参考：
4 级容灾：较低级别的容灾需求，通常同城容灾，确保同城网络的冗余性和故障切换能力。
5 级和 6 级容灾：更高级别的容灾需求，要求多地容灾，需要建立多个数据中心，在主要数据中心不可用时能够快速切换到备用系统，针对 6 级在异地副本数、备份周期频率、恢复 RTO 上会有更明确的要求。
一般银行的核心业务普遍要求 5 级容灾，考虑多数据中心的建设成本，当前金融行业普遍的 5 级容灾形态为两地三中心架构，典型的网络拓扑架构：
两地三中心对于数据库的需求
跨机房容灾，推荐 Paxos/Raft 多数派共识算法
在文章中《数据库内核那些事｜分布式数据库，挂掉两台机器会发生什么》，我们简单论证过对于数据有一定的重要性场景，都不应该选择主备架构的产品（包含 MySQL Semi-sync 半同步，也有网络降级为异步丢数的风险），而金融行业尤其重视机房级别的容灾（比如主机故障、断网脑裂等），推荐使用 Paxos/Raft 多数派协议的数据库，从多数派共识算法的原理层面可以很好的满足一致性要求。
目前主流分布式数据库基本都选择 Paxos\Raft（包括其他变种协议），其共通点是，每份数据会存在多个副本，并且能够保证在一个副本挂掉的情况下，不影响可用性，并且不会出现任何一致性问题（脑裂、丢数据、丢更新等）。
本文同样无意去解析 Paxos\Raft 协议，我们需要思考结合两地三中心架构，进一步思考新一代基于 Paxos 多副本的数据库，如何满足金融的严苛要求。
我们将进一步探讨几个问题：
1. 一个业务的两地三中心，同城和异地，数据库是一个实例还是多个实例，以及如何满足 RPO 和 RTO？
2.业务对接分布式数据库有单元化诉求，单元化要求数据库切主同机房优先，如何满足单元化？
3. Paxos/Raft 多数派共识算法，如何优化跨机房数据复制、以及如何满足机房故障场景？
4. 分布式事务遇到两地三中心，是否会有数据一致性问题？
5. 数据库日常的容灾演练能力，如何构建面向不同故障场景下的模拟演练？
1. 中心主实例＋异地灾备实例
按照两地三中心的 5 级容灾，同城每个机房至少需要 2 副本+异地至少需要 1 个副本，因此基于 Paxos 多数派的需求，两地三中心比较合理的架构是采用 5 副本。
针对第一个问题，一个业务的两地三中心，PolarDB-分布式数据库的设计上是：中心主实例（5 副本）+异地灾备实例（2 副本），基于可以满足 RPO/RTO 以及故障演练场景的诉求，文章后续通过架构逐步演进的思路来介绍两地三中心的方案。
▶︎ 中心主实例
初始的架构设计
基于 Paxos 协议经常被咨询的一个问题：如果机房容灾，多数派副本挂了，异地容灾能否提供服务？
映射到两地三中心 5 副本的初始架构，思考 RPO/RTO 的相关问题：
1. 中心机房 A 挂了，剩余 3 副本，可以满足多数派。此时，RPO=0 且 RTO<30，可以满足 paxos 多数派协议的自动切换。
2. 中心机房 B 挂了，如同上一条的 A 机房挂了的场景。
3. 中心地域挂了，机房 A 和机房 B 不可用，此时仅剩异地的 1 个副本，不满足多数派且异地 RPO>0，这种场景下数据库比较难以自动恢复，需要结合 RTO 场景思考数据库的能力。
异地单副本启动
在中心地域挂了，异地仅剩单副本时，PolarDB-X 提供了一种单副本启动的方式（一键需改元数据+强制重启），重新提供服务。
这种故障恢复模式下，可以作为一种应急能力，但 RTO 的时间取决于运维同学介入+手工操作恢复的总时间（登录一堆数据库主机挨个重启节点），RTO 比较难有严格时效性的保障。
同时，异地单副本启动模式对于故障演练场景的需求来看，即使有预期也会对当前业务有损（需要重建数据库），不太具备故障演练的能力。
▶︎ 异地灾备实例
架构形态：
中心主实例+异地灾备实例，采用数据异步复制+双向同步。
异地灾备实例，推荐选择为一个独立的 Paxos3 副本实例，结合 PolarDB-X 的 Logger 副本类型，最后等价于 2 副本模式。
PolarDB-X 支持的副本类型：
基于异地灾备实例，继续考虑中心地域故障的场景：
中心主实例仅剩异地 1 副本，不满足多数派，此时中心主实例不可服务，可以快速切流量到异地灾备实例，可以满足 RTO<1 分钟。
故障演练场景，可以切流量到异地灾备实例，此时基于双向同步的机制，异地灾备实例数据可以同步会中心主实例，演练过程对于数据没有太大的影响。
2. 分布式＋单元化
金融行业随着业务的发展，普遍都会有单元化的诉求，业务对于单元化的诉求：
业务单元化，将原本一个业务拆分为 N 个单元，每个单元承担部分流量，个别单元故障时可以隔离故障爆炸半径，避免影响业务整体。
分布式扩展性，将不同单元调度到不同资源上，实现业务的线性扩展性。
业务对于单元化的诉求，通过分布式数据库的分布式拆分机制，有比较好的技术契合度，这也是金融行业对于分布式数据库比较热衷的一个原因。
▶︎ 单元化分片
PolarDB-X 分布式数据库，考虑单元化适配后，此时的架构设计：
如上图所示：
业务单元划分：中心地域 2 机房 4 单元，相当于每个机房有 2 个单元，每个单元有自己独立的主机硬件和交换机。
分布式适配：PolarDB-X 数据库的数据节点 DN 的数量，推荐是单元数量的整数倍，比如 4、8、12、16 等。每个 DN 的多个副本，确保每个单元都有 1 个副本，同时需要调度不同分片 DN 的 Leader 到对应的单元，最后的效果：每个单元内都有数据库全量数据，分片 Leader 各自均匀分布。
数据库和表：适配单元化的分片和对应的 DN。比如总计 4 个 DN（DN1~DN4），数据分片 128 份，单元化的数据分片规则就是：分片 0~31（DN1）、分片 32~63（DN2）、分片 64~95（DN3）、分片 96~127（DN4）。
单元化分片算法：适配业务单元调度。比如按照用户 Id 进行单元化，按照 Hash 算法进行适配，业务流量和数据库的分片单元进行对齐，最后达到业务流量访问同机房 DB 的效果。
这里基于单元化的结构设计，针对数据库有隐形的需求：
a) 中心主实例，异地副本不能选为 Leader，否则单元会有跨地域访问的场景，导致 RT 异常。
b) 1 个机房包含 2 个单元，如果遇到一个单元的 DN 副本故障时，优先切换到同机房的 DN 副本，尽可能保证业务和单元之间的同机房路由。
▶︎ Paxos 选举权重
PolarDB-X 分布式数据库，在 Paxos 协议部分引入了选举权重设计：
乐观权重机制：多数派共识算法 Paxos 在选举策略中优先发起选举容易成为 Leader，引入权重后我们针对不同的节点引入随机延迟发起 Leader 选举的时间差，确保高权重的节点优先触发 Leader 选举。
强制权重机制：当某一新成为 Leader 的节点，发现自己不是所有节点中权重最高的节点的时候（当所有节点权重一致的时候，任意节点都是权重最高的点，所以此判定不生效），不会立刻放开写入，而是继续等待一个选举超时的时间段（称为禅让阶段），在禅让阶段会每隔一个心跳时间（比如 1~2 秒），向其它节点发送一次心跳探测。在选举时间段结束以后，如果收到其他权重比自己大的节点回包，即向回包节点中权重最大的节点发起一次 Leader 转移，确保高权重的节点成为 Leader。
4 个 DN 分片为例子：
整体权重按照 9/7/5/3/1，权重策略说明：
同机房的单元分配 9 和 7 的权重，确保权重为 9 的 Leader 故障时，优先选择同机房的权重为 7 的副本。
异地数据中心，分配到的权重为 1，权重为所有副本中最低，确保 Leader 不会调度到异地机房。
3. 跨机房复制
Paxos/Raft 多数派共识算法，会涉及跨机房的数据同步，在两地三中心场景下，需要考虑两种 case：
常态下，跨机房复制到同城或异地副本，相比于同机房，网络延迟差距比较大，如何优化对应的网络同步效率？
容灾场景（故障或者演练），中心一个机房出现不可用，此时原本的 5 副本，会变成只有 3 副本正常工作。虽然 3 副本也满足多数派，但涉及了异地机房的强同步，此时如何优化对应的网络同步效率？
▶︎ Paxos 网络同步优化
PolarDB-X 分布式数据库，在 Paxos 协议上针对高延迟网络做了大量的协议优化尝试和测试，并结合学术界现有的理论成果，通过合理的 Batching 和 Pipelining，设计并实现了一整套自适应的针对高延迟高吞吐和低延迟高吞吐网络的通信模式，极大的提升了 Paxos 协议的性能。
Batching
将多个日志合并成单个消息进行发送，Batching 可以有效的降低消息粒度带来的额外损耗，提升吞吐。但是过大 Batching 容易造成单请求的延迟过大，导致并发请求数过高，继而影响了吞吐和请求延迟。
Pipelining
在上一个消息返回结果以前，并发的发送下一个消息到对应节点的机制，通过提高并发发送消息数量（Pipelining 数量），可以有效的降低并发单请求延迟，同时在 transmission delay 小于 propagation delay 的时候（高延迟高吞吐网络），有效提升性能。
因 Pipeling 的引入，需要解决日志的乱序问题，特别是在异地场景下，Window 加大，加大了乱序的概率。PolarDB-X 实现了一个高效的乱序处理模块，可以对底层日志实现屏蔽乱序问题，实现高效的乱序日志存储。另外，由于 Paxos 的内部状态复杂，PolarDB-X 基于多线程实现 Paxos、以及结合 Group Commit 技术，利用异步化技术来达到最大化的吞吐。
针对跨域网络的场景，我们用 5 台 ECS 机器模拟了两地三中心架构的 5 副本，来验证 Paxos 网络同步优化的效果：
两地三中心的跨地域网络，相比于同机房的多副本，性能下降差异在 5~10%内。
▶︎ 副本数动态调整
两地三中心中，5 副本多数派的复制组，需要>=3 个副本完成同步响应，默认情况主中心的 4 副本会因为网络延迟的优势，优先在同城完成多数派的同步响应，多数派协议的延迟基本在 1ms 左右。但出现中心机房级别的故障后仅剩余 3 副本，会导致必须等待备份中心的副本也同步响应，导致多数派协议的延迟增加 30ms。（比如常见的金融行业中主中心和备份中心的网络延迟在 30ms 左右）。
PolarDB-X 分布式数据库，在 Paxos 协议设计上支持了副本数动态调整的能力，比如常见的副本数调整场景：
➠ 机房故障：5 副本降级为 3 副本，引入 Downgrade_follower 指令将 Follower 角色降级 Learner 角色，动态修改两个副本的角色；
➠ 机房恢复：3 副本升级为 5 副本，引入 Upgrade_Learner 指令将 Learner 角色升级为 Follower 角色，需要确保 Learner 异步复制日志追平；
➠ 单副本恢复多数派：1 副本升级为 3 副本，引入 Add_follower 指令动态新增节点，新节点会先成为 Learner 角色，追平日志之后自动转成 Follower 角色。
中心单机房故障场景，模拟 5 副本降级为 3 副本：
1. 通过控制台或者命令行，操作将对应机房的副本状态进行切换，动态降级为 Learner 角色（异步复制，不参与多数派）。
2. 查看数据库内核多副本的状态，5 副本变为 3 副本+2Learner 副本，此时多数派的投票变更为 3 副本。
3. 机房故障恢复后，可以通过副本重建的方式动态恢复。
4. 分布式事务一致性
分布式数据库，是将数据存储在多个节点上的数据库系统。分布式事务能够保证多个数据库节点上的数据在事务执行过程中保持一致，避免因为网络故障、系统故障或节点失效等原因导致数据不一致的问题。因此，两地三中心架构下也要深度论证分布式事务的一致性问题。
在文章中《分布式数据库，如何有效评测国产数据库的事务一致性》，PolarDB-X 在设计分布式事务机制时也讨论过容灾架构下的数据一致性问题。
容灾架构（两地三中心、同城 3AZ），典型的容灾架构场景，比如考虑两地三中心的极端场景，中心地域挂了，切换到异地机房，异地机房的数据可以有延迟(RPO>0)，但需要事务粒度的一致性，满足 A 和 B 上的账户总余额为 100。
如上图所描述，分布式多个 Paxos 复制组下，异地副本会出现复制进度不一致。如果遇到异地容灾切换，多个复制组各自的 RPO 不一致，最终会导致分布式事务的数据不一致。
额外思考一个问题：普通级别故障，比如：中心单节点故障、单机房故障，因为中心 5 副本的机制满足 RPO=0，分布式事务的一致性是可以保证的。
▶︎ CDC 事务日志复制
PolarDB-X 分布式数据库，分布式事务针对容灾场景，引入日志组件 CDC 解决事务一致性的问题，CDC 的基本工作原理：
CDC binlog 文件：采集多个 DN 多副本的本地日志，进行汇众归并和排序，按照分布式事务的 TSO 版本进行乱序重排，最终产出分布式事务的 binlog 日志（兼容 MySQL binlog 的完整格式）
CDC Replication 协议：允许分布式数据库下游按照 MySQL 主备复制的 replication 协议，比如：Change master 和 Binlog dump。
更多 CDC 的技术文章解读，可以参考《PolarDB-X全局Binlog解读》。结合 PolarDB-X 分布式完整能力，基于 CDC 优化中心主实例+灾备实例的复制机制，两地三中心的架构推荐：
▶︎ 异地就近访问
在两地三中心场景下，网络专线带宽是重要资源，需要在数据库的内部处理上尽可能减少不必要的数据访问，常见的网络访问诉求：
Paxos 多副本之间的数据同步，必要的数据同步，可以采用压缩优化网络带宽。
CDC 事务日志的采集和同步。
业务在异地访问数据库，比如报表或者对账。
PolarDB-X 分布式数据库，针对异地 CN/CDC 访问底下 DN 节点，引入了异地就近访问的设计，要求异地的组件就近访问同机房的 DN，减少无谓的专线网络带宽访问。
设计 1：CN 异地就近访问 DN
CN 的默认规则是访问 DN 多副本的 Leader 节点，支持通过类似读写分离的机制访问 follower 副本。在两地三中心场景下，CN 引入异地只读实例的形态，产品定义：
异地 CN 默认访问异地的 follower 副本，获取元数据才会路由 GMS Leader 节点（主数据中心）
异地 CN 默认提供只读能力，禁止 DML/DDL，避免用户在异地误操作（比如：异地写入会转发到主数据中心的 Leader 节点，因为网络延迟会带来事务提交的 RT 比较高，增加事务行记录锁的开销）
设计 2：CDC 异地就近访问 DN
CDC 的默认规则是访问 DN 多副本的 Leader 节点，采集 Leader 节点最新的本地 binlog，再进行归并和排序，按照分布式事务的语义生成最终的分布式事务日志 binlog。
在两地三中心场景下，CDC 访问 DN follower 副本，因为网络 30ms 的延迟，在数据归并和排序时需要额外等待完整的分布式事务日志，增加一定的阻塞开销。CDC 针对跨地域的网络场景做了针对性的优化，比如 Batching & Pipeling 处理、以及面向分布式的多流 binlog 能力。
针对跨域网络的 CDC 访问 DN 场景，我们通过 ECS 机器模拟了两地三中心场景：
CDC 异地就近访问，相比于同机房的场景，性能约为 30~60%左右，可以支持百万 TpmC 的业务（模拟 TPC-C 测试）。
▶︎ 一致性备份恢复
两地三中心架构，金融行业对于数据库的事务一致性要求同样适用于备份恢复，同时针对备份集也有特定的灾备需求，比如数据库备份存储需要对接银行内部的备份机，一般基于 S3 协议的存储设备，存储设备本身会有自己的灾备机制来容错。
PolarDB-X 分布式数据库，在分布式备份上针对两地三中心的容灾需求，比如：5 级容灾对于备份频率有明确的要求、以及全量+增量备份互补，因此对于分布式大规模存储下，除了备份一致性还有时效有要求。
分布式并行备份
阿里云上常见 MySQL 数据库基于 Xtrabackup 物理备份速度在 100~300MB/s，按照分布式 128 节点（每个节点 1TB 的存储容量来算），128TB 的数据存储传统备份的时间 124~372 小时，这显然不符合备份时效要求。
PolarDB-X 分布式数据库，技术上采用分布式的并行备份的策略，分布式 128 个节点，每个节点单独执行物理备份，总的 128TB 的数据基于分布式备份的时间理论值是 1~3 小时（会受限于备份存储介质的 IO 带宽上限）。
分布式下的一致性
传统分库分表模式也会采用每个节点并发备份和恢复，但并发物理备份会导致多个节点之间没有任何关系，如果有涉及分布式事务的场景下，每个节点的独立备份并不保证事务的一致性，因此带来了很多数据一致性层面的问题。
PolarDB-X 分布式数据库，结合分布式物理备份的前提下，引入了分布式一致性备份机制（PolarDB-X备份恢复），基本原理就是在物理备份完成后，通过分布式事务埋点找补一段时间的增量日志，补齐不同节点上缺失的分布式事务日志。基于全量物理备份+增量逻辑备份的方式，确保分布式事务数据的一致性。
▶︎ 异地 RPO 计算
两地三中心架构，对于异地容灾切换时需要精确统计对应 RPO 的情况，基于 RPO 的数据可以结合业务对账来回补对应的数据。
PolarDB-X 分布式数据库，结合分布式事务、主实例+灾备实例的架构，分解了一下异地 RPO 详细计算的过程。
这里包含 4 个时间：
时间 T1，业务在主中心实例上事务写入的最后一个版本时间戳（PolarDB-X 有每秒执行的心跳 SQL，确保 T1 时间约等于当前系统时间）；
时间 T2，分布式多个 Paxos 复制组，各自数据同步到异地，求取最小的版本时间戳，因为网络延迟，相比于时间 T1 至少约有 30ms+的网络延迟；
时间 T3，构建分布式事务日志的时间，采集分布式的多个异地 Follower，以最后的版本时间戳为上限，采集时间的延迟相比于 T2 约有 100ms 左右的延迟；
时间 T4，事务日志数据同步到灾备实例的最后更新时间戳，数据同步的延迟正常也在秒级左右。
基于 4 个时间戳的定义，异地容灾 RPO=T4-T1≈T4-now()，常态情况下在秒级左右（1~3 秒）。
PolarDB-X 异地灾备实例是独立于中心地域的架构，在异地容灾时可以通过灾备实例的时间 T4 来计算最后的 RPO，常态下可以对接银行的监控来实时采集时间 T1~T4。
5. 常态容灾演练
基于两地三中心架构，金融业务按照监管要求，会定期做容灾演练来提前验证，确保真实故障时可以正常切换。数据库在产品设计上，需要提供预期内容灾演练的能力。PolarDB-X 分布式数据库，梳理了容灾演练的多种场景，并提供基于 DBStack 管控的 WebUI 和 OpenAPI 容灾演练能力。
单 DN 节点切换
机房容灾切换
常见的故障演练操作
总结
业界有众多分布式数据库在金融银行领域，落地了两地三中心架构，但在架构的技术细节介绍上偏少，更多只是介绍基于 Raft/Paxos5 副本的部署机制，这并不满足银行核心系统上线两地三中心的容灾诉求。
PolarDB-X 推荐的两地三中心架构形态：
本文基于云原生数据库 PolarDB 分布式版在大型银行两地三中心架构的落地实践，分享了我们在实践过程中的细节和思考，避免数据库研发、以及金融银行在技术选型时少走弯路，也非常欢迎大家提出宝贵的意见。
最后，回过头回答下最开始提出的 5 个问题：
1. 一个业务的两地三中心，同城和异地，数据库是一个实例还是多个实例，以及如何满足 RPO 和 RTO？
推荐主备实例（主中心实例+异地灾备实例）的组合模式，可以更好满足容灾演练，中心地域容灾可以满足 RPO=0 且 RTO<30 秒，异地容灾因为异步复制 RPO>0，但满足 RTO<1 分的诉求。
单实例模式下，采用两地三中心 5 副本的架构，中心容灾时可以满足 RPO=0 且 RTO<30 秒，异地容灾时因为仅剩单副本，需要手工以单节点模式重启数据库节点，RTO 无法有效保障、以及缺少无损的容灾演练能力。
2. 业务对接分布式数据库有单元化诉求，单元化要求数据库切主同机房优先，如何满足单元化？
分布式数据库与单元化可以有很好的契合点，数据分区和 Leader 分布可以与业务单元化流量对齐，结合选举权重满足同机房流量优先的诉求。
3. Paxos/Raft 多数派共识算法，如何优化跨机房数据复制、以及如何满足机房故障场景？
Paxos 协议需要结合业务主流技术进行跨地域网络优化，同时副本数动态调整能力是一个核心诉求，从 5 副本动态降级为 3 副本，可以很好的解决机房故障时 RT 飙升的场景。
4. 分布式事务遇到两地三中心，是否会有数据一致性问题？
分布式事务在两地三中心容灾场景上，会出现事务数据同步不一致性的情况，可以引入事务级的日志复制解决，或者业务层避免使用分布式事务来绕过（市面上很多国产数据库交付的两地三中心更多是集中式数据库形态，比如基于 MySQL/MariaDB、PG 的单机主备形态）。
5. 数据库日常的容灾演练能力，如何构建面向不同故障场景下的模拟演练？
需要构建全方案的容灾演练能力，从单元 AZ/机房/地域、以及单实例、批量实例的容灾能力，需要提供 WebUI、以及 OpenAPI 方式适配现有银行系统。
微信公众号「阿里云瑶池数据库」 2023-06-19 加入
瑶池，喻指汇聚宝藏之地。阿里云瑶池数据库，汇集数据无价之宝，让数据业务持续在线，数据价值不断放大。
评论