大家好，我是JiekeXu,江湖人称“强哥”，青学会MOP技术社区主席，荣获Oracle ACE Pro称号，崖山最具价值专家YVP，IvorySQL开源社区专家顾问委员会成员，墨天轮MVP，墨天轮年度“墨力之星”，拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及金仓KCA、KCP、KCM、KCSM证书，PCA、PCTA、OBCA、OGCA等众多国产数据库认证证书,欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！

国产数据库浪潮下的 RAC 坚守：为何中国仍需这一经典架构？

前 言

2025 年国家信息安全测评中心第三批安全可靠测评结果发布，国产数据库头部格局逐渐清晰。在分布式架构盛行多年后，一个值得关注的现象是：崖山、达梦、南大通用、华为 openGauss、金仓、易景科技 Halo 等厂商纷纷加入到 RAC（实时应用集群）技术的研发投入。这一看似 “逆趋势” 的选择，实则折射出中国数据库产业从"概念跟风"向"场景务实" 的成熟转变。当分布式架构被视为未来方向时，为何中国市场仍需要 RAC？这一经典架构在当下的技术生态中究竟扮演着怎样的角色？

上图为RAC 架构演变历史,可以看到 9i 就已经有了，去年写参天存储引擎的时候也大概介绍过一些 Oracle RAC 的内部原理，感兴趣的可以去看看，初探华为Cantian(二)——类似于 Oracle RAC 共享存储架构都有啥？，今天这里就不在介绍了 。

一、需求锚点：中国市场为何离不开 RAC？

RAC 在国产数据库版图中的持续存在，本质上是由中国关键行业的数字化需求决定的。与互联网行业追求"无限扩展"不同，金融、能源、政务等核心领域更看重"绝对可靠"——这种需求差异使得 RAC 成为无法替代的技术选项。辽宁农信的国产化实践极具代表性，其采用某国产数据库的共享集群技术全面替代 Oracle 11G RAC 架构，在运维一体化平台实现了 “并行运行 3 个月无事故” 的稳定表现，验证了国产 RAC 在金融行业中的可行性。https://www.gbase.cn/case/197

这类案例揭示了 RAC 在中国市场的三大核心价值：

业务连续性保障构成首要需求。金融交易系统、电力调度平台等关键场景要求"零停机"，而 RAC 通过多节点冗余设计，能在硬件故障时实现秒级故障切换。Oracle RAC 的实践表明，其内置的应用连接故障转移功能可自动将连接从故障节点转移到正常节点，确保证券交易、电网调度等业务不中断。这种高可用能力正是分布式架构在复杂事务场景下尚未完全突破的短板 —— 尽管分布式通过分片提升扩展性，但跨节点事务一致性仍可能导致故障恢复时的数据风险。

遗留系统迁移成本是另一重现实考量。中国金融机构仍有大量基于 Oracle RAC 开发的核心应用，这些系统经过十年以上的业务验证，重构成本极高。国产 RAC 通过兼容 Oracle 语法和存储过程，大幅降低迁移难度。辽宁农信在替换过程中实现了"数据库、表、存储过程、触发器等全部数据对象的平滑迁移"，这种兼容性是分布式架构难以提供的。对于预算有限、风险承受能力低的区域银行和国企而言，基于 RAC 的国产化替换是更稳妥的路径。

监管合规要求进一步强化了 RAC 的必要性。《网络安全法》《数据安全法》要求关键信息基础设施使用安全可控的技术产品，而 RAC 的集中式架构更易于实现数据全生命周期的安全管控。相比分布式架构的多节点数据分布，RAC 的共享存储模式在权限审计、数据加密等方面具有天然优势，更符合金融监管对"数据可追溯、风险可控制"的要求。某国有银行科技部负责人曾表示：“在没有完全验证分布式架构安全性之前，RAC 仍是核心系统的首选。”

二、场景重构：RAC 与分布式的生态分工

前几年分布式数据库的热潮，很大程度上源于互联网行业"流量爆发式增长"的需求牵引。但随着数字化深入传统行业，技术选型开始回归场景本质 ——RAC 与分布式并非替代关系，而是形成了互补的生态分工。openGauss 社区 2025 年发布的 oGRAC（全球首个开源多写多读 RAC 架构），正是这种分工的典型体现，其将 RAC 定位为 “关键事务场景的稳定性保障者”。

RAC 的核心应用场景集中在三类需求：一是 “固定并发 + 高可靠” 的金融核心系统，如银行的柜台交易、证券的清算结算。这类场景并发量可控（通常在每秒数千笔交易），但对数据一致性和故障恢复要求极高。Oracle RAC 通过缓存融合（Cache Fusion）技术，使各节点能共享缓存数据，避免分布式架构中的跨节点数据传输延迟，交易响应时间比分布式架构缩短 30% 以上。二是"有限扩展 + 复杂查询"的企业 ERP 系统，如大型制造企业的生产管理系统。这类系统需要处理多表关联的复杂 SQL，RAC 的并行查询功能可将查询任务分解到多个节点执行，效率是单机数据库的 5-10 倍。三是 “遗留系统迁移"场景，如政府部门的核心业务系统，这些系统基于 Oracle RAC 开发，迁移到国产 RAC 可实现"零代码改造”，大幅降低迁移风险。

