在第十四届中国数据库技术大会（DTCC2023）上，优炫软件李勇围绕核心业务系统对数据库的严苛要求，深入剖析了共享存储多读多写集群技术（类 Oracle RAC）的必要性与实现路径。本文基于现场演讲整理，系统阐述了优炫为什么选择这一技术路线、UXDB SRAC 的关键技术创新、整体架构以及典型应用场景，为国产数据库在高端替代领域的探索提供了宝贵参考。
一、核心业务需求：为什么必须攻克 RAC 技术？
没有一种数据库能覆盖所有业务需求。在金融、电信、能源等关键行业，核心业务系统对数据库的要求是多维度的：既要考虑业务数据特点、增长趋势、并发访问规模，也要满足响应速度、业务连续性、数据一致性以及成本约束。
以金融行业为例，当一笔交易被系统判定为「有风险」时，后台需要瞬间调取用户在全国各地的支付习惯数据进行复杂关联分析——这种高频、复杂的事务处理，正是核心业务对数据库能力的真实写照。
核心业务的「铁三角」要求：
- 最高级别可用性：业务不能停，任何节点故障对应用层透明。
- 实时数据一致性：银行账户、交易记录必须强一致，不能有毫秒级延迟。
- 复杂事务处理能力：支持高并发、高吞吐的在线交易。
据《金融业数据库安全发展报告 2022》统计，集中式数据库在金融业总体占比高达 89%，其中银行核心系统占比超过 90%。究其原因，集中式架构在强一致性、高可用性方面具有不可替代的优势。
而这一领域的标杆，正是 Oracle Real Application Clusters（RAC）。自 2001 年推出至今，Oracle RAC 历经 20 余年发展，从基础集群到高可用、灾备、容器化，始终占据全球核心系统制高点。2022 年，Oracle 全球市场超 200 亿美元，仅 RAC 在中国市场就达 3 亿美元，四大行、九大国有企业的核心应用仍以 RAC 为绝对主流。
然而，地缘政治与技术自主的双重压力，使国产替代成为必然。但为何 RAC 替代进展相对缓慢？
一方面，RAC 技术门槛极高，被称为「数据库技术的天花板」；另一方面，RAC 的目标市场并非海量并发场景，而是追求极致可用性和一致性的高价值核心系统（如银行账户、实时计费），其 TPS 需求通常在 2000～8000 左右，性价比优势明显。市场规模有限、技术难度大，导致国产厂商投入意愿不足。
但优炫软件选择迎难而上。
二、UXDB 技术路线选择：为什么是类 RAC？
当前，国产数据库对 Oracle RAC 的替代主要有三条技术路径：
1. 中间件模拟方式：通过中间件屏蔽后端数据库实例连接与切换。实现简单，但本质仍是读写分离，无法满足极致高可用与强一致性需求。
2. 分布式数据库方式：依托互联网场景，数据分片、多副本、最终一致性。适用于海量数据、高并发、天然分布式的业务（如电商、社交），但在强一致、高可用核心场景中存在先天局限。
3. 类 RAC 方式：采用共享存储，所有节点操作同一份数据，不分区、不冗余，通过集群实现强一致性与绝对可用性。这是最接近 Oracle RAC 的替代方案，应用无感知、迁移成本最低。
优炫坚定选择了第三条路——自主研发 UXDB SRAC（Shared Storage Cluster）共享存储集群数据库系统。这不仅是对国家「去 IOE」战略的响应，更是填补国产数据库在 RAC 级高可用领域的空白。
目前，UXDB SRAC 理论规模无上限，实用集群可达 8 节点，在同等测试环境下性能与 Oracle 相当，并已与多家合作伙伴完成适配，开始进入关键业务系统。
三、UXDB SRAC 关键技术解析
RAC 集群最核心的特征是全对称架构——任意节点具备对全部数据的读写能力，任何节点故障不影响整体服务。实现这一目标，需要攻克五大关键技术：
1. SRAC 并行内存融合
内存融合的目标是让集群中各节点的数据缓冲区逻辑互通，节点间通过高速内网共享数据块，用网络 IO 换取磁盘 IO，提升性能。
优炫采用流式无状态模型，内存融合模块不处理冲突、不维护锁队列、不等待确认，发出调度指令后即假定成功，后续请求基于此状态推进。若网络通讯异常，则快速报警、解耦修复，必要时直接剔除故障节点，保证集群稳定。
2. 分散 PIN 并行清理与脏页缓存
高并发 Update 会产生大量老旧版本数据，RAC 环境下问题更突出。优炫重新设计 MVCC 清理机制，采用并行分散模型全局维护，有效控制膨胀。
同时，内存融合脏页缓存技术记录数据块修改历史，为节点故障恢复提供依据，使内存融合与并发控制实现解耦。
3. SRAC 实时事务并发控制
为实现全对称下的实时一致性，优炫在每个节点保留全局事务状态信息。事务提交时，通过广播方式同步状态，使各节点可本地获知全局事务进展，确保实时一致的并发控制。
4. USM 共享存储
多节点高频访问共享存储，必须保证元数据严格一致。优炫通过重新设计元数据结构，减少同步信息量，并借助内存融合与事务并发控制，实现高效元数据同步。
5. SRAC 不停机恢复
节点故障时，如何保证集群事务不中断？
- 双层 WAL 技术：解决单个节点 WAL 日志空洞问题，确保全局日志流连续。
- 全局日志序号（sno）：为集群内事务提供全局排序能力，保障恢复顺序正确。
- 并行多路按需恢复：优先修复被请求的故障数据，其他数据正常访问，用户无感知。
四、UXDB SRAC 整体技术架构
UXDB SRAC 采用标准类 RAC 架构：存储网络与节点间数据块网络分离，各节点通过高速内网进行内存融合与事务同步，共享存储统一持久化数据。
这种架构带来的优势：
- 节点故障无感切换：任意节点停机，业务自动转移。
- 滚动维护：支持有计划地停单节点进行系统维护，不影响整体服务。
- 异构节点支持：降低国产替代的硬件适配难度。
- 自主可控：全栈自研，为后续性能优化、新硬件适配打开空间。
此外，基于 SRAC 集群可构建灾备系统，多个集群通过流复制实现数据同步，满足关键业务容灾需求。
五、UXDB SRAC 典型使用场景
UXDB SRAC 主要适用于以下场景：
- 业务连续性要求极致：如银行账户系统、实时交易系统、高速公路计费系统。
- 高并发、高可用需求：如实时仿真、重卡调度等工业控制系统。
- 一定可扩展性要求：集群内节点数可根据业务增长动态调整，兼顾性能与弹性。
目前，优炫已与多家银行、交通、制造企业开展适配，UXDB SRAC 正在核心业务系统中逐步落地。
结语
Oracle RAC 是数据库技术的「明珠」，也是国产替代最难啃的骨头。优炫软件以十年磨一剑的决心，攻克共享存储多读多写集群核心技术，推出 UXDB SRAC，为关键行业核心系统提供了真正可用的国产方案。这条路虽然艰难，但唯有攀登，方能见峰顶风景。