大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
去年，某能源集团的核心交易系统在业务高峰期遭遇了一次"惊魂时刻"------并发请求突破特定阈值后，单机架构的锁竞争导致响应延迟从50ms飙升到3秒以上，系统触发熔断，业务中断了整整8分钟。团队连夜开会，争论的焦点只有一个：要不要上分布式？
这不是个例。我几乎每周都会遇到类似的问题："单机扛不住了，是不是该上分布式？"
但很多人的决策路径是错的------先听说"分布式很厉害"，再看几个产品介绍，然后开始选型。正确的顺序应该是：先判断"该不该上"，再决定"怎么上"。
一、分布式数据库到底是什么？
在聊"该不该上"之前，先把"分布式数据库是什么"讲清楚。
想象一座城市图书馆。一开始只有总馆，所有书都在一个地方，找书快、管理简单------这是集中式数据库 。后来书越来越多，总馆放不下了，于是在城市不同区域开了分馆。每个分馆有自己的藏书，读者去最近的分馆借书------这是分布式数据库 的关键：数据物理上分散在不同节点，但读者（应用程序）感知到的仍然是一个统一的图书馆（逻辑上统一的数据库）。
分布式数据库的核心能力是数据分片、分布式事务和弹性扩展。它解决了集中式单机的容量和性能天花板，但也带来了新的复杂性------跨节点查询的性能代价、分布式事务的一致性开销、运维难度的提升。
分布式数据库的三种技术路线
| 路线 | 数据怎么分 | 代表产品 |
|---|---|---|
| Share-Nothing（无共享） | 数据水平切片，每个节点独立存储和计算 | 金仓KES Sharding、TiDB、OceanBase |
| 共享存储集群 | 所有节点共享一份存储，各自计算 | 金仓共享存储集群、Oracle RAC |
| 分库分表中间件 | 中间件做路由，底层MySQL实例各自独立 | ShardingSphere、MyCat |
二、先回答三个问题，再决定上不上
不是所有"数据量大了"都需要上分布式。在选型之前，先用三个问题做个判断。
问题一：数据量到底多大？
-
单表<1000万行、总数据<10TB → 集中式完全够用，加读写分离可能就能解决问题
-
单表>1亿行、总数据>50TB → 需要考虑分布式
-
介于两者之间 → 可以先考虑分库分表或共享存储集群
问题二：业务高峰期能不能扛住？
-
并发QPS<1万 → 集中式+读写分离大概率够用
-
并发QPS>5万、且持续增长 → 分布式可能是必要选择
问题三：对RPO/RTO的要求有多高？
-
RPO=0（数据零丢失）、RTO<30秒 → 原生分布式数据库通过Paxos/Raft协议天然支持
-
可接受分钟级恢复 → 集中式主从切换可能就够用
判断标准：以上三个问题，至少两个回答"是"，才值得认真考虑分布式。如果只有一个"是"，先优化现有架构，别急着上分布式。
三、三种架构路线怎么选？
如果决定上分布式，接下来要选"哪条路线"。分布式不是铁板一块，下面拆成三条子路线。
路线一：Share-Nothing（无共享架构）
这是原生分布式数据库最主流的技术路线。每个节点独立拥有CPU、内存和存储，数据通过分片策略均匀分布到各节点，节点之间通过网络通信协调事务。
技术原理：一张大表的数据按分片键打散到多个节点，每个节点只负责自己那一份数据的读写。查询时，如果条件包含分片键，直接路由到对应节点------快；如果不含分片键，需要广播到所有节点再合并结果------慢。
优势：水平扩展能力强，理论上可以无限加节点；自动分片对应用透明；容灾能力强（多副本+自动切换）。
坑：分片键设计直接影响性能上限，选错了会导致数据倾斜；跨节点JOIN和分布式事务有额外开销；运维复杂度显著高于集中式。
代表产品：
金仓KES Sharding：金仓KingbaseES的分布式版走的是"集中+分布式"一体化路线------一套内核同时支持两种部署模式。企业可以先从集中式起步，当数据量和并发增长到单机瓶颈时，再平滑扩展到分布式集群，无需更换产品线。KingbaseES V9通过KES Sharding组件实现数据分片与全局事务透明化，分布式事务引擎将跨节点协调的延迟控制在毫秒级以内。
TiDB：PingCAP开源的分布式SQL数据库，MySQL协议兼容，三层架构（TiDB Server+PD+TiKV），适合互联网高并发、云原生SaaS等场景。
OceanBase：蚂蚁集团自研，Shared-Nothing架构，基于Paxos协议实现RPO=0、RTO<8秒，兼容Oracle和MySQL双生态，在金融行业分布式数据库市场中占据领先位置。
路线二：共享存储集群
多个计算节点共享同一份存储数据，通过集群文件系统协调访问。
技术原理：数据只有一份，存在共享存储设备上。所有计算节点都能读写这份数据，通过分布式锁或集群文件系统协调并发访问。节点故障时，其他节点直接接管，不需要数据迁移。
优势：对应用透明，不需要改造SQL和分片键；数据只有一份，没有分片间的数据倾斜问题；RTO极短，节点故障时业务连续性有保障。
坑：存储层可能成为单点故障和性能瓶颈；共享存储设备成本高；扩展性受限于存储层的吞吐能力。
代表产品：
金仓共享存储集群：金仓KingbaseES的共享存储架构支持多节点共享同一份数据，集群内所有节点对等，任一节点故障时业务可自动切换，无需人工干预。特别适合不想改应用代码、希望平滑替换Oracle RAC的企业。
Oracle RAC：Oracle的共享存储集群方案，金融、电信行业运行了二十多年。
路线三：分库分表中间件
在应用层和数据库之间加一层中间件，把数据按规则拆到多个MySQL实例上。底层仍然是单机MySQL内核，中间件只负责路由和聚合。
技术原理：应用层SQL发到中间件，中间件解析SQL中的分片键，把请求路由到对应的MySQL实例，然后聚合结果返回。
优势：技术成熟、生态完善，MySQL技术栈不用换；适合已有大量MySQL存量业务、需要短期扩展的场景。
坑：运维复杂------分片规则管理、扩容数据重分布、跨分片查询都需要人工介入；分布式事务需要应用层用补偿逻辑处理；本质上是在单机事务之上"叠"了一层，无法做到内核级的强一致性。
代表产品：ShardingSphere（Apache顶级项目，Java技术栈中广泛应用）、MyCat。
四、选型决策框架
| 场景 | 推荐路线 | 理由 |
|---|---|---|
| 已有大量MySQL存量业务，需短期扩展 | 分库分表中间件 | 改造成本相对低，但长期运维成本高 |
| 不想改应用代码，希望平滑替换Oracle | 共享存储集群 | 对应用透明，RTO极短 |
| 新业务、海量数据、高并发、强一致性要求 | Share-Nothing（原生分布式） | 透明扩展，长期TCO低 |
| 传统企业、需分阶段演进 | Share-Nothing（金仓KES Sharding） | 集中式起步→平滑扩展，无需换产品 |
五、避坑清单
坑1：数据量才几百GB就上分布式
运维成本翻好几倍，最后又退回了集中式。先摸清自己的瓶颈再选型，能用集中式+读写分离解决的别折腾。
坑2：分片键设计失误导致数据倾斜
Share-Nothing架构下，分片键选错了，90%的请求打到同一个节点，其他节点闲着，性能比单机还差。选型前先分析业务查询模式，确认分片键的基数和分布均匀性。
坑3：低估了分布式事务的复杂性
跨节点事务有性能开销，复杂JOIN可能受限于数据分布。POC阶段一定要用真实业务场景做压测，别只看厂商的跑分数据。
六、总结
分布式不是银弹。选型的第一步不是"选哪个产品"，而是"该不该上"。先回答三个问题：数据量到底多大？业务高峰期能不能扛住？对RPO/RTO的要求有多高？
如果决定上，再在三条路线中选一条：Share-Nothing适合海量数据高并发新业务；共享存储集群适合不想改应用、平滑替换Oracle；分库分表中间件适合MySQL存量业务的短期扩展。
选型这件事，顺序别搞反了。先搞清楚自己的需求和约束，再对着产品清单看------谁匹配谁入选。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~