大家好我是数据库小学妹 集群与分布式到底什么区别这个问题是我转行以来被问到最多的技术问题之一。搜了一圈网上的答案要么是两个名词的定义解释要么是厨师配菜师的类比。道理都讲得通但很少有人写过——把这两个概念搞混之后实际要付出什么代价。我把那次教训和后来复盘的思路都写在这里。如果你也在纠结选型或者跟我之前一样以为集群就是分布式这篇文章应该能帮你省点时间。集群与分布式最核心的区别集群是把多台服务器集中在一起做同一件事复制解决单点故障和并发压力分布式是把一个业务拆成不同子任务分布到不同机器上执行拆分解决海量数据和高并发写入。集群是多个人做同一件事分布式是多个人做不同的事。一、一次生产误判主备集群扛不住写压力的根因去年双十一前夜运营部门说流量预计翻三倍。我打开监控一看CPU已经百分之八十五磁盘IOPS打满。第一反应是加机器。当时我们已经搭了一主两备的集群主库写入从库读。看起来挺完美。但大促开始后两小时主库CPU直接飙到百分之百。从库再多也没用因为写压力全在主库上。从库只能分担读写不了。运维同事急坏了“不是分布式吗怎么一台挂了全完”我愣了一下。那个晚上我才意识到一个很蠢的事实我用了三年的分布式根本不是分布式只是集群。集群和分布式这两个词在技术上差了一个量级。混为一谈的代价就是双十一凌晨两点的报警电话。那天晚上紧急限流扛过了峰值。第二天我就开始重新梳理架构。也是那次事故让我明白搞不清集群与分布式的区别不只是考试答错题是真要付出代价的。二、定义集群与分布式到底什么区别是一回事吗痛定思痛我花了一周时间把这两个概念从底层捋了一遍。很多人问集群和分布式是一回事吗答案是否定的。它们解决的是完全不同的问题。集群Cluster是把多台服务器集中在一起实现同一个业务。每台机器跑一样的程序提供一样的服务。核心是复制解决的是单点故障和并发压力。像Oracle RAC和KingbaseES RAC这类共享存储集群方案就属于集群架构中的高配形态。分布式Distributed是把一个业务拆成不同的子业务分布到不同的机器上执行。每台机器干不同的活通过网络协同。核心是拆分解决的是海量数据和超高并发写入。一个很直观的例子。集群就像三个厨师炒同样的菜前面的调度员决定把客人的单子派给谁。三个厨师能力一样谁闲着谁接单。一个厨师请假了另外两个顶上。分布式是后厨分工。有人切菜有人配菜有人炒菜有人摆盘。每个人只干一件事但组合起来才能出一盘完整的菜。切菜的忙不过来加配菜师没用必须再加一个切菜的。所以集群与分布式最本质的区别就一句话集群是同一个人干同一件事的多份拷贝分布式是不同的人干不同的事协同完成。三、对比一张表看懂集群与分布式的差异对比维度集群Cluster分布式Distributed核心思想复制相同服务“多个人做同一件事”拆分不同功能“多个人做不同的事”节点功能所有节点运行相同的程序每个节点负责不同的子任务数据存放共享同一份数据或主从同步数据物理分片分散存储在不同节点解决问题单点故障、读并发压力海量数据存储、超高并发写入一致性保障相对容易主从复制或共享存储复杂需要分布式事务和共识协议扩展方式横向加节点简单直接需要数据重平衡复杂度高运维成本低监控调优成熟高跨节点排查困难典型场景数据库主备、Web服务器负载均衡分库分表、微服务、海量数据处理四、深入数据库集群和分布式区别到底在哪光讲概念没用落到数据库上才见真章。数据库集群和分布式区别不仅体现在部署形态上更体现在数据一致性、事务处理和扩展方式上。集群的数据库主从复制的甜蜜与苦涩集群在数据库里的典型形态是主备架构。主库负责写入从库通过WAL日志复制同步数据提供读服务。读写分离听起来很美但写压力始终集中在主库这一个点上。我遇到过一个问题。主库写入量上来以后WAL日志量暴涨从库的复制线程追不上主库了。主从延迟从几毫秒变成了十几秒。这时候从库读到的数据是旧的。报表跑出来的数字和业务系统里的对不上。财务部门拿着两张表来找我说数据有问题。这就是集群架构天然的天花板。-- 查看主从复制延迟SELECTclient_addr,state,sent_lsn,write_lsn,replay_lsn,EXTRACT(EPOCHFROM(now()-replay_lag))ASlag_secondsFROMpg_stat_replication;复制延迟是主备集群的顽疾。增加从库数量只会让主库的同步压力更大不会让延迟变小。解决这个问题的方向只有一个把写压力也分散掉。但主备架构做不了这件事。这也是为什么一些企业在主备集群跑了一段时间后开始关注像KES共享存储集群这样能真正分散写压力的方案。分布式的数据库分片存储的得与失分布式数据库的做法完全不同。数据被水平切分成多个分片Shard每个分片存储在不同的节点上。写入时系统根据分片规则定位到对应节点只操作那一部分数据。这样一来写压力被分散到了多个节点上。不再像主备集群那样所有写操作挤在一个主库里排队。但分布式也带来了新的麻烦。第一个麻烦是分布式事务。一个事务如果跨了两个分片怎么保证要么全成功要么全失败集中式数据库一条COMMIT就完事分布式环境需要考虑两阶段提交2PC、TCC补偿、或者Paxos/Raft共识协议。第二个麻烦是跨分片查询。用户要查的数据分在三个不同的节点上你得像拼图一样把结果拼回来。JOIN操作在分布式环境下性能损耗很大这就是为什么很多分布式数据库不擅长复杂关联查询。第三个麻烦是数据重平衡。某个分片数据量暴涨需要把一部分数据迁移到其他节点。迁移过程中还要保证服务不中断这操作起来非常精细。-- 分片后的查询示例按user_id取模路由-- 应用层需要先计算分片键再路由到对应节点-- SELECT * FROM orders WHERE user_id 10086;-- user_id % 4 2 → 路由到shard_2节点执行我在实际项目里做过分库分表。按用户ID取模分成四个库。前期跑得挺好后来发现有个大客户的订单量占了总量的百分之三十那个分片又成了热点。分片策略选错了分布式还不如集群。五、实战当集群扛不住时我看到的三种演进路线从主备集群到分布式不是只有一条路。路线一分库分表中间件在应用和数据库之间加一层中间件比如ShardingSphere。由中间件负责SQL解析、路由和结果归并。优点是成本低基于现有的MySQL就能做。缺点是跨库JOIN能力有限复杂查询性能差运维多了一套中间件要管。适合业务拆分清晰、跨库关联查询少的场景。路线二原生分布式数据库数据库内核原生支持分布式比如TiDB、OceanBase。应用端看起来像连了一个普通数据库底层的分片、路由、事务全部由数据库自己处理。优点是对应用透明弹性伸缩能力强。缺点是架构复杂DBA的学习曲线陡峭。出了问题排查起来比传统数据库难得多。路线三共享存储集群多节点共享同一份存储节点之间通过高速网络互联。代表方案有Oracle RAC和KingbaseES RAC。优点是强一致性有保障不需要数据分片。这条路线在金融核心系统这种数据绝对不能错的场景特别受欢迎。KingbaseES RAC方案在此基础上实现了故障切换时RPO0RTO小于十秒满足金融级连续性指标。补充集群与分布式和微服务的关系很多人会把微服务和分布式混为一谈。它们有关系但不是同一个概念。微服务是一种架构风格把大型应用拆成多个独立部署、松耦合的小服务。分布式是一种部署方式强调任务在多个节点上执行。集群与分布式和微服务三者可以这样理解先按微服务拆分业务分布式再给每个微服务部署多份实例集群。好的架构设计是先分布式再集群业务拆成子服务后每个子服务单独做集群部署。六、案例KingbaseES的集中分布一体化思路之前去一个客户现场调研他们的架构师说了一个很实在的痛点最怕的不是选型是选错了回头重来。很多数据库的集中式和分布式是两套产品选了就回不了头。业务初期数据量不大上了集中式。后面业务涨了想换分布式得迁移数据、改应用代码、换运维工具代价太大。KES在集群与分布式这件事上的思路挺务实。它没有把集中式和分布式做成两个产品而是单一数据库内核原生同时支持集中式与分布式两种部署形态。官方叫集中分布一体化。具体来说它提供了两条腿走路的能力共享存储集群模式对应KES RAC。多节点共享存储实现真正的读写分离和高可用。故障切换时RPO0RTO小于十秒。这个指标在金融核心系统里是硬指标。适合对一致性要求极高的OLTP场景。分布式集群模式。数据分片存储在多个节点上计算与存储分离。可以在不中断业务的情况下通过增加节点线性提升存储容量和计算能力。适合数据量突破TB级、需要弹性伸缩的场景。同一个数据库产品同一套SQL语法同一套运维工具。前期用集中式集群跑着后面业务涨了按需扩展到分布式集群。数据库不用换应用代码不需要重构。这对业务连续性要求高的行业来说是关键的安全感。我还注意到一个细节。KES的分布式方案支持国产化全栈适配从飞腾、鲲鹏、海光芯片到统信、麒麟操作系统都能跑。对于有等保三级合规要求的客户分布式集群同样支持国密算法加密和细粒度访问控制。信创环境下的集群与分布式选型这个维度是很多人容易忽略的。七、决策到底选集群还是分布式回到最实际的问题。怎么选什么时候用集群就够了数据量在单机或主备可承载范围比如几百GB到几TB。并发量几千QPS索引优化好完全够用。业务逻辑复杂跨表关联多上了分布式查询反而更慢。团队规模小DBA资源紧张运维分布式比运维单机累多了。这时候别折腾。把索引优化好、查询优化好、读写分离做好集中式的天花板比你想象的高得多。像KES这类支持集中式与分布式双形态的数据库完全可以先从集中式起步后面按需再扩展。什么时候必须上分布式数据量超过十TB且持续增长。高并发写入比如物联网日志、互联网交易。需要跨地域部署对高可用和容灾有硬性要求。业务增长不可预测需要随时能扩容。三个注意要点第一不要为了技术潮流上分布式。我见过有团队上了分布式之后DBA从两个变成了五个。不是因为业务涨了是因为排查问题变难了。一个慢查询可能跨了三个节点光是定位问题就要查三套日志。第二分片策略比分片本身更重要。分片键选错了数据分布不均匀热点节点又成了瓶颈。前面提到的大客户订单量占百分之三十的教训就是分片键没选对。选分片键之前先把你的查询模式和访问热力图看清楚。第三集群和分布式不是二选一而是可以结合。好的设计是先分布式再集群。业务拆分成不同的子服务分布式每个子服务单独做集群部署。这样单个子服务出问题不影响全局同时每个子服务自身也有高可用保障。八、常见问题集群和分布式是一回事吗?不是一回事。集群是多台服务器做同一件事解决高可用和并发压力分布式是把业务拆分到不同机器上执行解决海量数据和高并发写入。两者可以结合使用但概念完全不同。数据库集群和分布式区别在哪里?数据库集群通常是主备或共享存储架构数据集中存放写压力集中在主节点分布式数据库将数据水平分片存储在不同节点上写压力分散。集群的一致性容易保障分布式需要处理分布式事务和跨分片查询。先集群还是先分布式?建议先集群后分布式。业务初期用集中式集群跑着保证数据一致性和运维简单性。当数据量突破TB级、并发量持续上涨时再评估是否需要分布式分片。像KES这类支持集中分布一体化的数据库可以在同一套内核上渐进式演进不用一开始就选死路线。集群和分布式能同时用吗?可以。实际项目中最常见的架构是先分布式再集群业务按功能拆成不同子服务分布式每个子服务单独部署多份实例做高可用集群。这样单个子服务出问题不影响全局同时每个子服务自身也有故障切换能力。九、总结折腾了这么久我对集群与分布式就总结了四句话集群解决活下来的问题。高可用、负载均衡、故障切换。大多数企业现在的数据量集群完全够用。分布式解决跑得快、存得下的问题。海量数据、超高并发、弹性伸缩。但代价是运维复杂度和事务一致性成本。架构选型没有标准答案。关键是搞清楚自己的数据规模、查询模式和高可用需求。选之前想清楚我需要什么比知道市场上有什么重要得多。KES的集中分布一体化给了企业一个渐进式选项。从共享存储集群起步按需扩展到分布式集群。不用一开始就把整个架构推到重来也不用选错了回头换产品。这种渐进式演进路径对大多数企业来说比一步到位上分布式要稳妥得多。如果你也在纠结集群与分布式怎么选或者已经在搞了遇到什么坑欢迎在评论区聊聊你的经验。我是数据库小学妹咱们下篇见
集群与分布式区别详解：主备集群天花板与分布式分片实战
发布时间：2026/7/20 18:39:14
大家好我是数据库小学妹 集群与分布式到底什么区别这个问题是我转行以来被问到最多的技术问题之一。搜了一圈网上的答案要么是两个名词的定义解释要么是厨师配菜师的类比。道理都讲得通但很少有人写过——把这两个概念搞混之后实际要付出什么代价。我把那次教训和后来复盘的思路都写在这里。如果你也在纠结选型或者跟我之前一样以为集群就是分布式这篇文章应该能帮你省点时间。集群与分布式最核心的区别集群是把多台服务器集中在一起做同一件事复制解决单点故障和并发压力分布式是把一个业务拆成不同子任务分布到不同机器上执行拆分解决海量数据和高并发写入。集群是多个人做同一件事分布式是多个人做不同的事。一、一次生产误判主备集群扛不住写压力的根因去年双十一前夜运营部门说流量预计翻三倍。我打开监控一看CPU已经百分之八十五磁盘IOPS打满。第一反应是加机器。当时我们已经搭了一主两备的集群主库写入从库读。看起来挺完美。但大促开始后两小时主库CPU直接飙到百分之百。从库再多也没用因为写压力全在主库上。从库只能分担读写不了。运维同事急坏了“不是分布式吗怎么一台挂了全完”我愣了一下。那个晚上我才意识到一个很蠢的事实我用了三年的分布式根本不是分布式只是集群。集群和分布式这两个词在技术上差了一个量级。混为一谈的代价就是双十一凌晨两点的报警电话。那天晚上紧急限流扛过了峰值。第二天我就开始重新梳理架构。也是那次事故让我明白搞不清集群与分布式的区别不只是考试答错题是真要付出代价的。二、定义集群与分布式到底什么区别是一回事吗痛定思痛我花了一周时间把这两个概念从底层捋了一遍。很多人问集群和分布式是一回事吗答案是否定的。它们解决的是完全不同的问题。集群Cluster是把多台服务器集中在一起实现同一个业务。每台机器跑一样的程序提供一样的服务。核心是复制解决的是单点故障和并发压力。像Oracle RAC和KingbaseES RAC这类共享存储集群方案就属于集群架构中的高配形态。分布式Distributed是把一个业务拆成不同的子业务分布到不同的机器上执行。每台机器干不同的活通过网络协同。核心是拆分解决的是海量数据和超高并发写入。一个很直观的例子。集群就像三个厨师炒同样的菜前面的调度员决定把客人的单子派给谁。三个厨师能力一样谁闲着谁接单。一个厨师请假了另外两个顶上。分布式是后厨分工。有人切菜有人配菜有人炒菜有人摆盘。每个人只干一件事但组合起来才能出一盘完整的菜。切菜的忙不过来加配菜师没用必须再加一个切菜的。所以集群与分布式最本质的区别就一句话集群是同一个人干同一件事的多份拷贝分布式是不同的人干不同的事协同完成。三、对比一张表看懂集群与分布式的差异对比维度集群Cluster分布式Distributed核心思想复制相同服务“多个人做同一件事”拆分不同功能“多个人做不同的事”节点功能所有节点运行相同的程序每个节点负责不同的子任务数据存放共享同一份数据或主从同步数据物理分片分散存储在不同节点解决问题单点故障、读并发压力海量数据存储、超高并发写入一致性保障相对容易主从复制或共享存储复杂需要分布式事务和共识协议扩展方式横向加节点简单直接需要数据重平衡复杂度高运维成本低监控调优成熟高跨节点排查困难典型场景数据库主备、Web服务器负载均衡分库分表、微服务、海量数据处理四、深入数据库集群和分布式区别到底在哪光讲概念没用落到数据库上才见真章。数据库集群和分布式区别不仅体现在部署形态上更体现在数据一致性、事务处理和扩展方式上。集群的数据库主从复制的甜蜜与苦涩集群在数据库里的典型形态是主备架构。主库负责写入从库通过WAL日志复制同步数据提供读服务。读写分离听起来很美但写压力始终集中在主库这一个点上。我遇到过一个问题。主库写入量上来以后WAL日志量暴涨从库的复制线程追不上主库了。主从延迟从几毫秒变成了十几秒。这时候从库读到的数据是旧的。报表跑出来的数字和业务系统里的对不上。财务部门拿着两张表来找我说数据有问题。这就是集群架构天然的天花板。-- 查看主从复制延迟SELECTclient_addr,state,sent_lsn,write_lsn,replay_lsn,EXTRACT(EPOCHFROM(now()-replay_lag))ASlag_secondsFROMpg_stat_replication;复制延迟是主备集群的顽疾。增加从库数量只会让主库的同步压力更大不会让延迟变小。解决这个问题的方向只有一个把写压力也分散掉。但主备架构做不了这件事。这也是为什么一些企业在主备集群跑了一段时间后开始关注像KES共享存储集群这样能真正分散写压力的方案。分布式的数据库分片存储的得与失分布式数据库的做法完全不同。数据被水平切分成多个分片Shard每个分片存储在不同的节点上。写入时系统根据分片规则定位到对应节点只操作那一部分数据。这样一来写压力被分散到了多个节点上。不再像主备集群那样所有写操作挤在一个主库里排队。但分布式也带来了新的麻烦。第一个麻烦是分布式事务。一个事务如果跨了两个分片怎么保证要么全成功要么全失败集中式数据库一条COMMIT就完事分布式环境需要考虑两阶段提交2PC、TCC补偿、或者Paxos/Raft共识协议。第二个麻烦是跨分片查询。用户要查的数据分在三个不同的节点上你得像拼图一样把结果拼回来。JOIN操作在分布式环境下性能损耗很大这就是为什么很多分布式数据库不擅长复杂关联查询。第三个麻烦是数据重平衡。某个分片数据量暴涨需要把一部分数据迁移到其他节点。迁移过程中还要保证服务不中断这操作起来非常精细。-- 分片后的查询示例按user_id取模路由-- 应用层需要先计算分片键再路由到对应节点-- SELECT * FROM orders WHERE user_id 10086;-- user_id % 4 2 → 路由到shard_2节点执行我在实际项目里做过分库分表。按用户ID取模分成四个库。前期跑得挺好后来发现有个大客户的订单量占了总量的百分之三十那个分片又成了热点。分片策略选错了分布式还不如集群。五、实战当集群扛不住时我看到的三种演进路线从主备集群到分布式不是只有一条路。路线一分库分表中间件在应用和数据库之间加一层中间件比如ShardingSphere。由中间件负责SQL解析、路由和结果归并。优点是成本低基于现有的MySQL就能做。缺点是跨库JOIN能力有限复杂查询性能差运维多了一套中间件要管。适合业务拆分清晰、跨库关联查询少的场景。路线二原生分布式数据库数据库内核原生支持分布式比如TiDB、OceanBase。应用端看起来像连了一个普通数据库底层的分片、路由、事务全部由数据库自己处理。优点是对应用透明弹性伸缩能力强。缺点是架构复杂DBA的学习曲线陡峭。出了问题排查起来比传统数据库难得多。路线三共享存储集群多节点共享同一份存储节点之间通过高速网络互联。代表方案有Oracle RAC和KingbaseES RAC。优点是强一致性有保障不需要数据分片。这条路线在金融核心系统这种数据绝对不能错的场景特别受欢迎。KingbaseES RAC方案在此基础上实现了故障切换时RPO0RTO小于十秒满足金融级连续性指标。补充集群与分布式和微服务的关系很多人会把微服务和分布式混为一谈。它们有关系但不是同一个概念。微服务是一种架构风格把大型应用拆成多个独立部署、松耦合的小服务。分布式是一种部署方式强调任务在多个节点上执行。集群与分布式和微服务三者可以这样理解先按微服务拆分业务分布式再给每个微服务部署多份实例集群。好的架构设计是先分布式再集群业务拆成子服务后每个子服务单独做集群部署。六、案例KingbaseES的集中分布一体化思路之前去一个客户现场调研他们的架构师说了一个很实在的痛点最怕的不是选型是选错了回头重来。很多数据库的集中式和分布式是两套产品选了就回不了头。业务初期数据量不大上了集中式。后面业务涨了想换分布式得迁移数据、改应用代码、换运维工具代价太大。KES在集群与分布式这件事上的思路挺务实。它没有把集中式和分布式做成两个产品而是单一数据库内核原生同时支持集中式与分布式两种部署形态。官方叫集中分布一体化。具体来说它提供了两条腿走路的能力共享存储集群模式对应KES RAC。多节点共享存储实现真正的读写分离和高可用。故障切换时RPO0RTO小于十秒。这个指标在金融核心系统里是硬指标。适合对一致性要求极高的OLTP场景。分布式集群模式。数据分片存储在多个节点上计算与存储分离。可以在不中断业务的情况下通过增加节点线性提升存储容量和计算能力。适合数据量突破TB级、需要弹性伸缩的场景。同一个数据库产品同一套SQL语法同一套运维工具。前期用集中式集群跑着后面业务涨了按需扩展到分布式集群。数据库不用换应用代码不需要重构。这对业务连续性要求高的行业来说是关键的安全感。我还注意到一个细节。KES的分布式方案支持国产化全栈适配从飞腾、鲲鹏、海光芯片到统信、麒麟操作系统都能跑。对于有等保三级合规要求的客户分布式集群同样支持国密算法加密和细粒度访问控制。信创环境下的集群与分布式选型这个维度是很多人容易忽略的。七、决策到底选集群还是分布式回到最实际的问题。怎么选什么时候用集群就够了数据量在单机或主备可承载范围比如几百GB到几TB。并发量几千QPS索引优化好完全够用。业务逻辑复杂跨表关联多上了分布式查询反而更慢。团队规模小DBA资源紧张运维分布式比运维单机累多了。这时候别折腾。把索引优化好、查询优化好、读写分离做好集中式的天花板比你想象的高得多。像KES这类支持集中式与分布式双形态的数据库完全可以先从集中式起步后面按需再扩展。什么时候必须上分布式数据量超过十TB且持续增长。高并发写入比如物联网日志、互联网交易。需要跨地域部署对高可用和容灾有硬性要求。业务增长不可预测需要随时能扩容。三个注意要点第一不要为了技术潮流上分布式。我见过有团队上了分布式之后DBA从两个变成了五个。不是因为业务涨了是因为排查问题变难了。一个慢查询可能跨了三个节点光是定位问题就要查三套日志。第二分片策略比分片本身更重要。分片键选错了数据分布不均匀热点节点又成了瓶颈。前面提到的大客户订单量占百分之三十的教训就是分片键没选对。选分片键之前先把你的查询模式和访问热力图看清楚。第三集群和分布式不是二选一而是可以结合。好的设计是先分布式再集群。业务拆分成不同的子服务分布式每个子服务单独做集群部署。这样单个子服务出问题不影响全局同时每个子服务自身也有高可用保障。八、常见问题集群和分布式是一回事吗?不是一回事。集群是多台服务器做同一件事解决高可用和并发压力分布式是把业务拆分到不同机器上执行解决海量数据和高并发写入。两者可以结合使用但概念完全不同。数据库集群和分布式区别在哪里?数据库集群通常是主备或共享存储架构数据集中存放写压力集中在主节点分布式数据库将数据水平分片存储在不同节点上写压力分散。集群的一致性容易保障分布式需要处理分布式事务和跨分片查询。先集群还是先分布式?建议先集群后分布式。业务初期用集中式集群跑着保证数据一致性和运维简单性。当数据量突破TB级、并发量持续上涨时再评估是否需要分布式分片。像KES这类支持集中分布一体化的数据库可以在同一套内核上渐进式演进不用一开始就选死路线。集群和分布式能同时用吗?可以。实际项目中最常见的架构是先分布式再集群业务按功能拆成不同子服务分布式每个子服务单独部署多份实例做高可用集群。这样单个子服务出问题不影响全局同时每个子服务自身也有故障切换能力。九、总结折腾了这么久我对集群与分布式就总结了四句话集群解决活下来的问题。高可用、负载均衡、故障切换。大多数企业现在的数据量集群完全够用。分布式解决跑得快、存得下的问题。海量数据、超高并发、弹性伸缩。但代价是运维复杂度和事务一致性成本。架构选型没有标准答案。关键是搞清楚自己的数据规模、查询模式和高可用需求。选之前想清楚我需要什么比知道市场上有什么重要得多。KES的集中分布一体化给了企业一个渐进式选项。从共享存储集群起步按需扩展到分布式集群。不用一开始就把整个架构推到重来也不用选错了回头换产品。这种渐进式演进路径对大多数企业来说比一步到位上分布式要稳妥得多。如果你也在纠结集群与分布式怎么选或者已经在搞了遇到什么坑欢迎在评论区聊聊你的经验。我是数据库小学妹咱们下篇见
