数据库同城双活方案探讨

2025-04-28 10:00:03 栏目：宝塔面板 2 阅读

前一段时间有应用要进行双活改造，聊到数据库的对称双活架构，看了下同业在应用双活尤其是数据库双活设计的时候，没有一个最佳的实施方案。本文简单介绍下应用层和数据库层的同城双活设计方案，对比了不同方案的优缺点，以在实际选择时候作为参考。

1、应用层同城双活架构

同城双活架构是指在同一个城市或地理区域内，构建两个或多个数据中心，也就是常说的Region的概念，这些在同一个Region内的数据中心同时对外提供服务，实现资源的充分利用和业务流量的负载均衡。同城双活架构有以下特性：

高可用性：由于有两个或多个数据中心同时运行，当一个数据中心出现故障或维护时，另一个数据中心可以迅速接管服务，确保业务的连续性和稳定性。这种架构显著提高了系统的容错能力和可用性。
负载均衡：同城双活架构可以实现流量的动态分配和负载均衡，根据各个数据中心的负载情况，智能地将用户请求分发到不同的数据中心，从而优化资源利用，提高系统的整体性能和响应速度。
容灾备份：同城双活架构相互之间具备容灾备份的功能。当一个数据中心出现故障时，另一个数据中心可以迅速接管业务，确保数据的完整性和业务的不间断运行。

在双活架构的实现上，由于应用多数是无状态的，通过DNS和负载均衡在接入层实现流量动态分发，应用层按照竖井式架构部署，如下图所示。生产站点和同城站点在部署资源上完全对等，并具备同时接管承载两个站点流量的能力，当生产站点或者同城站点的应用出现异常时，将流量快速切换到一个站点，提升了业务的可用性。

图片

上述高可用架构中，虽然在应用层实现了同城双活，但是同城中心的应用是要写回生产的数据库主节点，依赖数据库层的数据同步保证同城站点的数据一致性。当生产站点数据库出现异常或者站点级别异常时，通过自动或者手动的方式切换到同城站点，但是这个切换过程其实是有损的，故障期间业务会出现全局性的不可用。那么想进一步提高业务的可用性，降低站点级故障的业务影响，实现数据库层的同城双活架构，将如何实现？

2、数据库层同城双活实现

2.1 常用的数据复制技术

在探讨数据库层的双活架构实现之前，先来看下在同城架构中常用的数据复制技术有哪些。数据复制是指将一组数据从一个数据源拷贝到一个或多个数据源的技术，在同城双活架构中有明确的RPO和RTO要求，因此数据复制的性能和时效性是技术选择的重要考量。常用的数据复制技术包括几种：

图片

基于应用的数据复制：通过应用程序与主备中心的数据库进行同步或异步的写操作，以保证主备中心数据的一致性。这种方式技术实现复杂，与应用软件业务逻辑直接关联，实现和维护难度较高，并且会提高系统的风险与数据丢失的风险，在实际场景中很少使用到。
基于数据库的数据复制：利用数据库自身的数据库日志基于逻辑复制或物理复制的方式，将数据同步或异步的方式复制到备节点，实现主备数据的一致性。基于数据库层的复制技术依赖于各数据库产品自身的能力，能够实现记录级和事务级的数据一致性，技术方案成熟稳定并且网络占用带宽小，是主流的数据复制方案。
基于主机的数据复制：由安装在主机上的卷管理软件或是文件系统来实现，在实际的应用场景中，以基于卷管理软件的数据复制技术居多，这种方式通常与主机平台相关，对软件的要求较高。通过主机数据管理软件实现数据的远程复制，当主数据中心的数据遭到破坏时，可以随时从备份中心恢复应用或从备份中心恢复数据。一般用于备份容灾环境的数据同步或恢复，实际应用案例也不多。
基于存储设备的数据复制：利用存储阵列自身的盘阵对盘阵的数据块复制技术实现对生产数据的远程拷贝，分为同步方式和异步方式，同步方式可以保证后备磁盘阵列中的数据与生产系统数据同步，实现RPO为零。该复制技术依赖于存储设备的功能，要求是同构的存储系统，并且对带宽的要求较高。
基于存储虚拟化的数据复制：与基于存储设备的复制技术类似，不同之处是由存储虚拟化控制器在存储网络层面实现，不要求底层存储阵列同构。

2.2 数据库同城双写的难点

在数据库主备节点的高可用部署架构中，如果要实现数据库双写，涉及到将数据同时写入多个数据库实例，在技术实现上存在诸多难点。

1）数据一致性问题

在主备库同步过程中，由于网络延迟、硬件故障等可能存在主备数据不一致的情况，当主库成功写入数据但是从库没有及时同步，从库访问到这部分数据就存在一致性偏差。
当两个数据库实例同时写入相同的数据时，则会发生数据冲突，类似MySQL的双主架构中就缺少这种冲突检测机制。
当一个主节点更新数据后，另一个主节点可能还没有同步到最新的数据，读取时可能会出现不一致的结果。

2）性能问题

在同步复制中，主库需要等待从库的数据确认写入后才能成功返回，需要保证强一致性，增加了写操作的延迟；
双写情况下需要维护多个数据库实例的同步状态，增加了系统的资源开销。
为解决数据不一致问题或者主键冲突时，引入分布式锁、乐观锁和唯一键约束等机制，会带来额外的性能开销

2.3 类RAC集群架构

