当业务流量快速增长，单机或小规模集群已无法支撑并发压力时，运维侧往往会执行一次大规模扩容，将节点数量从几十台提升到上百台甚至更多。新节点加入集群后若立即承接线上流量，其本地缓存与分布式缓存均为空，大量请求会穿透到后端数据库或下游服务，造成连接数暴涨、响应延迟陡增，严重时引发连锁雪崩。因此必须在新节点正式上线前，设计一套完整的预热与缓存加载方案，让热点数据提前就位。
预热时机的选择与架构分层
预热并不是简单地在启动脚本里加几行读取数据的代码，而是要根据集群架构明确是在哪一层做加载。常见的缓存架构分为本地缓存（如 Caffeine、Guava Cache）、分布式缓存（如 Redis 集群）以及基于 CDN 的静态资源缓存。大规模扩容时，如果只预热本地缓存，新节点启动后仍然会打到分布式缓存，而分布式缓存如果也是新建的，则依旧回源。因此合理的做法是先确保分布式缓存已有全量或热点数据，再让新节点从分布式缓存拉取并构建本地缓存。
从时机上看，预热可以分为离线预热和在线渐进预热。离线预热是在扩容量产之前，通过单独的数据构建任务把待加载的键值对序列化为文件或数据库表，新节点启动后直接读取这些产物。在线渐进预热则是新节点以低权重接入流量，同时后台线程按访问频次异步加载。对于电商大促前的扩容，通常采用离线预热加灰度放量的组合，既保证数据完整性，又避免启动初期资源争抢。
在 Kubernetes 环境中，还可以利用 Init Container 完成缓存加载，主容器启动前 Init Container 已把热数据写入挂载的空 Redis 实例或本地磁盘。这种方式的优势是生命周期清晰，不会污染主进程逻辑，但也要求 Init 阶段能拿到稳定的数据源连接，否则会阻塞 Pod 就绪。
基于分片与消息队列的加载实现
当集群规模较大时，让上百个节点同时全量加载所有缓存项会造成网络与数据库双重瓶颈。更优的思路是按数据分片，将 Key 空间划分为若干区间，每个新节点只负责加载属于自己的分片。例如用户 ID 取模后分配到不同节点，预热任务根据分片规则生成对应子集，这样单节点加载量降到原来的 N 分之一。
具体实现中可以引入消息队列解耦加载指令的下发。扩容控制器在节点注册到集群后，向特定 Topic 发送加载任务消息，消息体包含分片起始值、结束值以及数据源地址。消费者即新节点收到后启动多线程拉取，完成后上报状态。下面给出一个简化的 Java 消费与加载示例：
// 新节点收到分片加载消息后执行
public void handleWarmUpMessage(WarmUpMsg msg) {
int start = msg.getStartShard();
int end = msg.getEndShard();
ExecutorService pool = Executors.newFixedThreadPool(8);
for (int shard = start; shard <= end; shard++) {
pool.submit(() -> {
List<String> keys = shardService.listKeys(shard);
for (String k : keys) {
String v = remoteDao.get(k);
cacheClient.set(k, v, 300); // 5分钟过期
}
});
}
pool.shutdown();
}
使用消息队列的好处是扩容节奏可控，如果某个节点加载失败，只需要重发该分片消息即可，不需要全部重来。不过这也引入了 MQ 的运维成本，并且在网络分区时需考虑消息重复消费导致的重复加载，应在加载逻辑中加入幂等判断，比如利用分布式锁或数据库唯一约束。
避免集中失效与资源争抢的策略
预热完成并不意味着高枕无忧。如果所有缓存项设置了相同的过期时间，那么在扩容后某个时间点会出现集体失效，再次引发回源峰值。解决办法是为不同业务维度的数据设置带有随机抖动的过期时间，比如基础过期 300 秒，附加 0 到 60 秒的随机值，将失效曲线拉平。
另一个容易被忽视的问题是加载期间的资源争抢。新节点在预热时会占用大量 CPU 与带宽，如果此时旧节点也在处理正常流量，可能引发整个集群的响应变慢。应当通过限流手段约束单节点预热并发数，并在监控系统里对预热流量打上独立标签，方便与业务流量区分。以下配置示例展示如何用令牌桶限制预热线程每秒请求数：
import time
class TokenBucket:
def __init__(self, rate, capacity):
self.rate = rate
self.capacity = capacity
self.tokens = capacity
self.last = time.time()
def acquire(self):
now = time.time()
self.tokens += (now - self.last) * self.rate
if self.tokens > self.capacity:
self.tokens = self.capacity
self.last = now
if self.tokens >= 1:
self.tokens -= 1
return True
return False
bucket = TokenBucket(100, 200)
def load_key(k):
if bucket.acquire():
# 执行缓存加载
pass
else:
time.sleep(0.01)
此外，对于读取极其频繁且构建成本极高的热键，可考虑在旧节点上开启主动复制，当新节点上线时由旧节点推送 top N 热键，而不是让新节点重新计算。这种方案能进一步压缩预热时间，但需要旧节点具备识别热键并安全序列化的能力，适合稳定性要求极高的金融或交易系统。
验证预热效果与回滚机制
方案上线前应在灰度环境模拟同等扩容倍数，观察新节点就绪后缓存命中率是否达到预期阈值，比如本地缓存命中率高于百分之八十五，分布式缓存命中率高于百分之九十五。若命中率过低，说明分片规则或数据源选取有问题，需调整预热包生成逻辑。
同时必须准备回滚手段。当预热失败导致新节点无法服务时，负载均衡层应支持将新节点权重置零，流量退回旧节点。自动化脚本可监听节点健康接口，若连续多次探测缓存加载未完成则自动隔离。只有验证通过并稳定运行一段时间，才逐步提升新节点权重至全量，完成整个扩容闭环。
cluster_scalingwarm_upcache_loading修改时间：2026-08-16 05:46:31