集群高可用部署方案

📄字数 1.4K

👁️阅读量 加载中...

XuguDB 采用基于无共享（Shared-Nothing）的多副本架构，消除单点故障风险，保证系统的持续可用；XuguDB 支持单机房（数据中心部署）、多机房（同城双活部署、同城灾备部署）、城市（两地三中心）级别的高可用和容灾。

一、数据中心部署

数据中心部署核心生产数据库，承接上层应用，确保业务系统的高效运行和数据可靠性。数据采用分布式存算分离架构部署，将数据存储和数据计算分别部署到不同的节点，实现存储与计算资源的解耦，从而避免资源争用，提升整体性能。存储节点专注于数据持久化，支持多副本机制，确保数据冗余；计算节点则负责高效处理查询和事务，两者互不影响，即使某一节点发生故障，也能通过副本快速恢复，保障服务的连续性。

管理节点采用双活冗余设计，两个管理节点同时运行，当其中一个管理节点因故障无法服务时，另一个管理节点可自动无缝接管，确保数据管理、存储和计算的高可用性。此外，Binlog作为数据库操作的关键记录文件，不仅支持数据备份和恢复，还能用于数据复制和主从同步，满足不同场景下的数据一致性需求，用户可根据实际业务需求灵活配置其功能。

数据中心部署场景如图1所示。

图 1 数据中心

二、同城双活部署

建立一个与核心生产数据库完全同构的同城双活中心，两个数据中心采用对称部署，同时运行并承载相同的业务负载。两个数据中心之间通过高速低延迟的网络互联，确保数据实时双向同步，增量数据以毫秒级延迟完成复制，始终保持数据强一致性。这种架构不仅实现了跨中心的业务负载均衡，还能动态分配请求流量，显著提升整体服务能力和资源利用率。双数据中心的设计使得系统响应能力翻倍，能够高效应对高并发场景，同时通过智能路由机制优化用户体验。

当其中一个数据中心因硬件故障、网络中断或其他不可抗力因素无法正常运行时，系统可迅速切换，将业务请求无缝迁移至另一个健康的数据中心。切换过程对上层应用完全无影响，用户无感知，确保业务连续性。待故障数据中心修复并完成数据同步后，可平滑重新接入系统，恢复双活运行状态，继续提供高可靠、高性能的服务支持。

同城双活部署场景如图2所示。

图 2 双活中心

三、同城灾备部署

以核心生产数据库为中心，承接上层应用的全部数据请求，确保业务系统的高效稳定运行。在同城部署灾备中心，采用实时数据同步技术，对核心生产数据库中的数据进行持续备份。核心生产数据库在快速响应应用端请求的同时，通过高性能的数据复制机制（如基于Binlog的增量同步），将增量数据毫秒级实时同步至同城灾备中心，确保两地数据严格一致（RPO=0）。

当核心生产数据库因节点宕机、机房断电或网络中断等故障无法继续提供服务时，系统会立即触发高可用切换机制，自动将业务流量毫秒级切换至同城灾备中心，确保服务不中断。切换过程对上层应用完全透明，业务请求可无缝衔接，实现RTO（恢复时间目标）<30s的极致容灾能力。故障恢复后，系统支持数据反向同步，快速重建核心生产数据库，恢复双中心冗余架构，持续保障业务的高可用性和数据安全性。

同城灾备部署场景如图3所示。

图 3 同城灾备

四、两地三中心部署

在同城灾备中心的基础上，进一步增建异地灾备中心，构建“两地三中心”的高可用容灾架构。由于异地灾备中心与核心生产数据库距离较远，网络延迟较高，因此采用异步复制机制，将增量数据定期同步至异地灾备中心，确保数据最终一致性，同时避免对核心生产数据库的性能造成影响。

当核心生产数据库因硬件故障、网络中断等问题无法运行时，系统可快速切换至同城灾备中心，保障业务连续性和数据实时可用性（RPO≈0，RTO<30s）。然而，若遭遇自然灾害（如地震、洪水）或区域性电力中断等极端情况，导致同城双中心同时不可用，异地灾备中心将基于备份数据启动应急流程，提供关键业务的数据和计算能力，防范大规模灾难风险。

异地灾备中心平时仅存储数据副本，灾备切换时通过自动化工具快速拉起服务，确保业务在可接受的时间内恢复运行。同时，系统支持灾后数据回迁，待主中心恢复后，逐步将业务流量切换回核心生产环境，实现容灾与业务连续性的闭环管理。

两地三中心部署场景如图4所示。

图 4 两地三中心