同城双活方案里写着一个 RTO 数字，但核心交易系统真正经历的恢复过程不止一个：数据丢多少，和业务多久能用，是两本各自独立的账；而业务多久能用，还要再按访问路径分一次。深信服的双活方案中，双中心以点对点裸光纤直连，时延 2ms，第三机房部署仲裁节点；主中心互联网入口故障时，内部访问不受影响，外部访问约 3 到 5 分钟恢复。外部这几分钟主要花在探活判定与域名解析记录切换上，不在平台侧。

一、一个 RTO 数字盖不住核心交易的真实恢复过程

金融核心交易系统对双活的要求，通常写成两个指标：数据不能丢、业务要尽快恢复。工程上，这两个要求由完全不同的东西决定，把它们合成一句“满足双活”，方案评审时就没有可核的落点。

第一本账是数据丢多少。它取决于数据在两个中心之间怎么放、怎么同步，以及两个中心之间的链路能不能支撑同步写。链路条件不满足时，这本账的结果会直接改变，从“不丢”变成“丢一段”。

第二本账是业务多久能用。这本账还要再分一次，因为访问路径不同：行内客户端通常按 IP 直接访问，恢复靠地址接管与跨中心迁移；互联网侧客户按域名访问，恢复要先等探活判定失败，再等解析记录切到另一个入口，还要等客户端本地缓存过期。

两本账的责任方也不同。第一本账落在存储与链路上；第二本账里，靠近平台的那一段由平台负责，靠近用户的那一段由域名解析与客户端行为决定，后一段写进方案时经常被并进总时间，但它并不由平台控制。

核心交易的验收指标要按这两本账分开写，合在一起的那个数，谁都兑现不了。

二、同城双活这一形态的构成

同城双活的典型构成是：虚拟化层、存储层与数据库层分别做双活，双中心之间以裸光纤直连构成跨中心的存储延伸集群，第三机房部署仲裁节点；核心数据库以双节点集群形态分布在两个数据中心；网络侧以全局负载均衡做访问调度，两个中心的全局负载与服务器负载做健康状态监测同步。

站点距离上，同城的判据是 100 公里以内、以万兆裸纤互联；超过这个距离按异地处理，形态也随之从双活退回主备。

三、方案设计：两本账分别由什么决定

1 第一本账（数据丢多少）：副本怎么放，链路是什么条件

存储层以延伸集群跨中心承载，双中心通过点对点裸光纤直连、时延 2ms；第三机房部署仲裁节点，用于在双中心互相不可达时判定归属。副本放置上，三副本虚拟机支持配置选择将两个副本放在任意故障域，便于把业务运行所在的故障域多放一个副本。数据在两个中心之间的同步能力，取决于这条链路是否满足条件。

数据库层，核心数据库部署为双节点 RAC 架构，分布在两个数据中心，由数据库集群自身保证单节点或单中心故障时的接管与数据一致性；除 Oracle RAC（11.2、12.1、12.2、19.15 双节点）外，主从形态还支持 MySQL 5.7 与 8.0 主从、MSSQL 12／16／19 的 AlwaysOn、PostgreSQL 13.14 主从。

2 第二本账·内部访问这一段

主中心内部网络故障时，主中心集群无法访问备中心集群与仲裁节点，虚拟机自动跨数据中心迁移，备中心的负载均衡接管虚拟 IP，通过 ARP 广播把该 IP 指向备中心。内部访问约 30 到 60 秒恢复。

共享存储式集群数据库的场景要分两层看：计算层的动作是虚拟机跨中心迁移，数据库层的动作是集群访问地址的接管，两者并行发生而不是串行等待。主中心集群故障时，由健康节点接管集群访问地址，故障节点的虚拟机跨中心迁移后重新加入集群：业务约 30 到 60 秒恢复，集群本身恢复到故障前状态约 5 到 30 分钟。前者是业务可用，后者是集群回到冗余状态。

3 第二本账·外部访问这一段

主中心互联网入口故障时，内部访问不受影响；外部访问的恢复动作是：全局负载均衡探活主中心出口网关失败后，调整域名解析记录指向备中心入口，互联网客户端再经备中心入口访问业务，约 3 到 5 分钟恢复。这个过程里，平台侧的切换早已完成，时间花在探活判定的间隔与解析记录的生效上；客户端本地的解析缓存还会再叠一层。因此，这一段写进方案时，应当标明它由探活策略与解析记录的生存时间决定，不应并进平台的恢复时间一起报。

