数据库同城双活方案探讨

发布时间：2025-11-03 16:53:24 来源：技术快报 作者：数据库

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

1、城双应用层同城双活架构

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

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

图片

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

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

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

图片

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

1）数据一致性问题

2）性能问题

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

图片

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

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

图片

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

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

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

图片

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

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

图片

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

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

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

参考资料：

相关文章