📌 关键词：分布式数据库、Share-Nothing、共享存储集群、数据库选型、国产数据库、金仓KES
大家好！我是数据库小学妹 👋
前面聊了"什么时候该上分布式"，有小伙伴接着问："决定上分布式了，但架构路线怎么选？Share-Nothing、共享存储、分库分表......看得头大。"
这个问题我太有感触了。分布式数据库的架构路线选错了，不是换个配置就能解决的，轻则性能不达标，重则项目推倒重来。
今天就掰开了讲，三种主流架构路线到底有什么区别，各自的坑在哪，怎么选才不踩雷。
一、分布式数据库有哪些？先理清大类
聊路线之前，先搞清楚市面上的分布式数据库大致分几类。
分布式数据库的核心目标就一个：突破单机的性能和容量天花板。但怎么"分布"，各家思路不一样。
目前主流的三种架构路线：
| 路线 | 代表产品 | 数据怎么分 |
|---|---|---|
| Share-Nothing（无共享） | 金仓KES Sharding、TiDB、OceanBase、CockroachDB | 数据水平切片，每个节点独立存储和计算 |
| Share-Disk（共享磁盘） | 金仓共享存储集群、Oracle RAC | 所有节点共享同一份存储，各自独立计算 |
| 分库分表中间件 | ShardingSphere、MyCat、DBLE | 中间件层做路由，底层还是多个独立数据库实例 |
还有一种分类方式是把"分库分表中间件"归为Share-Nothing的变体，因为它底层每个库也是独立的。但从选型角度看，中间件方案和原生分布式差异很大，分开讨论更实用。
二、Share-Nothing：把数据切开，各管各的
原理
Share-Nothing是最常见的分布式架构。思路很直接：把数据按某个规则切片（Sharding），每一片放到一个独立节点上。每个节点有自己的CPU、内存、磁盘，互不共享。
打个比方，一个图书馆的书按字母分到不同房间：A-F在1号房，G-L在2号房，M-Z在3号房。每个房间有独立的管理员和书架，找书的时候去对应房间就行。
优势和坑
好处很直观：数据量大了加节点就行，横向扩展理论上没有上限，每个节点的CPU和内存都是独享的，普通服务器就能搭集群，不依赖高端存储。
但坑也不少。
分布式事务是最大的那个。一个事务跨了多个分片，就要走2PC或者Paxos这类协议，性能开销不小。转账、库存扣减这种强一致性场景，稍不注意就出问题。跨分片查询也头疼，比如"查所有金额大于1万的订单"，如果按用户ID分了片，每个片都得扫一遍再汇总，数据量大了这类查询会很慢。
运维方面也不轻松。分片规则怎么定、热点数据怎么处理、扩缩容怎么做数据迁移，每一步都有坑。我见过有团队上了分布式之后，DBA从2个人扩到5个人，不是业务涨了，是排查问题变难了。SQL兼容性也要注意，跨分片的JOIN、子查询、排序，不同产品支持程度差异很大，选型时一定要拿真实业务SQL去测。
国内走这条路的产品里，金仓KES Sharding是比较有代表性的，运营商网间结算、基金公司TA系统这类高并发场景已经有落地。
三、Share-Disk：共享存储，各算各的
原理
Share-Disk的思路和Share-Nothing完全相反：所有节点共享同一份存储（通常是SAN或分布式存储），每个节点有自己的CPU和内存来做计算。
Oracle RAC是这个路线的典型代表。多个实例跑在不同服务器上，但读写的是同一份数据文件。
优势和坑
Share-Disk最大的好处是数据一致性强。所有节点看的是同一份数据，不存在分片之间数据不一致的问题，应用层不需要改，SQL该怎么写还怎么写，跨表关联、复杂查询都不受限制。故障切换也快，一个节点挂了其他节点直接接管，不需要做数据迁移。
听起来挺美的，但瓶颈很明显：存储是单点。所有节点都去读写同一套存储，IO带宽和延迟就是天花板，节点越多存储压力越大。硬件成本也不低，高性能SAN存储、光纤交换机、共享存储阵列，一套下来比普通服务器贵不少。而且扩展性有限，加节点容易，性能不是线性增长的，存储带宽到顶了加再多计算节点也没用，一般4-8个节点就是实用上限。多节点同时修改同一份数据还需要全局锁协调，高并发写入场景下锁竞争会严重影响性能。
国产方面，金仓共享存储集群（KingbaseES RAC）走的就是这条路，对标Oracle RAC，金融和制造行业的核心系统已有替代案例。
四、分库分表中间件：在应用和数据库之间加一层
原理
分库分表中间件是在应用和数据库之间插入一个代理层。应用发SQL给中间件，中间件根据分片规则把SQL路由到底层的某个数据库实例。
底层每个实例还是独立的MySQL或PostgreSQL，中间件负责"看起来像一个大数据库"。
优势和坑
分库分表中间件的好处是改造成本低。底层数据库不用换，原来用MySQL的继续用MySQL，只加一层中间件就行。应用层也不需要关心数据在哪个分片，中间件帮你做透明路由。加上ShardingSphere这类开源方案社区活跃，文档和案例都比较丰富，上手门槛不高。
但问题也不少。中间件毕竟不是数据库内核，复杂JOIN、子查询、聚合函数的支持程度有限，很多写法在单库能跑，跨库就报错或者性能暴跌。分布式事务在中间件层实现，性能和可靠性都不如数据库内核原生支持。运维方面要同时管中间件和底层数据库两套体系，监控、备份、故障排查都要兼顾。中间件本身也可能成为瓶颈或单点故障，还得给它做高可用。
五、三种路线对比：一张表看清差异
| 对比维度 | Share-Nothing | Share-Disk | 分库分表中间件 |
|---|---|---|---|
| 扩展性 | 好，理论上可线性扩展 | 有限，受存储瓶颈限制 | 较好，加库即可 |
| 数据一致性 | 需要分布式事务保证 | 天然一致，共享同一份数据 | 取决于中间件实现 |
| SQL兼容性 | 跨分片SQL受限 | 与单机一致 | 跨库SQL受限 |
| 运维复杂度 | 高，需要管理分片和多节点 | 中等，硬件运维要求高 | 两套体系，复杂度叠加 |
| 硬件成本 | 普通服务器即可 | 高端共享存储，成本高 | 普通服务器+中间件 |
| 适用场景 | 海量数据、高并发、弹性扩展 | 核心交易、强一致性、中等规模 | 已有MySQL/PG，快速分库 |
选型的时候，别一上来就看哪个"更先进"。先搞清楚自己的业务场景，再匹配路线。
六、怎么选？三个问题帮你做决定
选分布式数据库架构之前，先回答三个问题。
问题一：你的数据量到底有多大？
几百GB到几TB，集中式加个读写分离就够了。到了几十TB甚至PB级，Share-Nothing才真正发挥优势。Share-Disk适合中间地带，几TB到十几TB，对一致性要求高的场景。
问题二：你的业务能容忍多大的一致性延迟？
银行转账、支付清算这种场景，数据不能有任何差错。Share-Disk的共享存储天然保证一致性，这方面比Share-Nothing省心得多。如果业务能接受最终一致性，Share-Nothing的性能上限更高。
问题三：你的团队能运维多复杂的架构？
分布式数据库的运维成本经常被低估。Share-Nothing要管分片策略、数据迁移、分布式事务，对DBA能力要求高。Share-Disk硬件运维要求高，但软件层面和单机差异不大。分库分表中间件看起来简单，实际上要同时运维中间件和底层数据库两套。
七、国产分布式数据库怎么选？
信创背景下，很多企业选分布式数据库还要加一条：得是国产的。
国产分布式数据库目前主要有三个技术方向：集中式+分布式一体化（金仓KES、达梦DM8）、原生分布式（TiDB、OceanBase）、以及分布式中间件+单机数据库（如TDSQL、GoldenDB）。
前面聊Share-Nothing和Share-Disk时分别提到了KES Sharding和共享存储集群，其实这两条路在金仓KES上用的是同一套内核、同一套SQL语法、同一套运维工具。企业可以先用集中式跑起来，后面根据业务需要选择共享存储集群（应用物感知）或KES Sharding（需适度配合分片键设计的改造）来扩展，无需更换产品、应用代码改动量极小。
我接触过一个政务系统的案例，一开始用集中式部署，数据量涨上来之后扩展到了共享存储集群，整个过程应用层基本没改代码。如果当初选了一个纯Share-Nothing的方案，后面想切回集中式或者换路线，成本就大了。
对于金融、政务、制造这些行业来说，这种"集中分布一体化"的渐进式方案，比一步到位上纯分布式要稳妥得多。
总结
回过头来看这三种路线，没有哪个是万能的。Share-Nothing在海量数据和弹性扩展方面确实能打，但分布式事务和运维复杂度是绕不过去的代价，团队能力跟不上的话别硬上。Share-Disk在一致性和高可用方面省心得多，核心交易系统用它比较踏实，只是扩展性和硬件成本要提前想清楚。分库分表中间件适合已有MySQL/PG的团队快速改造，但跨库查询和事务能力的天花板比较低，业务复杂了可能会不够用。
如果你不想在项目初期就把架构路线"锁死"，金仓KES这种集中分布一体化的方案值得看看。它在同一套内核上支持集中式、Sharding、共享存储集群三种形态，业务增长后按需扩展就行，不用换产品也不用改应用代码。在政务、金融、制造这些行业，这套方案已经有比较成熟的落地经验了。
我接触过不少选型的案例，最大的感受就是：选错路线的代价，远远大于多花时间做评估的代价。搞清楚自己要什么，比搞清楚哪个"更先进"重要得多。
大家在分布式数据库选型或使用中，有没有遇到过什么坑？欢迎评论区聊聊~
我是数据库小学妹，一个用设计师思维学数据库的转行人。我们一起，把复杂的技术变得简单有趣！💕
本文基于技术学习和实践经验撰写，旨在分享分布式数据库的架构选型思路。