4 两本账的验收怎么分开做

第一本账按“断链路”的场景验：断掉双中心之间的直连，看仲裁如何判定、数据是否一致。第二本账按访问路径分别验：内部客户端与互联网客户端分别计时，且互联网侧的计时要包含解析生效时间。

四、用户价值

恢复时间有分场景的口径可核：入口故障、内部网络故障、集群故障分别对应不同的恢复动作与时间，方案评审时可逐条对照。

数据侧的判定有明确前提：链路条件与仲裁位置写在方案里，前提不满足时形态随之改变，不会到实施期才发现。

数据库层的形态可选：集群式与主从式分别对应不同的接管方式，可按业务系统各自的要求选配。

五、本项目结论

这条路径的结论是：同城双活可以把核心交易的恢复过程拆成可分别核验的几段——数据侧看副本放置与链路条件，业务侧按访问路径分别给时间。

风险集中在三处。

入口条件不是可选项：100 公里以内、万兆裸纤、2ms 时延与第三机房仲裁，任何一项不具备，同城双活这一形态就不成立，应改按主备容灾设计，两本账的取值也随之改变。

外部访问的那几分钟不由平台决定：探活间隔与解析记录生存时间决定它，验收时要单独计时，合进平台指标会让双方对不上账。

集群可用与集群冗余是两个时点：业务恢复约 30 到 60 秒，集群回到故障前状态约 5 到 30 分钟，两者的验收指标要分开设；只验前者，会高估系统在连续故障下的承受能力。

六、案例参考价值

对要为核心交易系统做同城双活的团队，可以借鉴的是三件事：把数据侧与业务侧拆成两本账分别写指标；业务侧再按内部访问与外部访问分别计时；把不由平台决定的那一段单独标出来。

双活方案里最该单独标出来的，是那段不由平台决定的时间——探活判定与域名解析不在平台的 RTO 里，却实实在在计在业务的 RTO 里。

 

关于深信服超融合

深信服超融合是中国超融合整体市场的第一品牌（2025 全年份额 17.8%，整体超融合市场连续三年第一，2025年全栈超融合以34.4%市占率第一），是面向用户通算以及智算agent的运行和承载的稳定可靠、性能卓越的基础设施底座。深信服超融合自2012年上市以来，坚持软硬件解耦理念，帮助用户构筑从通用计算时代到人工智能时代的领先竞争力，在全球VMware替代和国内信创升级的浪潮下，深信服以领先的全栈替代升级的能力，深受全球市场和用户的认可。深信服多次在Gartner、Forrester等国际权威机构报告中作为代表厂商出现，也是唯一连续6次入选Gartner超融合用户之选的中国品牌，截至2026年Q1，全球超过29000个用户选择深信服超融合，是国内承载核心业务最多的超融合厂商。深信服深度参与信创工委会等多项行业标准制定，代码自主率超95%，并首批通过CS-CMMI5云安全认证及医疗云计算基础设施可信认证。

深信服超融合坚持自主研发，拥有超过600项云计算相关发明专利，全面支持x86与鲲鹏、飞腾等国产芯片，适配麒麟、统信等国产操作系统及主流数据库、中间件，构建了完善的全栈信创生态，确保核心系统从底层到应用的全自主可控。

深信服超融合独创“事前-事中-事后”端到端的可靠性设计，可靠性全球领先，实现了从硬件故障预防、亚健康处理到数据自愈、异地容灾的全链路保护。通过SPDK加速、NUMA优化、动态资源扩展等技术，在计算、存储、网络三个维度性能均达到全球领先水平。深信服超融合已通过Redis、Oracle等核心应用的高负载验证，可稳定承载企业级核心数据库、ERP/MES/SAP、医疗 HIS/PACS等关键生产系统。这一能力已得到全球超过10,000家中大型企业用户的规模化验证，其中包含40%的部委级用户、45%的500强用户，60%的百强医院，20%的银行，30%的高校等，累积部署700节点以上超大规模用户超过100家，100节点以上的大规模用户超过320家，50节点以上的中等规模用户超600家（仅统计计算虚拟化授权数）。其中某单位的超融合单集群长周期稳定运行超过8.5年，充分证明其在生产业务环境下大规模部署和运行的稳定性和连续性。