数据库的两地三中心部署已经是很多企业重要系统的标准搭建方式，说起来很简单，但真正落地，很多细节（包括但不限于架构选型、数据一致性、应急处置等）还需要结合实际的场景进行调整，技术社群的这篇文档《自主可控数据库两地三中心部署的难点和方案思路》给我们讲解了金融行业自主可控数据库两地三中心部署的一些难点和方案，可以学习借鉴，应用到实际工作当中。
一、背景
近些年，金融行业IT技术架构更新迭代快，发展迅速，云平台、大数据、AI、微服务、分布式架构、敏捷前台、统一中台等技术架构的发展很好地契合了金融行业尤其是银行未来业务发展的需求，数据库作为其中重要环节贯穿了整个前中后端。此外，受复杂多变的国际形势影响，金融行业自主可控越来越迫切，国产化进程逐步进入深水区，国产数据库作为一项重要基础研究和应用。
自主可控数据库要在金融行业大规模应用，必须要满足金融监管业务连续性指标相关要求，其中最重要的就是RTO和RPO的要求，例如，关键业务系统RPO=0，RT0<30分钟，即故障情况下不得丢失数据，30分钟内对外恢复业务，要做到这些，自主可控数据库架构必须要具备“两地三中心”部署能力，以应对机房级灾难时数据不丢失并且能在短时间内对外恢复业务。
二、采用自主可控数据库的难点分析
国产数据库需要进行“两地三中心部署”，需要考虑以下几个难点，
1) 主从数据节点间数据的同步问题
主从数据节点间同步需要考虑同步效率和主备数据节点数据一致性之间的平衡，如果采用异步同步模式，主节点只要将同步数据发出即可释放计算资源，同步效率高，但是备节点可能存在数据丢失的风险，无法做到RPO=0；如果采用强同步模式，主节点将同步数据发送给备节点后，需要等待备节点回复收到同步数据的反馈，等待的期间计算资源被占用无法释放，因此同步效率较低。此外，如果备节点出现异常或者网络异常，主节点无法收到反馈，会直接影响业务连续性。
对于金融行业来说，RPO必须为0，因此必须要采用强同步模式，所以同步的效率需要数据库厂商进行优化，实现效率与异步模式相当，可以通过在主节点等待备节点反馈的期间将会话暂时保存，释放资源等方式实现，所以在数据库选型时需要关注主从实现的效率和方式。此外，同机房和同城跨机房主从同步设计时需要注意，同机房主从必须要设置为异步模式，同城跨机房需要设置为强同步模式，虽然牺牲了一点同步效率，但能确保跨机房数据RPO=0，做到同步效率和数据一致性之间的平衡。同时，为了尽可能减少同城间网络抖动对主节点的影响，建议在备机房设置两个强同步备机，两个强同步备机使用不同运营商线路。
2) 全局一致性的问题
分布式数据库要解决全局一致性问题，需要引入使用全局事务管理器GTM，负责全局事务的统一管理，每个事务都需要从GTM处获得唯一的全局事务，类似于Oracle的SCN号以实现全局MVCC，带来的问题就是GTM的效率和可靠性问题。由于所有事务都需要获取全局事务号，随着业务量的增加，GTM节点会成为性能瓶颈，而且一旦GTM节点出现问题，业务将中断，显然是无法接受的。因此，GTM需要采取集群可扩展模式部署，以解决效率和高可用问题，在数据库选型和两地三中心方案设计时，必须要考虑该问题，GTM效率和高可用需要重点测试（性能测试、破坏性测试以及业务功能测试等）和论证（针对数据库厂商提供的GTM实现的原理进行专家论证），同时对比GTM开启的情况下带来的性能损失，最终综合评估，在效率和高可用之间寻得最优解。
3) 单元化还是分布式数据库选择
对于国产数据库在金融行业尤其是银行业的实施案例来看，通常有单元化和分布式数据库两种部署模式。单元化部署，分布式事务通常由微服务架构去控制，用户数据通过算法进行分库分表，共用数据通过数据同步进行汇总，该架构把分布式事务交给了微服务架构，而数据库层面进行了分库分表，因此数据库在进行两地三中心部署时，同城机房内均部署全量单元数的应用微服务架构和对应的数据库，同城机房间数据库同步采用强同步模式以确保数据不丢失，单元化部署适用于业务量大的全国性大行，例如邮储、微众以及平安等银行的核心均采用单元化模式进行部署。分布式数据库模式，对应用而言是逻辑一个数据库，内部数据则分节点存放，所以分布式事务作为其内部事务，用户不必太关注分布式事务的实现，只需要重点做好数据在数据库里的分布设计，提高其运行效率即可。
三、典型两地三中心方案建议
综上所述，由于不同的场景、不同的业务规模对应的两地三中心部署模式有差别，本文接下来重点探讨一个典型的场景——交易型数据库场景，典型架构图如下（图1）：
图1：交易型数据库场景典型架构图
数据库由计算节点层、存储节点层和管控节点层组成，计算节点层主要负责应用系统的接入和数据计算，存储节点主要负责实际数据的存储更新和主从同步，管控节点负责集群的管控，全局事务的管理，主备切换，故障隔离与恢复，监控和自动化运维相关事宜。
计算节点采用多节点高可用部署，计算节点不存储数据，只进行数据计算和结果返回，所以单节点故障不影响其他计算节点运行。同城两机房计算节点均部署N台（N由具体业务量和计算量确定，N≥2），同城两机房均可接入业务，同时实现节点级和机房级高可用，确保业务连续性。
存储节点采取一主多备模式进行部署，存储节点数量M由业务量确定（M≥1）,同步模式采用同机房异步，同城异机房强同步模式，以确保跨机房数据一致性，此外为减少机房间链路抖动对同步的影响，建议同城异机房设置两个强同步节点并使用两种不同运营商链路。故障恢复方面，当主DB出现故障时，系统需要具备自动切换到备DB对外恢复业务的能力，通常在20-30秒左右比较合适，太小的话可能造成性能高峰频繁误切，太长会导致业务影响时间太长，所以在设计时通常考虑RTO≤30S即可。
管控节点是需要三机房部署，单机房出现故障时进行仲裁，防止出现脑裂情况。
除管控节点外，异地机房还需要部署对应的计算节点和存储节点，与本地数据库实例进行异步同步，应用根据实际情况在异地机房部署。
以上场景仅为典型案例，具体情况还有根据机房环境、网络条件以及业务接入情况等实际情况进行方案调整。例如很多银行单位有集中式存储设备资源，也可以采用“数据库+集中式存储”的架构方案搭建，重要类数据采用存储3DC的方式实现数据的物理和逻辑的多副本多重保护。
四、因此
本文对自主可控数据库在金融行业尤其是银行业多种场景情况下的两地三中心模式进行了探讨，并结合自身实践经验重点对典型的交易型数据库模式进行了方案建议，旨在对正在进行自主可控数据库选型或者实施的同行有所借鉴。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"
