OLTP 分布式架构实战：全局事务、一致性协议与 HTAP 落地方案

大家好，我是小耶，写功课是为了我踩过的坑，你们别再踩了！

选 OLTP 数据库，最容易犯的错就是两个极端：要么"先跑起来再说，反正现在数据量不大"，要么"直接上分布式，一步到位"。

前者是业务增长后被打脸——单库 TPS 到顶了才发现架构没留扩展空间。后者是花了分布式的钱，运维复杂度翻了十倍，但日均只有 1 万笔交易，根本用不上。

这篇把 OLTP 架构演进的每个阶段、每个临界信号、每个坑都讲清楚。你看完就知道自己该在哪一步。

一、OLTP 架构演进的五个阶段

阶段一：单库单表
  ↓ 写入达到单库上限
阶段二：主从复制 + 读写分离
  ↓ 写入仍然不够，读也遇到瓶颈
阶段三：分库分表 + 中间件
  ↓ 跨分片查询痛苦，分布式事务复杂
阶段四：分布式 OLTP（NewSQL）
  ↓ 分析需求增长，OLTP 库被分析查询拖慢
阶段五：HTAP（事务 + 分析融合）

阶段一：单库单表

最简单，也是所有系统的起点。一台数据库服务器，所有数据放在一个库里。

适用场景：日均事务量 <100 万，数据量 <500GB。

临界信号：CPU 使用率持续 >80%，慢查询开始增多。

阶段二：主从复制 + 读写分离

一台主库负责写，多台从库负责读。写入压力没变，但读的压力被分散了。

适用场景：读/写比例不均（如 8:2 或 9:1），读查询成为瓶颈。

临界信号：主从延迟开始出现（秒级到分钟级），从库上的查询开始变慢。

坑：主从延迟会导致"刚写入的数据读不到"。解决方案是核心业务强制走主库，非核心走从库。

阶段三：分库分表 + 中间件

当单库的写性能到顶了，就需要把数据拆到多个库/表里。

分片键选择原则：

• 高频查询条件作为分片键（如 user_id）
• 避免跨分片 JOIN（尽量让关联数据在同一分片）
• 考虑数据分布均匀性（避免热点分片）

分库分表的代价：

• 跨分片查询性能下降
• 分布式事务增加复杂度
• 扩容时需要数据迁移
• 全局唯一 ID 生成（雪花算法、号段模式等）

我在厂里的教训：MES 系统的工单表做分库分表时，选了工单状态作为分片键，结果"待处理"状态的工单全堆在一个分片上，其他分片空荡荡的。后来改成工单号哈希才解决。

阶段四：分布式 OLTP（NewSQL）

原生分布式架构，自动分片和负载均衡，不用手动拆表。

代表产品：TiDB、OceanBase、CockroachDB、GoldenDB。

优势：

• 水平扩展：加节点就能提升吞吐量
• 分布式事务内置
• 自动负载均衡

代价：

• 运维复杂度高（需要管理计算节点、存储节点、调度组件）
• 延迟略高于单库（网络往返开销）
• 需要分布式数据库运维经验

阶段五：HTAP（混合事务分析处理）

同一套引擎同时支持 OLTP 和 OLAP，避免数据同步延迟。

二、HTAP：三种路线，怎么选？

路线一：行存 + 列存双引擎

典型代表：TiDB（TiKV 行存 + TiFlash 列存）。

OLTP 写入行存，通过 Raft Learner 异步同步到列存。OLAP 查询走列存，不干扰 OLTP 性能。数据延迟通常在秒级到分钟级。

路线二：行列混存

典型代表：Oracle In-Memory、SAP HANA。

同一份数据在内存中同时维护行式和列式表示。OLTP 和 OLAP 查询自动路由到最优存储格式。零同步延迟，但内存开销翻倍。

路线三：资源隔离

典型代表：PostgreSQL 资源组、金仓 KES 连接池隔离。

在同一数据库实例中，通过 CPU/内存/IO 资源池隔离不同负载。OLTP 事务和分析查询各用自己的资源池，互不干扰。

金仓 KES 在这条路线上做得比较彻底：除了资源组隔离 CPU 和内存，还通过连接池把 OLTP 和 OLAP 的查询通道分开，避免分析查询的连接数挤占 OLTP 的连接资源。同时 OLTP 和 OLAP 之间通过 logical decoding 实时同步，不需要额外的 CDC 组件或 ETL 调度。

这条路线适合中小规模场景：不需要额外部署分析引擎，部署简单，运维成本低。但隔离不如双引擎彻底，大规模场景还是双引擎更稳。

HTAP 适用场景速查

三、OLTP 架构演进的临界信号

什么时候该升级架构？不是拍脑袋，是看数据。

何时进入读写分离？

