政策快报平台从上线第一天就开始使用Redis。

早期是自建Redis，部署在ECS上，主从架构（1主2从）。当时数据量小、请求量低，自建Redis完全够用，成本也低。

随着业务增长，Redis的数据量从几GB增长到几十GB，QPS从几千涨到几万。自建Redis开始暴露一些问题：主从同步延迟增大、内存碎片需要定期维护、故障恢复需要人工介入。

2025年底，我们做了一次迁移：从自建Redis迁移到云原生Redis（Tair）。本文复盘这个迁移过程。

迁移的3个核心原因

原因一：运维成本

自建Redis需要投入大量运维精力：

• 版本升级需要手动操作，风险较高

• 内存碎片整理需要定期执行，否则性能下降

• 监控告警需要自己搭建和维护

• 故障恢复需要人工介入，响应时间长（平均15-30分钟）

• 扩缩容需要停机或复杂的主从切换操作

随着业务规模扩大，运维成本线性增长。云原生Redis不需要关心版本升级、不需要手动处理内存碎片、不需要自建监控告警、支持自动故障恢复和分钟级扩容。运维成本显著降低，团队可以把精力放在更有价值的业务需求上。

原因二：性能瓶颈

自建Redis的配置固定（如16GB内存、4核CPU），遇到流量高峰（如热门政策发布时）难以快速扩容。

云原生Redis支持在线扩容，不中断服务，在流量高峰来临前快速扩容，峰值过后再缩容，性能和成本的平衡更好。

原因三：数据持久化与备份

自建Redis的RDB/AOF持久化配置需要自行优化，备份策略需要自行设置。

云原生Redis提供自动备份（每日/每周）和任意时间点恢复，数据安全性更高，无需担心备份失败或恢复缓慢的问题。

迁移方案

步骤一：数据迁移（全量+增量）

全量同步：从自建Redis导出RDB文件，导入到云原生Redis。数据量约30GB，导出+导入耗时约2小时。

增量同步：全量同步期间的新写入操作，通过双写机制同步到云原生Redis，保证数据一致性。

步骤二：双写验证

迁移后进入双写阶段：所有写入同时写自建Redis和云原生Redis，读取仍从自建Redis读取。

验证期持续一周，重点验证数据一致性、云原生Redis的性能指标（响应时间、吞吐量）、云原生Redis的稳定性（无异常错误）。

步骤三：流量切换

验证通过后，逐步切换读取流量：先切换10%的读取流量到云原生Redis，观察1-2天；无异常后切换30%，再观察；无异常后切换50%、80%，最后100%全量切换。

切换完成后，自建Redis保留一周作为回退备份，确认新环境完全稳定后再下线自建Redis集群。

迁移后的效果数据

指标	自建Redis	云原生Redis
平均响应时间	约0.8ms	约0.4ms
P99响应时间	约3.2ms	约1.5ms
可用性	99.5%（约44小时/年宕机）	99.99%（约52分钟/年宕机）
运维投入	约4小时/周	约0.5小时/周
扩容时间	约30分钟（需停服或复杂切换）	约2分钟（在线扩容）

迁移过程的几点经验总结

1. 双写验证是核心保障。 如果直接切换流量，一旦出问题需要紧急回退，影响用户访问。双写验证可以确保在切换前就发现问题，避免用户受到影响。

2. 灰度切换降低风险。 10%→30%→50%→80%→100%的渐进式切换，可以确保每一步都在可控范围内。如果某个阶段出现异常，可以立即回退，不影响整体可用性。

3. 数据一致性验证不能少。 双写阶段需要持续监控数据一致性，包括缓存命中率、数据差异率等指标。出现差异时及时排查原因，确保切换时数据完全一致。

从自建Redis到云原生Redis，是一次“让专业的人做专业的事”的升级。政策快报平台的核心价值在于政策数据处理和服务，缓存服务的底层运维交给云厂商更高效。

迁移的核心是“安全第一”——充分测试、灰度切换、保留回退路径，确保用户无感知。