分布式存储架构演进十周年：从分库分表、中间件到原生分布式 Multi-Raft

分布式存储架构演进十周年：从分库分表、中间件到原生分布式 Multi-Raft

站在 2026 年秋天的这个时间节点回望，企业级数据基础设施与分布式存储架构，在过去的整整十年里，经历了一场波澜壮阔的技术大迁徙。

十年前（2015~2016 年前后），当互联网业务数据量从“千万级”野蛮生长至“百亿级”、“万亿级”时，单机关系型数据库在物理容量与连接数上面临着崩溃的边缘。

为了应对海量数据的吞吐压力，一代又一代的架构师与数据库工程师，在不同的历史阶段给出了三种截然不同的架构解法。

深入复盘这三代架构的演进逻辑、技术代价与本质局限，我们才能真正看懂：为什么“原生分布式 Multi-Raft 底座”是海量数据存储演进的终极必然归宿！

[分布式存储架构十年演进三代进化全景]

第一代: 客户端分库分表 (2015~2019, Sharding-JDBC / TDDL)
[应用代码] ──(硬编码分片规则: order_id % 1024)──▶ [1024 张物理 MySQL 分表]
(致命痛点: 业务侵入极深、跨分片 JOIN 彻底失效、扩容必须停机重分片!)
─────────────────────────────────────────────────────────────
第二代: 集中式数据库代理中间件 (2019~2023, MyCat / DBProxy)
[应用代码] ──▶ [集中式 Proxy 网关集群] ──▶ [后置 MySQL 分库集群]
(致命痛点: Proxy 自身成为单点瓶颈、分布式 2PC 性能极其昂贵、脑裂风险高)
─────────────────────────────────────────────────────────────
★ 第三代: 原生分布式 Multi-Raft 底座 (2023~2026+, 当前方案)
[应用代码] ──(标准 SQL 接口, 0 侵入)──▶ [无状态分布式 SQL 计算层]
│
▼
[原生 Multi-Raft 存储池: 25 万个 Region 自动动态分裂、自适应迁移与多副本强一致!]

第一代（2015~2019）：客户端分库分表的“手工痛苦时代”

在第一代架构中，分布式能力完全被生硬地塞进了业务应用代码或 SDK 内部（如早期的 TDDL、Sharding-JDBC）：

• 业务代码强耦合：研发人员写每一句 SQL 都必须小心翼翼地带着 sharding_key；
• 扩容代价深不见底：一旦预先规划的 1024 张表容量用完，团队必须停机数天，编写极其繁琐的双写迁移脚本进行“再拆表（Re-sharding）”；
• 分布式事务彻底裸奔：跨库事务只能依赖业务层做极其复杂的 TCC / Saga 最终一致性补偿，研发心智负担极其沉重！

第二代（2019~2023）：集中式代理中间件的“妥协与瓶颈”

为了解决业务代码侵入的问题，行业演进出了独立的数据库代理层（如 Cobar、MyCat、MySQL Proxy）：

• 解决的痛点：对外暴露统一的单个 MySQL 协议端口，业务无需再关心底层分表；
• 致命新瓶颈：
• Proxy 节点自身成为了网络与内存的巨大单点性能瓶颈；
• 底层依然是数十个独立的 MySQL 实例，分布式 2PC（两阶段提交）在跨网络下性能极其昂贵（TPS 极低）；
• 一旦发生网络分区，Proxy 极易发生误判导致脑裂脏写！

第三代（2023~2026+）：原生分布式 Multi-Raft 底座的“降维打击”

第三代原生分布式架构彻底打破了“分库分表”的旧思维，从底层存储引擎和共识算法层进行了革命性重构：

[原生分布式 Multi-Raft 架构三大终极降维打击优势]

1. 存储层真强一致:
– 每个 Region 分片通过 Multi-Raft 多数派实现硬件级高可用，彻底告别异步主从复制丢失数据!

2. 极致弹性与自愈:
– 分片超过 96MB 自动分裂，新机器上线自动拓扑再均衡，扩容搬迁业务发生整整 0 感知!

3. 完整 ACID 分布式事务:
– 基于 Percolator / MVCC 与乐观锁/悲观锁并发控制，跨全集群任意表关联如同单机一样优雅自然!

• 单表万亿行无感承载：研发人员像使用单机 MySQL 一样建表，无需再关心任何分片规则；
• 万亿规模秒级自愈：96 台裸金属节点、25 万个分片在后台实现无人值守的自动化负载均衡。

结语

从人工拆表的狼狈与苦涩，到原生分布式底座的优雅与从容。这十年的技术大演进，本质上是软件工程将“复杂性不断下沉至系统底层、把简单与确定性还给业务开发者”的伟大胜利！