📌 关键词：分布式数据库、分布式集群、共享存储集群、集中式数据库、交易型数据库、OLTP、国产数据库、数据库架构演进
大家好！我是数据库小学妹 👋
之前讲过Oracle 替代和国产数据库选型，有小伙伴问了一个很实在的问题："我们公司数据量越来越大，单机数据库快扛不住了，是不是该上分布式？"
这个问题问得好。这两年"分布式数据库"这个词出现的频率越来越高，但说句实话——分布式不是银弹。用对了是利器，用错了是包袱。
今天就聊聊分布式数据库到底解决了什么问题、怎么选架构，还有最重要的——什么场景真的需要它。
一、为什么都在谈"从集中式到分布式"？
先搞清楚一个前提：集中式数据库没有死，也不会死。
集中式（单机/主备架构）有几个天然优势：架构简单、运维省心、一致性好搞。MySQL 单机跑个几百 GB 数据、几千 QPS 的并发，大部分场景够用了。
但问题是——业务是会长的。
我跟一个做电商的朋友聊过，他们三年前 MySQL 单机跑得好好的，后面业务翻了五倍，单表数据量干到了 2 亿行，高峰期一条查询能跑十几秒。这时候不是"想不想"换架构的问题，是"不得不"换。
总结下来，推动企业从集中式走向分布式的，主要是三个因素：
| 驱动因素 | 具体表现 | 集中式的天花板 |
|---|---|---|
| 数据量增长 | 单表上亿、库容量几百 TB | 单机存储有物理上限，扩展靠加硬盘总有瓶颈 |
| 并发压力 | 高峰期 QPS 破万、连接数上千 | 单机 CPU/内存有限，连接池再优化也扛不住指数级增长 |
| 高可用要求 | 核心业务不能停，RPO=0、RTO 秒级 | 主备切换有窗口期，跨机房容灾架构成本高 |
尤其是金融、电信、政务这些行业，系统连续性要求越来越高。以前允许停机一小时的业务，现在已经不能被接受了。
所以，"走向分布式"不是追技术潮流，是被业务逼出来的。
二、分布式数据库绕不开的三个坎
分布式说起来简单——数据分到多台机器上，大家一起干活。但真动手的时候，有三个问题绕不过去。
数据分片：怎么切？
把数据拆开放到不同节点，怎么切是关键：
- 按某个字段（比如用户 ID）做哈希取模，分布均匀，但跨分片查询就麻烦了。
- 按时间或 ID 范围切，查询友好，但容易热点不均——比如按日期切，今天的那个分片压力贼大。
- 按租户或地区分，业务隔离性好，但运维复杂度跟着涨。
没有哪种方式是万能的，完全看你的查询模式。切错了方向，后面全是坑。
分布式事务：ACID 还能不能保证？
集中式数据库的事务是本地事务，一条 COMMIT 完事。分布式场景下，一个事务可能跨好几个节点，这事就复杂了。
CAP 理论说得很明白：一致性、可用性、分区容错性，三个只能保住两个。
实际工程中，大多数分布式数据库走的是折中路线——核心交易用强一致（比如两阶段提交 2PC），非关键场景接受最终一致。
具体落地方案，常见这几个：
- 2PC（两阶段提交）：强一致，但性能开销不小。
- TCC（Try-Confirm-Cancel）：业务层补偿，灵活但不通用。
- Paxos/Raft 共识协议：通过多数派写入保证一致性，目前主流选择。
全局一致性：读到的数据到底是不是最新的？
分布式环境下数据有多个副本，你从一个节点读到的东西是不是最新的？这可不是小问题。
这里涉及几个概念：强一致读（读到的一定是最新写入）、最终一致读（可能读到旧数据但最终追上）、会话一致读（同一个会话内保证读到自己的写入）。
不同场景需要的保障级别不一样。银行转账必须强一致，用户头像延迟几秒同步完全没问题。
三、三种主流分布式架构，怎么选？
目前市面上常见的分布式数据库架构，我大致归纳为三种路线：
| 架构路线 | 代表思路 | 核心特点 | 适用场景 |
|---|---|---|---|
| 分库分表中间件 | 在应用和数据库之间加一层中间件（如 ShardingSphere） | 部署相对简单，但跨分片查询能力有限 | 业务拆分较清晰的场景 |
| 原生分布式数据库 | 数据库内核原生支持分布式（如 TiDB、OceanBase） | 对应用透明、自动分片、弹性伸缩，但架构复杂 | 高并发互联网场景、海量数据 |
| 共享存储集群 | 多节点共享同一份存储，节点间高速互联（如金仓共享存储集群、Oracle RAC） | 强一致性有保障、不需数据分片，硬件要求较高 | 核心交易系统、一致性要求严格的场景 |
三种路线无所谓谁好谁坏，看场景。
分库分表中间件路线，成本低、上手快，适合业务逻辑清晰、跨库关联查询少的场景。
原生分布式路线扩展性好，但运维复杂度也跟着上去了。我见过有团队上了分布式之后，DBA 从 2 个变成了 5 个——不是因为业务涨了，是因为排查问题变难了。
共享存储集群路线在一致性上做得更扎实，金融核心系统这种"数据不能错、绝对不能丢"的场景尤其合适。国产数据库里，金仓（KES）的共享存储集群方案走的就是这条路，同时它还有分布式集群部署能力，等于两条腿走路。
四、金仓的分布式方案：集中分布一体化的思路
前面提到金仓，稍微展开说一下。
金仓在分布式这件事上的思路挺有意思——它没有把集中式和分布式做成两个产品，而是单一数据库内核，原生同时支持集中式与分布式两种部署形态。官方叫"集中分布一体化"，是金仓"五个一体化"产品架构里的重要组成部分。
一体化核心原理
很多数据库的集中式和分布式其实是两套代码、两套运维体系。金仓不一样，它在同一套内核上实现了两种形态：
- 共享存储集群模式：多节点共享存储，读写分离，高可用。适合对一致性要求高的 OLTP 场景。
- 分布式集群模式：数据分片、水平扩展。适合数据量大、需要弹性伸缩的场景。
因为是同一套内核，用户看到的 SQL 语法、开发接口、管理工具都是统一的。这就意味着：
1. 平滑演进，不用换产品
之前去客户现场，有个银行的架构师说了一个很实在的痛点：他们最怕的不是选型，是"选错了回头重来"。
金仓这个方案的好处是，业务初期数据量不大的时候用集中式部署，后面业务涨了、数据量上来了，可以直接扩展到分布式集群——数据库产品不用换，应用代码不需要重构。对业务连续性要求高的行业来说，这一点很关键。
2. 统一运维，管理成本降下来
集中式和分布式共用一套运维体系，监控、备份、告警、SQL 调优的体验是一致的。不用像传统方案那样，集中式一套工具、分布式又换一套——那种运维的碎片化，才是真正吃人的隐性成本。
总结：先上车，再升级
金仓这个方案给我的感觉是务实。它不逼你在项目初期就选死"集中式还是分布式"，而是让你先用集中式跑起来，后面按需扩展。这种渐进式的演进路径，对大多数企业来说，比一步到位上分布式要稳妥得多。
五、到底要不要上分布式？一个简单的判断框架
先问自己一个问题：集中式真的扛不住了吗？
什么时候值得上分布式
- 数据量到了 TB 甚至 PB 级，单机存储快到头了。
- 并发请求量万级以上，而且还在持续涨。
- 需要跨机房、跨地域部署，对高可用和容灾有硬性要求。
- 业务增长不可预测，需要随时能扩容。
什么时候集中式就够了
- 数据量几百 GB 以内，单机轻松装下。
- 并发量几千 QPS，MySQL 或 PostgreSQL 配好索引完全够用。
- 业务逻辑复杂、跨表关联多——上了分布式查询反而更慢。
- 团队规模小、DBA 资源紧张——运维分布式比运维单机累多了。
如果答案是"集中式还行"，那就别折腾。把索引优化好、查询优化好、读写分离做好，集中式的天花板比你想象的高得多。
如果答案是"确实不行了"，那就认真评估哪种分布式架构匹配你的实际场景。别一上来就奔最大的架构去。
六、总结
聊了这么多，核心就几句话：
集中式数据库远没有过时。 大多数企业现在的数据量和并发，单机架构完全够用。别因为"分布式"这个词火就觉得不用就落后了——那是在给自己找麻烦。
分布式解决的是天花板问题。 当数据量和并发真的超过了单机承载能力，分布式提供了扩展的出路。但它不是免费的午餐，运维复杂度、事务一致性、数据分片策略——每一个都是实打实的成本。
架构选型没有标准答案。 分库分表中间件、原生分布式、共享存储集群，每种路线都有它适合的场景。选之前搞清楚自己的数据规模、查询模式和高可用需求，比对比产品参数重要得多。
金仓这类"双模"方案给了企业一个渐进式选项： 可以从集中式集群起步，按需扩展到分布式，不用一开始就把整个架构推到重来。
技术选型最怕的不是选错，是不知道为什么选。搞清楚"我需要什么"比知道"市场上有什么"重要一百倍。
如果你也在纠结要不要上分布式，或者已经在搞了遇到什么坑，欢迎评论区聊聊！👋
我是数据库小学妹，我们下期见！
本文基于个人学习和实践经验撰写，仅作为技术分享，不构成任何产品推荐或技术选型建议。文中观点仅代表个人，欢迎同行交流指正。
