为什么缓存迁移和扩容/缩容看起来复杂
先把问题说清楚：缓存不是单纯的数据存储，它是应用性能的关键依赖。迁移或调整容量时，你面对的是读写流量、命中率、热点数据、一致性和故障恢复五个维度。如果任一维度处理不好，用户会感觉“卡顿”或者数据不一致，业务就会被牵连。
常见痛点（说人话）
- 命中率骤降：重分片或冷启动会导致缓存未命中，后端压力暴增。
- 延迟提升：网络迁移或不当路由会把请求多绕一圈。
- 数据不一致：双写不同步、回写失败会造成脏数据。
- 运维复杂性：回滚不顺畅、监控缺口导致排障慢。
可选迁移与扩缩策略——先看全局，再细说实现
我通常把方案分为四类：冷迁移（停机/窗口）、主从复制迁移、增量同步（双写/双读）与代理/分片重映射。每种都有适用场景和代价，下面分开说。
1. 全量冷迁移（停机窗口）
- 场景：数据量小、能接受短暂停机的场合。
- 步骤：暂停写入 -> 导出快照 -> 导入目标 -> 验证 -> 恢复服务。
- 优缺点：实现简单但可用性受影响，适合低流量时段。
2. 主从复制/切换（适用于 Redis 主从、Replica）
- 场景：需要尽量减少停机时间但能容忍短暂延迟差异。
- 步骤示例（Redis）：建立新集群为从库 -> 等待同步完成 -> 切换应用到新主 -> 老主降级或删除。
- 注意事项：确保复制延迟小，切换时处理客户端连接重试。
3. 增量同步（双写/双读）和灰度迁移
- 场景：零中断、复杂一致性需求、线上大流量。
- 做法：应用同时写入旧缓存与新缓存（双写），或读时优先旧缓存并回补新缓存（双读+回写）。通过流量灰度把百分比逐步从旧系统迁移到新系统。
- 代价：开发改造成本高，但风险最小。
4. 基于代理或路由层的切换（如 twemproxy、codis、环境网格）
- 场景：需要透明迁移、避免应用改造。
- 做法：更新路由规则或代理配置，把部分槽/分片指向新集群，逐渐平衡。
- 优点：对应用透明；缺点：代理单点或性能瓶颈需评估。
扩容与缩容的实操要点
扩容分为纵向（scale up）和横向（scale out）；缩容则是相反。总体原则是：优先横向扩容以分散风险，缩容要灰度并确保数据搬迁完毕。
扩容（scale out）步骤示例
- 容量评估：计算当前与峰值 QPS、平均/95/99 响应时间、缓存命中率及内存利用率。
- 规划分片：如果用一致性哈希，新增节点会触发槽迁移，估算重分片流量。
- 预热新节点：通过批量写入或流量复制把热点数据加载进新节点（减少冷启动）。
- 逐步引流：使用代理或在客户端按比例发送流量，观察命中率与延迟。
- 剔除瓶颈：确认无问题后，把新节点正式加入集群并调整监控告警阈值。
缩容（scale in）安全流程
- 标记节点为“待下线”，停止将新数据写入该节点（或逐步减少权重）。
- 把热数据迁移/回写到其它节点，确保无超时或丢失。
- 流量完全切换后，监控至少数小时无异常，才物理下线。
- 预留回滚窗口：保留旧实例快照和配置，便于快速恢复。
关键监控指标与验收标准
- 命中率（整体与热点分布）——迁移中应维持或快速回升。
- 平均/95/99 延迟——迁移切换点的延迟波动应小于业务可承受阈值。
- 后端 QPS——未命中时后端压力增长需可控。
- 复制延迟（若用复制）——小于设定容忍值。
- 错误率与连接数——无异常增长。
对比表：四种主流迁移方式
| 方式 | 可用性影响 | 实现复杂度 | 适用场景 |
| 全量冷迁移 | 高（需短停机） | 低 | 小流量或维护窗口 |
| 主从复制切换 | 中（短时间切换） | 中 | 可容忍短延迟差的场景 |
| 增量同步（双写/灰度） | 低（近零停机） | 高 | 关键业务、大流量 |
| 代理/路由层切换 | 低（对应用透明） | 中 | 已有成熟代理或网关的环境 |
实操清单（迁移当天必做）
- 确认快照与配置备份可用，并能在 30 分钟内恢复。
- 预演迁移流程（至少在测试环境完整演练一次）。
- 准备回滚脚本与自动化步骤，保证回退时间小于业务容忍值。
- 设置低阈值告警与看板（命中率、延迟、错误率、复制延迟）。
- 安排联调和应急联系人，明确切换审批人和沟通流程。
Redis 常用命令参考（实操笔记）
- MIGRATE：用于原子迁移 key 到远端实例，适合逐键搬迁，但对大量 key 不方便。
- REPLICAOF / SLAVEOF：设置从库，等待同步完成后再切换主从。
- SLOT迁移：在 Redis Cluster 中使用 CLUSTER 命令进行 slot rebalance。
- BGSAVE / RDB/AOF：用于全量快照备份与恢复。
常见问题与解决思路（那些会让人头疼的）
- 命中率骤降：先回滚路由或开启预热，增加缓存填充，并分析热点是否错位。
- 复制延迟大：检查网络带宽与延迟，考虑临时缩减一致性要求或增加带宽。
- 代理成为瓶颈：考虑水平扩展代理或改用客户端分片策略。
- 数据丢失风险：始终有多层备份（RDB/AOF + 外部备份），并定期演练恢复。
小结式提示（不是总结，随手写的几条经验）
- 越早做容量评估越省事，避免临时扩容导致资源浪费或故障。
- 灰度迁移是最稳妥的方式，但需要开发投入；对关键业务值得投入。
- 监控和演练的重要性被高估也不为过——你在排查问题时会感谢那些做过的压力测试。
- 缩容要比扩容更谨慎：不要在高峰期退节点，先做无写入停写验证。
干货就先到这里——如果你是在做真实迁移，建议先在隔离环境把“预热、灰度、回滚”三步跑通；遇到特殊热点分布或复杂一致性需求时，逐步把双写/代理策略纳入方案。说到这儿我忽然想到，上次做分片重平衡的时候，测试环境漏了一个 TTL 导致预热失败，后来才意识到细节的坑其实比大策略更容易翻车，还是那句话：演练和日志，一定要跟上。