分布式架构的优势领域则在"弹性扩展 + 海量数据"场景，如互联网电商的订单系统、社交平台的用户行为分析。这类场景的特点是数据量巨大（PB 级）、并发波动大（如电商大促），需要通过分片实现无限扩展。但分布式架构在复杂事务处理上仍存短板，两阶段提交（2PC）机制会导致事务延迟，难以满足金融核心系统的实时性要求。分布式架构的选择也并非只看数据量，而是取决于业务对扩展能力的需求及业务场景。一般而言，当并发量可控、数据量在 100TB 以内时，RAC 的性价比和稳定性更具优势。

场景边界的动态平衡构成当前市场的主要特征。随着技术演进，RAC 与分布式开始出现融合趋势：部分国产数据库在 RAC 架构基础上增加了 "共享存储 + 局部分片"的混合模式，既保留 RAC 的高可用优势，又具备一定的扩展能力。openGauss 的 oGRAC 就支持 “多写多读”，突破了传统 RAC 的扩展限制，同时通过共享存储确保数据一致性。这种融合趋势表明，未来数据库市场将呈现 “场景驱动” 的多元化格局，而非单一架构的一统天下。(https://discuss.opengauss.org/t/topic/81)

三、技术攻坚：RAC 的壁垒与 Oracle 的破局之道

RAC 被业内称为"数据库领域的珠穆朗玛峰"，其技术壁垒体现在分布式一致性、性能优化、运维复杂性三个维度。Oracle 通过近 25 年的技术迭代，构建了难以逾越的技术护城河，其经验对国产 RAC 的发展具有重要借鉴意义。

分布式一致性的突破是 RAC 的核心难点。多个节点共享存储时，如何避免数据冲突、确保事务一致性，是 RAC 面临的首要挑战。Oracle 通过两项关键技术解决这一问题：一是缓存融合（Cache Fusion）技术，允许节点间直接传输缓存数据块，避免重复读取共享存储，将数据访问延迟降低 80% 以上；二是全局资源目录（GRD），统一管理所有节点的资源请求，确保数据修改的串行化执行。这两项技术的结合，使 Oracle RAC 能支持并发事务的一致性处理，而国产数据库在这一领域仍处于追赶阶段 ——openGauss 的 oGRAC 虽然实现了多写多读，但在高并发场景下的稳定性仍需时间验证。

性能优化的技术深度决定 RAC 的实用价值。共享存储可能成为性能瓶颈，Oracle 通过 ASM（自动存储管理）技术解决这一问题：ASM 将存储设备划分为磁盘组，自动实现数据的条带化和镜像，IOPS（每秒输入输出操作）比传统存储管理提升很多性能。此外，Oracle RAC 支持事务级别的并行执行，可将复杂查询分解到多个节点的 CPU 核心执行，大幅提升处理效率。相比之下，部分国产 RAC 仍依赖第三方存储解决方案，在 IO 优化和并行处理上存在差距，导致在高负载场景下性能不如单机数据库。

运维复杂性的降低是 RAC 普及的关键。Oracle 通过自动化工具简化 RAC 管理：一是 CRS 集群件，自动监控节点和服务状态，实现故障的自动检测和恢复；二是联机补丁技术，支持在不中断业务的情况下更新数据库软件，解决了传统集群"升级必停机"的痛点。这些工具使 RAC 的运维复杂度大幅降低，普通 DBA 经过培训即可胜任管理工作。而国产 RAC 在自动化运维方面仍显不足，部分产品仍需手动配置节点资源，增加了运维成本和出错风险。

Oracle 让客户接受 RAC 的过程，本质上是"技术验证 + 生态构建 + 服务保障"的三位一体策略。在技术验证层面，Oracle 通过金融、电信等关键行业的标杆案例（如九七工程拿下中国电信行业市场）证明 RAC 的可靠性；在生态构建层面，与 IBM 等厂商合作，确保主流应用对 RAC 的兼容性；在服务保障层面，提供 7×24 小时的全球技术支持，消除客户的后顾之忧。这种全方位的生态建设，使 RAC 从一项技术创新转变为行业标准，这正是国产 RAC 需要学习的核心经验。

四、生态共建：国产 RAC 的发展路径与存储厂商的角色

国产 RAC 要实现从"可用"到"好用"的跨越，需要厂商在技术研发、生态建设、服务体系三个维度持续投入，而存储厂商的深度参与将成为关键助力。崖山、openGauss、南大通用等厂商的实践表明，国产 RAC 已初步具备替代 Oracle 的技术基础，但要在市场中站稳脚跟，还需突破生态瓶颈。

技术打磨的优先级应聚焦三个方向：一是核心算法优化，重点突破缓存融合、全局锁管理等关键技术，提升高并发场景下的稳定性 openGauss 的 oGRAC 在这方面做出了有益尝试，但还需要在实际场景中验证；二是存储适配能力，开发类似 Oracle ASM 的专用存储管理工具，实现与国产存储设备的深度优化。华为等存储厂商已推出针对 RAC 的优化方案，使得 IO 延迟降低很多；三是可视化自动化运维工具，开发智能监控、自动故障转移、联机补丁等功能，降低运维门槛。

生态建设的关键在于兼容性和案例积累。一方面，需加强与应用厂商的合作，确保 ERP、CRM 等主流应用对 RAC 的支持。Oracle RAC 的成功很大程度上得益于与 SAP 的深度集成，国产厂商可借鉴这一模式，与金蝶、用友等本土应用厂商共建适配标准；另一方面，需打造行业标杆案例，通过金融、能源等关键领域的成功实践建立市场信任。辽宁农信的案例已证明国产 RAC 在中小银行系统的可行性，厂商应在此基础上扩大应用范围，形成可复制的解决方案。openGauss 社区的做法值得参考，其通过"社区 + 商业发行版"的模式，吸引了国产数据库厂商基于其构建 RAC 产品，形成了生态合力。

存储厂商的助力将加速 RAC 的成熟。存储是 RAC 的性能基石，存储厂商可从三个层面提供支持：一是硬件优化，开发低延迟、高 IOPS 的共享存储设备，如基于 NVMe-oF 协议的全闪存阵列，可将存储响应时间降至微秒级；二是软件协同，与数据库厂商联合开发存储管理接口，实现数据库与存储的智能联动。例如，华为存储的 “智能 IO 调度” 功能可识别 RAC 的事务特征，优先处理核心业务的 IO 请求；三是解决方案整合，提供"数据库 + 存储 + 备份"的一体化方案，降低客户的部署复杂度。Oracle 与 EMC 的合作模式表明，存储与数据库的深度协同可大幅提升 RAC 的整体性能和可靠性。

资源投入的策略需要兼顾短期效益与长期布局。对国产厂商而言，短期内应集中资源突破金融、政务等重点行业，通过差异化场景建立市场优势；长期则需加大基础研究投入，在共识算法、并行处理等核心技术领域形成自主知识产权。崖山数据库重点投入 RAC 的研发，这种长期主义的战略布局，正是国产数据库突破技术壁垒的关键。同时，厂商应加强人才培养，建立"数据库内核 + 集群技术 + 存储优化" 的复合型团队，为 RAC 的持续迭代提供人才保障。

五、结语：多元架构下的 RAC 价值重估

在分布式架构大行其道的今天，RAC 的持续存在并非技术的倒退，而是市场成熟的理性选择。中国数据库产业的发展，需要避免"非此即彼"的架构对立，而是根据业务场景选择最合适的技术方案。RAC 以其高可用性、事务一致性和成熟的生态，在金融核心系统、企业 ERP 等关键场景中仍将长期占据重要地位；而分布式架构则在互联网海量数据场景中发挥优势，二者共同构成了国产数据库的多元生态。

2025 年国测第三批名单的发布，标志着国产数据库进入"技术差异化竞争" 的新阶段。YashanDB 共享集群（YashanDB for Cluster，YAC）的使用，openGauss oGRAC 的开源、南大通用 GBase 8s 的商业化落地等等，表明国产 RAC 已具备与国际厂商竞争的基础，但要实现真正的超越，还需在核心技术、生态建设、服务体系三个维度持续发力，同时加强与存储厂商的协同创新。

未来的数据库市场，将不再是单一架构的胜利，而是场景与技术的精准匹配。RAC 的坚守，不仅是对经典技术的传承，更是对中国关键行业数字化需求的深刻理解。在国产数据库从"跟跑"向"领跑"的跨越中，RAC 将继续扮演重要角色，为中国数字经济的安全发展提供坚实支撑。

六、参考链接

曙光初现
https://mp.weixin.qq.com/s/YoPCGruR-IoP1NA6JiCz6w
浅谈分布式、伪分布式与集中式之选
https://mp.weixin.qq.com/s/1QhecFOECUed3a1yXHmE9g
国产 “数据库 RAC”，能否一战？
https://mp.weixin.qq.com/s/QhLKsYaf_tBP9trg9mra5g
为什么有些用户还要RAC架构
https://mp.weixin.qq.com/s/_jz1uwJDY1UV4jQxQwd_Dw
未来是否需要RAC架构
https://mp.weixin.qq.com/s/Gkj178bEWBB5pRBkZNkYBg
Oracle RAC体系结构介绍（ 详细版）
https://www.modb.pro/db/197233

欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————