企业官网建设流程全解析

📌今日关键词：数据库集群、分布式、主从复制、RAC、分库分表

大家好，我是数据库小学妹 👋

之前有朋友问我：读写分离已经撑不住了，是不是该上分布式了？

我当时就想：你确定需要的是分布式吗？很多人把集群和分布式混着用。选型时很容易踩坑。

今天就用数据库的视角，把集群和分布式讲清楚。搞懂了这两个概念，后面的选型才不会踩坑。

先搞清楚概念，集群≠分布式

用一句话概括：集群是多台机器干同一件事。分布式是多台机器干不同的事。

集群要的是高可用和负载均衡。一台扛不住，加一台。两台都跑同样的服务。所有节点持有完整的数据副本，或者共享同一份存储。

分布式要的是拆分。一个大任务拆成多个小任务，每个节点负责一部分。每个节点只持有数据的一个分片。

两者不矛盾。分布式里的每个节点，本身可以是一个集群。

但这两条路的代价、复杂度、适用场景差别非常大。选错了，后面改起来成本翻倍。

数据库集群，三条技术路线

数据库集群不是只有一种形态。从简单到复杂，有三条路线。

第一条：主从复制

一台主库负责写，多台从库负责读。读请求分散到从库，主库压力减轻。这就是读写分离。

主从复制的问题在于故障切换。主库挂了，从库需要把落后的WAL日志追完才能接管。数据量大的时候，追赶过程可能要几分钟。这段时间业务是中断的。

更危险的是WAL同步延迟。主库的日志还没来得及传到从库，切换后这部分数据就丢了。RPO不为零，这对核心业务来说是硬伤。

第二条：读写分离集群

在主从复制基础上加了中间件。应用不用关心读请求发到哪个从库。ProxySQL、MySQL Router都是干这个的。

但本质上还是主从复制。写入瓶颈没解决，数据追赶的问题也没解决。中间件只是让应用层更方便了，底层的硬伤还在。

第三条：共享存储集群（RAC）

多台数据库节点共享同一份存储。主节点挂了，备节点直接接管存储，不需要数据追赶。切换能做到秒级，数据零丢失。

这条路线和前两条有本质区别。主从复制靠"日志同步"保证数据一致，总有同步延迟的窗口。共享存储集群靠"同一份存储"保证一致。根本不存在同步延迟。

KES的共享存储集群方案就是这个思路。多节点共享同一份存储，主备切换没有数据追赶过程。RPO能做到零，RTO在秒级。对核心账务、交易系统来说，这个差异是决定性的。

集群解决的是"扛不住"的问题。加机器，分摊压力。

但集群有个硬伤：写入还是集中在主节点。读可以分散，写不行。要解决写入瓶颈，得看分布式。

选集群路线时要想清楚：业务能接受多长的故障切换时间？

能接受多大的数据丢失风险？这两个问题的答案，决定了你该选主从复制还是共享存储集群。

分布式数据库，长什么样

当单台机器的写入能力到顶了，光加从库没用。这时候需要分布式。

分布式数据库把数据拆成多个分片。每个分片存储一部分数据。不同分片可以分布在不同节点上。

分库分表是很常见的分布式手段。按用户ID取模，把数据分散到多个库。每个库独立处理自己的读写。KES也支持数据分片能力，写扩展不再是分布式数据库的专属。

但分布式也有代价，而且比想象中大：

跨分片查询是大坑：按用户ID分片后，想按订单时间范围查？得扫所有分片再合并排序。数据量一大，性能断崖式下跌。

分布式事务代价高：一个事务涉及两个分片，就要走两阶段提交。网络往返多一倍，锁持有时间拉长，吞吐直接腰斩。

扩缩容不是加台机器那么简单：加一个分片，数据要重新分布。线上业务做数据迁移，规划不好就是一场事故。

Schema变更复杂度翻倍：改一个字段类型，在单机上一条DDL搞定。在分布式环境下，每个分片都要改，还得保证一致性。

分布式解决的是"单点瓶颈"的问题。读和写都能横向扩展。但运维复杂度不是线性增长，是指数级的。

选分布式之前，建议先问自己三个问题。数据量真的到了单机存不下的地步吗？业务能接受跨分片查询的性能损失吗？团队有没有分布式运维的经验？三个问题有一个答案是否定的，就该重新考虑。

一张表看懂区别

看完这张表你可能会觉得：集群简单但写入有瓶颈。分布式能扩展但太复杂。

这也是很多DBA在选型时最纠结的地方。有没有一种方案，能兼顾两条路的优势？

市面上确实有数据库在尝试这件事。用同一套内核支撑集群和分布式。让企业不用一开始就押注某一种架构。金仓KES就是这个思路。

从主备集群到共享存储集群（RAC），再到无共享分布式（Sharding）。全系列覆盖，按需叠加。

