📌今日关键词：分布式集群、分布式、集群、分库分表、数据一致性
大家好，我是数据库小学妹 👋
最近帮一个客户做数据库架构评审。提交上来的方案里写了一大段"部署分布式集群"。问他分片策略和节点冗余分别是怎么考虑的，答不上来。
这种情况我见过很多次了。分布式和集群这两个词经常被混在一起说。但它们解决的问题完全不同。搞不清楚区别就写方案，架构评审基本过不了。
前段时间参与了两次数据库架构升级。从选型到落地踩了不少坑。今天把分布式、集群、分布式集群这几个概念理清楚。顺便聊聊数据库场景下怎么选。
先把结论放前面。集群是多台机器做同一件事，解决高可用问题。分布式是多台机器分工做不同事，解决性能瓶颈问题。分布式集群是两者结合，先分工再给每个岗位配多台机器。
下面展开讲。
先搞清楚：分布式和集群是两件事
很多人把分布式和集群当同义词用。其实它们解决的是完全不同的问题。
集群的思路是"一群人做同一件事"。
打个比方，一家饭店生意忙不过来了，老板又招了两个厨师。三个厨师在三个灶台上炒一样的菜，谁手空了谁接单。这就是集群——多台服务器跑同一套服务。前面放个负载均衡器，把请求轮流分给不同服务器。
集群解决的是单点挂掉、服务中断的问题。一台机器崩了，另外两台顶上，用户没感觉。
分布式的思路是"每个人只干一件事"。
还是那家饭店。老板发现光加厨师也不行。厨师要炒菜又要切菜还要出餐，再快也快不过来。于是重新分工。专门找一个人切菜，一个人出餐，厨师只管炒菜。流水线跑起来，效率翻了好几倍。
分布式就是把一个完整业务拆成好几个子业务。每个子业务独立跑在不同的服务器上，通过接口互相配合。
换句话说：集群是加人干一样的活。分布式是分工干不同的活。
分布式集群：把两者叠在一起
概念分清楚了，但实际项目里它们往往是混在一起用的。
先拆开业务（分布式），再给每个岗位加人（集群），就是分布式集群。
饭店里，切菜这个岗位有3个人同时在干，出餐有2个人，炒菜有4个人。每个岗位内部是集群，岗位之间是分布式。业务拆开了，每个模块还不止一台机器在跑。
为什么非得这么搞？
我之前接触过一个项目，最初只有集群。多台机器跑同一套服务。后来业务量上来了，单套服务的代码太复杂。性能优化到头了，只能把业务拆开。拆完之后又发现某个模块压力太大。一台机器顶不住，又得加机器做集群。最后自然演变成了分布式集群。
只分不加人，某个环节还是会卡。只加人不分，机器越多越乱。分布式集群是同时解决"怎么拆"和"怎么扛"的问题。
回到数据库：分布式集群到底怎么用
说概念容易，落地到数据库才是真正的考验。
先放一张对比表，把四种架构放在一起看。
| 架构模式 | 核心思路 | 解决的问题 | 适合的场景 | 运维复杂度 |
|---|---|---|---|---|
| 单机 | 一台机器干所有事 | 简单场景 | 个人博客、内部工具 | 低 |
| 集群 | 多台机器干同一件事 | 高可用、负载分担 | Web服务、读写分离 | 中 |
| 分布式 | 多台机器分工干不同事 | 性能瓶颈、业务拆解 | 分库分表、微服务 | 高 |
| 分布式集群 | 分工 + 每个岗位多台机器 | 性能 + 高可用 | 电商订单、金融核心数据库 | 很高 |
这几个概念在数据库场景下特别明显。
单机数据库，所有数据存在一台机器上。数据量小的时候没问题，几千条记录毫秒级查询。但换成订单表，几亿条记录全塞在一台机器上，写入会越来越慢。查询也跟着变慢。更要命的是，这台机器宕机了，整个系统就瘫了。
分布式集群数据库分两步解决这些问题。
第一步，把数据拆开。一张订单表太大，按用户ID拆成100份，分别存在100个节点上。查某个用户的订单，直接定位到对应节点，不用全表扫描。这叫分库分表，是分布式思路。
第二步，给每份数据做备份。每份订单数据同时存3个副本，分别在不同服务器上。主节点负责写入，从节点负责读取。一台机器坏了，另外两份副本还在，数据不会丢。这叫多副本，是集群思路。
两步合起来，就是分布式集群数据库。MySQL主从+分库、金仓KES的集群+分布式扩展，走的都是这条路子。
真要落地：这几个技术点得搞明白
概念好懂，真动手的时候全是坑。我在参与数据库迁移的时候踩过不少，说几个关键的。
数据怎么拆——分片策略
两种主流方案：哈希分片是把用户ID取模，均匀打散到各个节点上。范围分片是按时间或ID区间来切。比如1月的数据放节点A，2月的放节点B。
我们当时选了哈希分片。结果上线后发现有几个月的热点数据访问量特别大。哈希分片没法把它们聚在一起。某个节点忙得要死，其他节点很闲。后来改成混合方案才好一些。分片策略选错了，后面改起来很痛苦。
这里提一个思路。如果业务量还没到必须分库分表的程度。可以先考虑数据库本身的集群能力。比如金仓KES，支持一主多从的集群部署。读请求分发到从节点，写请求走主节点。很多场景下，读写分离加集群就能扛住。不用一上来就搞分库分表。
数据同步——一致性问题
分布式环境下，节点之间数据同步是个大麻烦。
强一致性要求所有节点写完才算成功，数据绝对准确，但性能差。最终一致性允许短暂延迟，节点之间慢慢同步，性能好。但某个瞬间不同节点看到的数据可能不一样。
银行转账当然要强一致性，少一分钱都不行。社交APP的点赞数用最终一致性就够了，晚两秒看到也没啥影响。
在数据库集群层面，一致性靠同步复制来保证。KES支持同步和异步两种复制模式。同步模式下，主节点写完必须等从节点确认才返回成功。数据零丢失，但性能会受一点影响。异步模式性能好，但极端情况下可能丢少量数据。具体选哪种，看业务对数据安全的要求。
请求分发——负载均衡
用户请求来了，分给哪个节点？最简单的是轮询，按顺序轮流分配。聪明一点的是最少连接，谁当前最闲就给谁。还有一致性哈希算法，能让同一用户的请求总落到同一节点上。适合有状态的服务。
机器挂了——故障转移
分布式集群得有个健康检查机制，定期探测每个节点的状态。一旦发现某台机器没响应，马上把请求切到正常节点上。用户基本感觉不到中断。
KES的集群方案内置了这个能力。自动检测节点心跳。故障发生时自动提升从节点为主节点。不用人工干预。切换过程对应用透明。
分布式集群不是万能药
这个坑我也踩过。
当时觉得上了分布式集群就万事大吉了。结果发现运维复杂度直接翻了好几倍。跨节点查询比单机查询慢。分布式事务比单机事务难处理得多。监控告警的配置工作量也很大。
我之前那个项目迁完分布式集群之后。DBA团队从3个人扩到了8个人。光是监控告警就搞了两个月。
不过工具选对了，运维复杂度能降不少。KES有配套的KEMCC统一管控平台。安装部署、监控告警、备份恢复、性能诊断都在一个界面上管理。不是加集群就得加人。
数据量还没到单机扛不住的时候，别急着上分布式集群。先用集群做读写分离。够用了就不要往上加复杂度。先搞清楚自己的业务瓶颈在哪，再决定上什么架构。
避坑清单
分布式和集群要分开理解。集群是多个节点做同一件事，解决高可用。分布式是多个节点分工做不同事，解决性能瓶颈。分布式集群是两者结合，别混为一谈。
分片策略选型要慎重。哈希分片和范围分片各有适用场景。选错了后面改起来代价很大。混合方案在很多场景下更实用。
一致性方案按业务选。不是所有场景都需要强一致性。大部分互联网业务用最终一致性就够了。强一致性的性能代价要考虑清楚。
没到瓶颈别上分布式集群。运维复杂度、监控成本、团队能力都要评估。能用集群解决的先用集群。国产数据库里，KES这类产品本身就有成熟的集群方案。先把这些用好，再考虑更复杂的架构。
做好故障转移和监控。分布式集群节点多，故障概率也高。健康检查、自动切换、告警这些基础设施要先搭好。不能等出了问题再补。
架构是为业务服务的。先搞清楚瓶颈在哪。再决定上什么架构。不要反过来为了用某个技术而硬上。
最后说一个实际案例。某大型运营商的核心业务系统，连接31个省。用KES部署了多套高可用集群。可用性跑到99.999%，故障切换在30秒以内。集群方案不是纸上谈兵，是真跑出来的。
KES这类国产数据库的优势在于，集群和分布式扩展用的是同一套内核。不用在不同产品之间来回切换。从读写分离到分库分表，一套方案能覆盖大多数场景。加上配套的管控平台，运维成本也能控住。
你们团队目前用的什么架构？遇到过分布式和集群搞混的情况吗？评论区聊聊。
我是数据库小学妹，咱们下篇见 👋
