关于国产 RAC 和分布式研讨

本次研讨核心目标是围绕崖山 DB、达梦 DB、GBASE三款国产数据库，以及数据库内核开发吕工程师的分享，深入了解共享集群 RAC 的开发技术。但实际效果未达预期，参会者多围绕 “共享集群与分布式应用场景” 泛泛而谈，缺乏深度技术拆解。

参会观众以 ORACLE ACE 为主，包括垃圾首席、狗屁总监等资深DB媒体角色，但其观点普遍倾向 “共享集群优势显著、分布式存在缺陷”，存在明显认知局限。需明确的是：RAC 已属于日落架构，其并发能力上限固定；而分布式架构才是数据库发展的核心趋势（海鲨架构师观点）。

需纠正一个常见误区：分布式架构的选择并非依赖数据量（如 “1TB 之内用 RAC” 的认知错误），且当前分布式数据库虽存在短板（如两阶段事务提交导致的事务延迟），但仍具备不可替代的未来价值。

一、数据库设计核心要求

数据库设计需满足以下 9 大目标，其中关键要求的具体定义如下：

1. 零丢失

2. 高稳定：指单机环境下，数据库软件可长时间运行，无自发崩溃现象

3. 高可用

4. 高并发：以 TPCC 指标为核心（每秒事务数、QPS、并发线程、并发连接用户），重点衡量数据库支持的用户访问量（即使前后端优化，最终落到 DB 端的 SQL 量不会减少）

5. 高性能：区分查询性能与 UPDATE 性能，需注意 “性能” 与 “并发” 不可混为一谈

6. 高便利：指数据库易用性，包括配套工具丰富度、操作便捷性

7. 高观测：支持多维度跟踪手段，可清晰监控数据库运行状态、了解运行机制

8. 高安全

9. 高节能：该特性在大规模部署场景（如数据中心上万台 DB）中更明显，例如某国产 DB 通过无锁化编程，在无负载时 CPU 消耗可稳定维持在 15%

二、广义与狭义分布式数据库的定义

1. 广义分布式数据库

在外行人（含开发工程师、CTO、普通同事）认知中，只要数据库依赖多台物理 PC 服务器支撑，且单台 / 多台物理机 / 数据库故障会导致业务部分 / 全部受影响，即可认定为分布式数据库。

典型场景包括：

• 读写分离的主备 / 主从架构（属于分布式中的 “克隆模式”）

• ORACLE RAC（存算分离的分布式：“算” 部分分布式部署，“存” 部分共享）

• MYSQL MGR（多主模式为分布式，单主模式非分布式；“算” 部分分布式，“存” 部分为克隆模式，非分片模式）

2. 狭义分布式数据库

即 “分库分表”，核心特征是 **“算” 与 “存” 双维度拆分，且采用分片模式（非克隆模式）。

其核心价值是提升并发能力 **：通过水平扩展 PC 服务器实现弹性扩容，无需像 RAC 那样依赖停机升级内存、CPU。

三、RAC 共享集群与分布式架构的核心差异

四、分布式与共享集群的选型建议

国企用户普遍因 “RAC 稳定性经长期验证” 而偏好该架构，但选型需结合并发量、活跃数据量、业务停机需求综合判断：

1. 优先选择 RAC 的场景

• 对内业务：并发量可控，存在固定业务维修窗口

• 数据量与用户增长有限： 新硬件支撑下，并发和数据量在RAC承接范围内、共享存储压力可覆盖当前IOPS需求，且未来用户量、业务 SQL 功能增长也有限

• 核心优势：短期内稳定性有保障，适合对 “扩展能力” 需求低的场景

2. 建议选择分布式 DB 的场景

• 互联网业务：并发量不可控，无业务停机维护窗口（需 7×24 小时在线）

• 业务增长特性：用户量可能爆发式增长（如新业务快速起量），需支持在线横向扩展

• 核心优势：突破 RAC 扩展瓶颈，可通过增加 PC 服务器实现无感知扩容

五、当前狭义分布式数据库的缺陷与优化思路

1. 现存缺陷

1. 事务性能：相对 RAC 存在明显延迟

2. 分片设计：分片不合理易导致事务需跨多数据节点执行

3. 读写策略：未做针对性读写分离，查询操作会消耗多数据节点的 IO 与 CPU

4. 数据完整性：无完整数据库备份，若所有数据节点故障，部分业务会受影响

2. 优化建议：保留完整数据库在线

核心方案：USER 表同时设计分片表与完整不分片表，完整数据库的价值体现在：

1. 解决分片决策难题：无论采用何种分片算法，均存在 “部分 SQL 需跨节点更新” 的情况，完整数据库可承接这类跨节点事务

2. 优化多节点读操作：需跨多数据节点联合执行的读操作，可直接在完整数据库中读取，降低节点资源消耗

3. 事务与数据同步策略：

• 多数据节点事务：先在完整库执行，再通过分片字段 BINLOG 复制到对应数据节点

• 单数据节点更新事务：通过 BINLOG 反馈并应用到主库

最后狭义分布式数据库架构设计，每个数据节点可以使用RAC共享集群架构来满足高可用需求。当然较为经济的MYSQL MGR也可以！