大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
中国信通院《2024数据库发展白皮书》显示，超过六成的政企用户在核心交易系统升级中，将"强一致性保障下的高可用扩展能力"列为关键选型维度。然而在实际技术选型中，集群与分布式这两个概念经常被混用------很多团队口中的"分布式架构"，实际上只是主从集群；而真正需要分布式写入扩展能力的场景，又可能因为误判而被局限在集群方案中。
集群解决的是"扛不住"的问题，分布式解决的是"装不下"的问题。这两个问题的答案完全不同。
一、集群与分布式：差的不只是一个字
集群（Cluster） ：多台服务器集中在一起，做同一件事。每台机器运行相同的程序，提供相同的服务。核心机制是"复制"，解决的是单点故障和并发压力。所有节点持有完整的数据副本，或者共享同一份存储。
分布式（Distributed） ：把一个业务拆成不同的子任务，分布到不同机器上执行。每台机器处理不同的数据分片，通过网络协同。核心机制是"拆分"，解决的是海量数据和写入瓶颈。
一个结构性差异值得注意：集群的写入能力受限于单节点。读请求可以分散到多个从库，但写操作始终集中在主节点或共享存储层。分布式通过数据分片将写入分散到多个节点，但代价是跨分片查询的复杂度和分布式事务的开销。
两者并不矛盾------分布式环境中的每个分片节点，本身可以是一个集群。但这两条路径的代价、复杂度和适用场景差别非常大，选错了，后期架构改造成本会成倍增加。
集群是加人干一样的活，分布式是分工干不同的活。混用的根源在于：两者都涉及"多台服务器"，但解决的问题完全不同。集群解决的是"一台机器不够稳、不够快"，分布式解决的是"一台机器装不下、写不动"。
二、三条技术路线及其代价
数据库集群不是只有一种形态。从简单到复杂，有三条路线。每条路线解决的侧重点不同，代价也不同。
路线一：主从复制
一台主库负责写入，多台从库负责读取。读请求分散到从库，主库压力减轻。
核心问题是故障切换：主库宕机后，从库需要将落后的WAL日志追完才能接管，数据量较大时追赶过程可能持续数分钟。异步复制模式下，主库写完即返回成功，binlog尚未传到从库时主库发生故障，数据丢失无法避免。
适用场景：读多写少、RPO不为零可接受的业务。
路线二：读写分离集群
在主从复制基础上引入中间件（ProxySQL、MySQL Router等），应用层无需感知读请求路由到哪个从库。
但底层机制未变：写入瓶颈依然存在，数据追赶问题未解决。中间件改善的是应用层的便利性，而非架构层面的根本局限。
适用场景：读请求量大、但写入压力可控的业务。
路线三：共享存储集群（RAC）
多台数据库节点共享同一份物理存储（SAN或分布式存储），通过集群软件将独立服务器节点连接为对等架构。所有节点地位对等，可以同时接受读写请求，共同分担负载。主节点故障时，备节点直接接管存储，不需要数据追赶过程，切换可在秒级完成，数据零丢失。
这条路线与前两条的本质区别在于数据一致性的保障机制。主从复制依赖"日志同步"，存在同步延迟窗口；共享存储集群依赖"同一份存储"，从根本上消除了同步延迟的概念。对核心账务、交易系统而言，这个差异直接决定了RPO能否为零、RTO能否进入秒级。
适用场景：核心交易、要求RPO=0且RTO秒级的业务。
三、金仓KES：从读写分离到分布式的融合集群架构
金仓KES的集群方案不是单一产品的堆叠，而是在同一内核下的融合架构，覆盖从读写分离到共享存储集群再到分布式分片的完整演进路径。这意味着用户不需要在选型时就做出不可逆的架构决策------业务初期可以用读写分离集群，数据量和并发增长后平滑升级到共享存储集群或分布式集群，底层技术栈保持一致。
KES RAC（共享存储集群）
金仓共享存储集群的核心思想是打破计算与存储的强耦合，所有节点对等，可同时接受读写请求，共同分担负载。通过缓存融合技术，节点间通过高速互联网络直接传递数据块，减少磁盘I/O。配合全局锁管理与事务协调机制，确保跨节点对同一数据块的修改操作保持串行化。
传统模式下，节点A修改了数据页，节点B必须等A写回磁盘后才能从存储上读取最新版本。而在缓存融合模式下，A修改的数据块直接通过高速网络传递到B的内存缓存中，B几乎实时就能看到最新数据，无需经过磁盘中转。这种机制让集群的整体性能接近一台高性能服务器，同时保留了多节点的处理能力。
全局锁管理与事务协调则解决多节点并发写入的一致性问题。当节点A请求写锁时，内核通过节点间同步机制通知其他节点释放相关锁或等待。这种机制确保同一数据块在任何时刻只被一个节点修改，从逻辑上杜绝脏写。
实测数据方面，在基于鲲鹏920处理器与全闪存环境的金融级TPC-C基准测试中，KES RAC 6节点集群达成1,247,800 tpmC的处理能力，平均事务响应时间稳定在8.3ms以内，线性加速比达5.78x。可靠性方面，经国家工业信息安全发展研究中心实测，实现RPO=0、RTO≤15秒，年化可用性达99.999%，支撑某直辖市高级人民法院全业务系统连续无故障运行超1,820天。
在某大型国有银行信用卡核心账务系统升级项目中，采用KES RAC 4节点集群替代原有Oracle RAC集群后，系统完整兼容现有PL/SQL存储过程逻辑与JDBC标准接口，迁移过程未涉及业务代码改造。上线后联机交易TPS由12,400提升至18,600+，日终批处理耗时由217分钟压缩至89分钟，IT基础设施年度运维成本下降37%。
KES读写分离集群
基于流复制技术实现数据同步，主库提供数据共享服务，备库作为备份。守护进程负责检查各库状态并实现自动故障转移，主库故障时备库可在10秒内接管业务。这套方案适合读多写少的业务场景，比如报表查询、历史数据检索，在不显著增加成本的前提下提升读扩展能力。
KES分布式集群（Sharding）
当写入能力成为瓶颈时，KES支持数据分片能力，将数据水平拆分到多个节点，写扩展不再是分布式数据库的专属能力。对于从读写分离集群起步的业务，可以在数据量增长到单机瓶颈时，平滑引入分片能力，而不需要更换数据库产品。
四、选型决策框架
选型之前，先回答两个问题：
业务能接受多长的故障切换时间？ 能接受分钟级恢复，主从复制或读写分离集群可能已够用；要求秒级恢复，选共享存储集群。
业务能接受多大的数据丢失风险？ RPO不为零可以接受，主从复制即可；RPO必须为零，选共享存储集群或原生分布式。
具体决策分三步走。
第一步：判断瓶颈类型。 单机CPU/内存/连接数不够但数据装得下，走集群，加节点或加备机；数据量大到单机装不下、写入吞吐超单机上限，走分布式，拆数据。
第二步：确认第一目标。 怕宕机、要自动切换，选主备/共享存储集群，盯RPO/RTO；要扛海量读写，选主从读写分离（读多）或分片（写多）。
第三步：确认数据是否要拆。 不拆，选主备/主从/共享存储集群；拆，选分片，并准备好接分布式事务、跨分片查询。
| 业务场景 | 推荐路线 | 关键指标 |
|---|---|---|
| 数据量可控、读多写少 | 主从复制/读写分离集群 | RTO分钟级可接受 |
| 核心交易、要求RPO=0 | 共享存储集群（KES RAC） | RTO秒级、RPO=0 |
| 写入瓶颈、数据量持续增长 | 分布式集群（KES Sharding） | 水平扩展、写分散 |
| 信创环境、国产化替代 | 金仓融合集群方案 | 全栈自主可控 |
五、小结
集群与分布式的混淆，代价不仅是架构选型的偏差，更是生产环境中的可用性风险。集群解决高可用与并发压力，分布式解决写入瓶颈与海量数据。选型之前，先厘清业务面临的核心问题是"扛不住"还是"装不下"。金仓KES的融合集群架构从读写分离集群到共享存储集群再到分布式分片，覆盖了从"稳"到"大"的完整演进路径，使得架构选择可以随业务发展逐步演进，而非在初始阶段被迫做出不可逆的决策。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~