RAC（Real Application Clusters）架构允许在多个物理服务器节点上部署相同的数据库实例，这些实例共享相同的数据库文件和存储资源，底层使用分布式锁管理器（DLM）等机制来控制多个节点对共享资源的并发访问，确保数据的一致性和完整性，避免数据冲突和丢失。与传统的主备模式不同，RAC是一种并行模式，每个节点都可以对数据库进行读写操作，当一个实例出现问题时，请求会自动转发到另外一个实例。

图片

以达梦共享集群架构为例，在同一个站点内实现RAC共享存储架构，实现存算分离，计算实例有多个可以并发读写，数据文件、控制文件在集群系统中只有一份，这些文件保存在共享存储上。另外在共享存储上使用DMASM 文件系统管理共享存储设备，并通过配置DMASM 镜像提供多副本技术。当出现磁盘损坏或数据丢失时，系统无需人工干预即可利用其他镜像副本继续提供数据库服务，同时又可以自动或手动通过使用其他镜像副本进行数据恢复。

RAC架构实现了同一站点级别同时写操作，那么能否延伸到同城双中心的RAC部署实现呢？

图片

该技术方案在实现上尚存在诸多技术难点：

首先存储层借助存储虚拟化产品实现双数据中心组成的存储集群，依赖双中心网络的二层打通，成本上需要网络波分设备、存储交换机等；
仲裁的一致性问题，数据库RAC集群和存储集群的一致性判断，数据库集群依赖集群管理组件来判断、存储依赖依赖站点之间网络的连通性，如果出现不一致，整个集群会crash；
链路稳定状态不可控：双中心链路的主干网延迟因素和线路稳定性，在读写热点相对突出的业务上会出现数据库读写性能影响比如IO阻塞，同时链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁的频繁发生。

从技术架构实现上来看，基于RAC+共享存储的数据库双活方案，技术实现难度很大，业内也少有成功实施的案例。

2.4 原生分布式数据库实现

原生的分布式数据库具备数据自动分片的功能，以OceanBase数据库为例，它将大表划分为多个较小的分片（Tablet），这些分片自动分布到多个节点上，每个节点处理数据的一部分。另外每个分片有多个副本，并分布在不同的节点上，副本之间通过Paxos一致性算法实现数据一致性。当生产和同城部署在同一个数据库集群中，通过配置分片的策略，在双中心都会有主节点分布，也就是实现了生产和同城同时写的操作。

图片

基于原生分布式数据库的实现生产和同城双中心双活架构，当生产或同城中心故障时，自动将主副本切换到其它节点，保证了可用性。不过这种架构下不可避免的存在跨中心的写业务操作，存在以下问题：

当跨中心的读写业务大时，会对跨中心的网络带宽带来压力，进行会影响交易性能
跨中心网络时延和链路抖动的影响，影响分布式事务的性能以及分布式组件之间的链路检测的稳定性和有效性。

2.5 单元化部署架构

单元化部署是将应用服务和数据按照某种规则进行分片，使得某个单元提供面向部分数据分片的完整服务能力。每个单元都是一个独立的实体，包含完整的服务和数据副本，可以独立运行和扩展。单元化可以实现系统的水平扩展，提高系统整体处理能力，提高系统的容错性和可用性。单元化架构要求系统具备数据分区能力，数据分区承载了各个单元的业务流量比例，数据分区就是将全局数据按照某个维度水平划分开来，每个分区的数据互不重叠、每个节点有自己的应用系统和数据库。比如业务服务单元包含多个客户的业务数据以及为此类客户提供服务支持的应用实例。

图片

单元化与分布式数据库能够有机结合，不同的单元存储在不同的数据库节点，每个数据库节点根据业务大小还可以进行数据分片分为不同的数据库实例，单元和单元之间实现物理上的隔离和数据上的逻辑隔离。单元化架构在实现过程中有以下难点：

单元化的拆分：设计合理的单元拆分方式，比如按照地域、客户号进行单元划分，单元和数据库的分片规则也需要确认；
单元扩展：随着业务规模的增长，需要扩展单元，涉及到分布式数据库的横向扩展；
单元化架构高可用：单个单元故障不会造成全局影响提高系统整体可用性，结合分布式数据库的高可用特性，设置合理的副本数，保证RPO和RTO的要求，甚至实现数据库层站点级别的双活架构；
跨单元数据同步汇总：对于跨单元数据的汇总，支持部分批量加工的综合分析，需要从不同单元进行数据抽取汇总和加工。

基于单元化的部署架构实现数据库层的同城双活，也是业务比较普遍的做法，在架构实现上将部分单元的数据库主节点部署在同城单元，在网关层进行单元的路由分发，实现哪些业务访问生产单元、哪些业务访问同城单元。

2.6 总结

本文讨论了同城双活的实现架构以及如何实现数据库层同城双活，对于对同一份数据同时写操作在集群的机制上本身比较复杂，虽然RAC架构能够实现本站点的部署，但是在同城架构下RAC集群要依赖底层的数据库网络和存储网络，架构中的不稳定因素太多，而且RAC集群的性能相比单集群的架构反而会有下降。原生的分布式数据库架构也支持生产同城双写，但是存在跨中心的写操作以及集群间跨站点的网络影响，对业务的性能会有影响。而基于单元化的数据库双活方案，结合应用的单元化设计，自上而下实现单元的物理和逻辑上的隔离性，并且生产和同城同时承载数据库写业务，在一定程度上实现数据库层的双活部署，也是业务在双活改造过程中推荐的部署方案。

参考资料：