四阶段演进路径：

起步阶段：主备集群。中小规模业务，高可靠基础需求。RPO做到零，RTO在30秒以内。

增长阶段：读写分离集群。读多写少、高并发查询场景。吞吐量能提升数倍。

核心阶段：共享存储集群（RAC）。金融核心系统，对标Oracle RAC。2到8个节点同时对外服务，RPO零，RTO在10秒以内。

海量阶段：无共享分布式（Sharding）。PB级数据、超高并发场景。7个节点能跑到1090万TPMC。

换架构不换产品。从主备到RAC，应用代码无需修改。从集中式到分布式，金仓KES提供了最平滑的过渡路径。

很多数据库厂商只做分布式，或者只做集群。选了之后就被锁死了。业务量涨了只能换产品，迁移成本巨大。KES的集中分布一体化理念，让企业可以按需选择、平滑演进。不用为未来不确定的流量提前支付高昂的分布式成本。

真实案例验证：

某头部基金公司的TA系统，清算耗时从40分钟降到1.5分钟。性能提升26倍。

某大型金融机构核心交易系统，采用金仓两地三中心方案。RPO为零，稳定运行超百天。

某大型运营商一级BOSS枢纽系统，连接31个省。六套高可用集群跑出99.999%可用性。故障切换不到30秒。

超九成产业央企共同选择金仓，累计部署超两万套。中国移动单一客户就部署了约2000套，覆盖B域、O域、M域全场景。

Oracle兼容能力：

如果是从Oracle迁出来的团队，这一点尤其重要。Oracle的PL/SQL、存储过程、序列这些特性，换到分布式架构上基本都得重写。工作量非常大。

KES同时兼容Oracle、MySQL、SQL Server、PostgreSQL四大语法体系。Oracle常用功能的兼容性做得非常深。PL/SQL、存储过程、序列、同义词基本可以直接跑。迁移成本能砍掉一大块。

配合金仓的迁移工具链：KDMS做评估，KDTS做全量迁移。Kingbase FlySync做增量同步，KDC做数据校验。覆盖迁移全流程，实现低难度、低风险、低成本的平滑迁移。

对信创迁移的团队来说，这个省下来的工作量不是小数目。

很多团队在信创迁移时头疼的不是选哪个数据库。而是选什么架构。集群够不够用？要不要上分布式？选错了，迁移成本翻倍都不止。KES的集中分布一体化，让这个问题变得简单。先用集群顶住，后面不够了再加分布式，不用推倒重来。

什么时候用集群，什么时候用分布式

这是DBA选型一定要想清楚的问题。

读多写少？集群就够了。写多读少或者读写都大，考虑分布式。先看读写比例。

单库几个G到几百G，集群扛得住。数据量到TB级，单机存不下，就得上分布式了。

能接受最终一致性的话，集群的主从延迟可以优化到毫秒级。要求强一致，分布式事务的代价你得认。业务容忍度这关，很多人卡在这里。

还有团队能力。集群运维相对简单，DBA上手快。分布式运维门槛高，故障排查复杂度翻倍。

一句话：能用集群解决的，别急着上分布式。

几个容易踩的坑

说几个我见过的、也踩过的坑。

概念混淆是大忌。有人把读写分离叫分布式，有人把主从复制叫集群。概念不清，选型必歪。先搞清楚自己要的是"多台机器干同一件事"还是"把数据拆开"。

分库分表别冲动。我见过有团队数据量才几百G就急着分库分表。结果跨分片查询慢得要命，分布式事务把性能拖垮了。最后不得不退回来，折腾了三个月。数据量不到TB级，集群加从库基本够用。

共享存储集群要看存储层。存储本身是单点的话，高可用就是假的。选方案的时候，一定要确认存储层有没有冗余。

故障切换不能只看文档。得在真实负载下跑一次演练。不演练就不知道切换要多久、会丢多少数据。很多团队上线后第一次主备切换就翻车。就是因为没提前演练过。

信创迁移先定架构再选数据库。顺序搞反了，后面改架构的成本比选型成本高十倍。金仓KES的集中分布一体化方案，让这个问题变简单了。先用集群顶住，后面不够了再加分布式，不用推倒重来。

SQL兼容性要提前扫。存储过程、触发器、自定义类型，这些迁移前必须逐项评估。不扫就上，后面发现一堆SQL跑不了，改写工作量能把你吓一跳。

集群和分布式不矛盾，关键是搞清楚自己的场景需要什么。

信创这件事已经不是"要不要做"的问题了，而是"怎么做好"的问题。选数据库之前，先把架构方向想清楚。金仓KES的集中分布一体化方案，让企业不用二选一。按需选择、平滑演进，才是降本增效的正经路子。

各位在架构选型上还踩过哪些坑？评论区聊聊，互相学习。

我是数据库小学妹，咱们下篇见 👋