1、扩容基础：什么是集群扩容？为什么需要扩容？扩容的常见场景与挑战。

大家好，我是老张。今天咱们聊聊集群扩容。

你想想看，一个系统刚上线时，可能就几台机器。随着业务增长，用户量上来了，数据量也上来了。这时候你会发现，机器扛不住了。怎么办？加机器呗。这就是扩容。

但事情没那么简单。我见过太多团队，扩容就是“加机器、重启、完事”。结果呢？数据分布不均匀，有的节点忙死，有的节点闲死。甚至有的数据直接丢了。嗯，这期课程，咱们就把扩容这件事彻底讲透。

1.1 什么是集群扩容？

集群扩容，说白了就是给系统增加计算或存储资源。目的是提升系统的处理能力，或者增加存储容量。

举个例子。你有一个 Redis 集群，原本 6 个节点。现在数据量涨了，内存快满了。你再加 3 个节点进去，这就是扩容。

扩容通常分两种：

• 垂直扩容：给单台机器加 CPU、加内存、加硬盘。简单粗暴，但有上限。一台机器再牛，也扛不住无限增长。
• 水平扩容：增加机器数量。这是分布式系统的核心能力。理论上可以无限扩展。

我个人习惯把水平扩容再细分成两类：

• 数据分片扩容：比如 Redis Cluster、MongoDB Sharding。数据被切分到不同节点上，扩容后需要重新分配数据。
• 无状态服务扩容：比如 Web 服务、API 网关。加机器就行，不需要关心数据在哪。

咱们这门课，主要讲的是数据分片扩容。因为这才是真正有挑战的地方。

1.2 为什么需要扩容？

这个问题看似简单，但我在面试时发现，很多人其实说不清楚。我总结下来，就三个原因：

1. 容量不足：磁盘快满了，内存不够了。这是最直接的原因。
2. 性能瓶颈：QPS 上不去，响应时间变长。CPU 使用率长期 90%+。
3. 可用性要求：单点故障风险高。需要多节点分担压力，同时提供冗余。

我曾经遇到过一个项目，上线三个月，数据量翻了 10 倍。原本 3 个节点的集群，磁盘使用率飙到 95%。再不扩容，整个系统就要挂了。那是我第一次意识到，扩容不是“锦上添花”，而是“雪中送炭”。

扩容原因	典型表现	扩容方式
容量不足	磁盘使用率 > 80%，写入失败	增加存储节点
性能瓶颈	QPS 上不去，延迟飙升	增加计算节点
可用性要求	单点故障导致服务中断	增加副本节点

1.3 扩容的常见场景

我这些年经历过的扩容场景，少说也有几十次。挑几个典型的说说：

• 电商大促前扩容：双十一前，所有系统都要扩容。这是计划内的，相对好处理。
• 业务爆发式增长：比如某个功能突然火了，用户量暴增。这是计划外的，很考验应急能力。
• 数据迁移/机房搬迁：老机房要下线，数据要搬到新集群。这本质也是一种扩容。
• 故障恢复后扩容：某个节点挂了，恢复后需要重新加入集群。这也算扩容的一种。

1.4 扩容的核心挑战

扩容听起来简单，做起来全是坑。我踩过的坑，能写一本书。这里说几个最常见的：

1.4.1 数据迁移与 Rebalance

这是最大的挑战。你加了新节点，数据不会自动均匀分布。你需要把一部分数据从老节点搬到新节点。这个过程叫 Rebalance。

Rebalance 期间，系统还在对外服务。既要搬数据，又要保证读写正常。这就像给高速飞行的飞机换引擎。稍有不慎，就会出问题。

我曾经在 Rebalance 时，因为迁移速度太快，把网络带宽打满了。结果正常请求超时，用户投诉一片。从那以后，我学会了限速迁移。

1.4.2 数据一致性

迁移过程中，数据可能还在被写入。你搬走的数据，可能下一秒就被修改了。怎么保证最终一致性？这是个难题。

常见的做法是：先全量迁移，再增量同步。最后切流时，需要短暂的只读窗口。嗯，这个窗口时间越短越好。

1.4.3 负载均衡

扩容后，新节点是空的，老节点压力大。如果不做处理，新节点就浪费了。你需要把请求均匀分发到所有节点上。

但问题来了：怎么判断“均匀”？是按请求数？还是按数据量？还是按 CPU 使用率？不同的业务，标准不一样。

1.4.4 扩容对在线服务的影响

扩容不是“加机器、完事”。扩容期间，系统性能会下降。因为迁移数据要消耗 CPU、内存、网络带宽。

我见过一个团队，扩容时没做限流，结果正常请求的延迟从 10ms 涨到 500ms。用户直接炸了。所以，扩容一定要有优雅降级策略。

1.5 扩容的核心流程

我习惯把扩容分成四个阶段。每个阶段都有不同的关注点：

1. 评估阶段：确定扩容规模。加多少节点？加什么配置？
2. 准备阶段：新节点上线。安装软件、加入集群、检查连通性。
3. 迁移阶段：数据 Rebalance。这是最核心的阶段，也是风险最高的阶段。
4. 验证阶段：检查数据一致性、性能指标、负载分布。确认无误后，才算扩容完成。

下面这张图，展示了扩容的核心流程：

1.6 扩容的常见误区

最后，说说我见过的几个常见误区。你对照一下，看看自己有没有中招：

• 误区一：扩容就是加机器。加机器只是第一步。数据怎么分布？流量怎么调度？这些都要考虑。
• 误区二：扩容越快越好。速度快，风险高。我见过有人把迁移速度调到最大，结果网络打满，服务挂了。
• 误区三：扩容后就不用管了。扩容后要持续监控。新节点是否稳定？负载是否均匀？这些都要关注。
• 误区四：所有系统扩容方式一样。不同的系统，扩容方式天差地别。Redis 和 MySQL 的扩容，完全是两码事。