• Buffer Pool 命中率 >95%，但 CPU 使用率持续 >80%
• 慢查询日志中，读查询占比 >70%
• 业务读/写比例明显不均

何时进入分库分表？

• 单库 TPS 持续超过 5,000，且硬件已顶配
• 单表数据量超过 5000 万行，索引维护开销明显
• 写入延迟 P99 持续超过 200ms

何时进入分布式 OLTP？

• 分库分表后，跨分片 JOIN 性能无法接受
• 分布式事务成为性能瓶颈
• 扩容需要停机迁移数据，业务不能接受

何时考虑 HTAP？

• 业务需要实时分析结果（秒级到分钟级）
• OLTP 库被分析查询严重拖慢
• 实时风控、实时推荐、实时报表等场景

四、演进中的常见陷阱

陷阱一：用 OLTP 引擎做分析查询

在 OLTP 库上跑大表 JOIN 和 GROUP BY，会拖慢事务性能。正确的做法是通过 CDC 将数据同步到 OLAP 引擎。

我之前在制造业，财务部门每天要跑一个库存周转率分析，直接从 OLTP 库里查三张大表的 JOIN。结果每到月初那几个小时，产线报工的响应时间从 50ms 飙升到 2 秒。后来把这个分析通过 CDC 同步到分析库，两边互不干扰。

陷阱二：只看 TPS 不看延迟分布

一个系统 TPS 很高，但 P99 延迟 500ms，用户体验会非常差。一定要看延迟的百分位分布。

陷阱三：忽视迁移成本

从 Oracle 迁移到开源数据库，如果存储过程有 10 万行 PL/SQL，改写成本可能比许可费用还高。此时选择高兼容的替代方案反而更经济。

陷阱四：分布式不是银弹

日均 100 万笔交易的系统不需要分布式 OLTP。选择与业务规模匹配的方案，留出扩展空间即可。

五、OLTP 选型的决策框架

5.1 先评估业务规模

5.2 选型维度

5.3 不同类型 OLTP 数据库的适用场景

传统关系型（MySQL、PostgreSQL 等）

• 适用：中小规模 OLTP、团队熟悉度高
• 局限：写扩展需要分库分表

分布式 OLTP / NewSQL（TiDB、OceanBase 等）

• 适用：大规模高并发、需要水平扩展
• 局限：运维复杂度高

Oracle 兼容型（金仓 KES、达梦等）

• 适用：Oracle 迁移、金融级事务、PL/SQL 存储过程依赖
• 优势：金仓 KES 对 Oracle 的 PL/SQL 兼容率达到 90% 以上，NVL、DECODE、CONNECT BY 等核心语法几乎不需要改写。原生兼容 Oracle RAC，RPO=0、RTO<30 秒，高可用级别跟源端对等。迁移工具链完整：KFS 全量搬迁 + logical decoding 增量同步，可以并行跑验证数据一致性后再切换。在制造业 MES 系统迁移中，存储过程改写量从预估的 40% 降到了不到 10%，大幅降低了迁移风险
• 局限：许可成本（商业版）

云原生 OLTP（Aurora、PolarDB 等）

• 适用：云上部署、弹性伸缩需求
• 局限：锁定特定云厂商

5.4 Oracle 迁移的特殊考量

迁移成本里，存储过程改写是大头。如果源端 Oracle 有 10 万行 PL/SQL，改写成本可能远超数据库许可费用。所以在 Oracle 迁移场景下，兼容性评估一定要做在选型前面。

金仓 KES 在 Oracle 迁移场景下有个明显的差异化优势：对 Oracle 的 PL/SQL 兼容率达到 90% 以上，NVL、DECODE、CONNECT BY 等核心语法几乎不需要改写。而且原生兼容 Oracle RAC，在城商行核心账务系统迁移场景里，RPO=0、RTO<30 秒，高可用级别跟源端对等。迁移工具链也完整——KFS 做全量搬迁，logical decoding 做增量同步，两边可以并行跑一段验证数据一致性，不需要停机切换。这个迁移链路在实际项目里跑通过，比纯开源方案的"评估-导出-导入-验证"流程要稳。

六、总结

OLTP 架构演进不是"一步到位"，而是跟着业务规模走：

1. 单库单表是起点，简单但要关注性能上限
2. 读写分离解决读瓶颈，但写还是单点
3. 分库分表解决写瓶颈，但跨分片查询是代价
4. 分布式 OLTP 原生扩展，但运维复杂度上升
5. HTAP 融合交易和分析，但要看场景是否值得

选型的核心原则：不要过度设计，也不要低估增长。选择与当前业务规模匹配的方案，留出扩展空间。

如果你在做 Oracle 迁移或信创选型，建议先做一次兼容性评估：统计存储过程行数、PL/SQL 语法使用频率、RAC 依赖程度，再决定迁移路径。

👋 小耶在手，SQL不愁