关于国产 RAC 和分布式研讨
本次研讨核心目标是围绕崖山 DB、达梦 DB、GBASE三款国产数据库，以及数据库内核开发吕工程师的分享，深入了解共享集群 RAC 的开发技术。但实际效果未达预期，参会者多围绕 “共享集群与分布式应用场景” 泛泛而谈，缺乏深度技术拆解。
参会观众以 ORACLE ACE 为主，包括垃圾首席、狗屁总监等资深DB媒体角色，但其观点普遍倾向 “共享集群优势显著、分布式存在缺陷”，存在明显认知局限。需明确的是：RAC 已属于日落架构，其并发能力上限固定；而分布式架构才是数据库发展的核心趋势（海鲨架构师观点）。
需纠正一个常见误区：分布式架构的选择并非依赖数据量（如 “1TB 之内用 RAC” 的认知错误），且当前分布式数据库虽存在短板（如两阶段事务提交导致的事务延迟），但仍具备不可替代的未来价值。
一、数据库设计核心要求
数据库设计需满足以下 9 大目标，其中关键要求的具体定义如下：
零丢失
高稳定：指单机环境下，数据库软件可长时间运行，无自发崩溃现象
高可用
高并发：以 TPCC 指标为核心（每秒事务数、QPS、并发线程、并发连接用户），重点衡量数据库支持的用户访问量（即使前后端优化，最终落到 DB 端的 SQL 量不会减少）
高性能：区分查询性能与 UPDATE 性能，需注意 “性能” 与 “并发” 不可混为一谈
高便利：指数据库易用性，包括配套工具丰富度、操作便捷性
高观测：支持多维度跟踪手段，可清晰监控数据库运行状态、了解运行机制
高安全
高节能：该特性在大规模部署场景（如数据中心上万台 DB）中更明显，例如某国产 DB 通过无锁化编程，在无负载时 CPU 消耗可稳定维持在 15%
二、广义与狭义分布式数据库的定义
1. 广义分布式数据库
在外行人（含开发工程师、CTO、普通同事）认知中，只要数据库依赖多台物理 PC 服务器支撑，且单台 / 多台物理机 / 数据库故障会导致业务部分 / 全部受影响，即可认定为分布式数据库。
典型场景包括：
读写分离的主备 / 主从架构（属于分布式中的 “克隆模式”）
ORACLE RAC（存算分离的分布式：“算” 部分分布式部署，“存” 部分共享）
MYSQL MGR（多主模式为分布式，单主模式非分布式；“算” 部分分布式，“存” 部分为克隆模式，非分片模式）
2. 狭义分布式数据库
即 “分库分表”，核心特征是 **“算” 与 “存” 双维度拆分，且采用分片模式（非克隆模式）。
其核心价值是提升并发能力 **：通过水平扩展 PC 服务器实现弹性扩容，无需像 RAC 那样依赖停机升级内存、CPU。
三、RAC 共享集群与分布式架构的核心差异
| 对比维度 | RAC 共享集群 | 狭义分布式数据库 |
|---|---|---|
| 核心目标 | 高可用（ORACLE 重点优化方向，最新版本支持事务无影响迁移） | 提升并发能力（通过水平扩展实现） |
| 存储模式 | 共享存储（IOPS 存在上限） | 分片存储（无共享存储瓶颈） |
| 扩容方式 | 需停机升级内存 / CPU（扩展能力有限） | 在线横向扩展 PC 服务器（弹性扩容） |
| 并发能力 | 上限明确（受共享存储 IOPS 限制） | 可随节点扩展无限提升 |
四、分布式与共享集群的选型建议
国企用户普遍因 “RAC 稳定性经长期验证” 而偏好该架构，但选型需结合并发量、活跃数据量、业务停机需求综合判断：
1. 优先选择 RAC 的场景
对内业务：并发量可控，存在固定业务维修窗口
数据量与用户增长有限： 新硬件支撑下，并发和数据量在RAC承接范围内、共享存储压力可覆盖当前IOPS需求，且未来用户量、业务 SQL 功能增长也有限
核心优势：短期内稳定性有保障，适合对 “扩展能力” 需求低的场景
2. 建议选择分布式 DB 的场景
互联网业务：并发量不可控，无业务停机维护窗口（需 7×24 小时在线）
业务增长特性：用户量可能爆发式增长（如新业务快速起量），需支持在线横向扩展
核心优势：突破 RAC 扩展瓶颈，可通过增加 PC 服务器实现无感知扩容
五、当前狭义分布式数据库的缺陷与优化思路
1. 现存缺陷
事务性能：相对 RAC 存在明显延迟
分片设计：分片不合理易导致事务需跨多数据节点执行
读写策略：未做针对性读写分离，查询操作会消耗多数据节点的 IO 与 CPU
数据完整性：无完整数据库备份，若所有数据节点故障，部分业务会受影响
2. 优化建议：保留完整数据库在线
核心方案：USER 表同时设计分片表与完整不分片表，完整数据库的价值体现在：
解决分片决策难题：无论采用何种分片算法，均存在 “部分 SQL 需跨节点更新” 的情况，完整数据库可承接这类跨节点事务
优化多节点读操作：需跨多数据节点联合执行的读操作，可直接在完整数据库中读取，降低节点资源消耗
事务与数据同步策略：
多数据节点事务：先在完整库执行，再通过分片字段 BINLOG 复制到对应数据节点
单数据节点更新事务：通过 BINLOG 反馈并应用到主库
最后狭义分布式数据库架构设计，每个数据节点可以使用RAC共享集群架构来满足高可用需求。当然较为经济的MYSQL MGR也可以！