上半年，我们将 Redis集群 从旧机房迁移到了服务所在的新机房，迁移过程碰到了一些常见的方法，也遇到一些Key丢失的问题，因此写文章来记录和总结下。
迁移清单
想要平稳顺利的迁移，那么做好准备哦那个工作很重要。最重要的工作就是准备 清单。一个合格的数据库迁移一般要包括：步骤、灰度策略、验证措施、回滚方案。
- devops 使用
redis-shake从旧集群持续同步数据到新集群 - dev 验证新集群功能正常
- devops 确认新旧集群 Key 一致
- dev 开始发布的切换到新集群配置
- 按照地区灰度迁移（在东南亚七个地区提供服务，因此可以优先灰度用户量小的地区）
- 将服务分为 无风险、低风险、高风险，按照风险等级分组发布和回退
- 发布群通知所有人开始发布
- 观察服务监控、并验证服务功能
- devops 确认旧集群流量为0，新集群调用量、监控正常
个别 Key 同步失败
第一个问题出现在 步骤3。在数据同步完全正常的情况下，发现个别 Key 没有同步到新集群
0 lack_target xxx_cron_RetryEsStoreTask
0 lack_target xxx_cron_WsCDNStatMonitor
0 lack_target xxx_cron_TaskMonitor
0 lack_target xxx_cron_TxCloudStatMonitor以上几个 Key 存在比较明显的特征，即，都是定时任务使用Redis作为分布式锁创建的。该部分比较特殊的地方在于使用 lua 脚本，而同步工具对 lua的支持不太好。
Redis 集群流量持续不归零
第二个问题出现在 步骤5，迁移完成之后Redis流程持续不归零，经过捞日志发现，该部分流量来源于监控、扫描检测程序
个别 Key 奇怪丢失
第三个问题出现在迁移完第一个地区的两天后，在迁移地区的本地运营同学反馈一个问题，少部分 Key 莫名奇怪的丢失
2020-03-05 18:01:32 写入key：xxx_balancestatus_216213136
2020-03-05 18:06:49 检测到key丢失
2020-03-06 18:05:21 再次写入key检查了项目代码里，没有删除key的操作，请问能否查下redis数据是否正常，有没有意外丢失key的可能性。以下是我们排查的对话：
Devops: xxx_balancestatus_216213136 这个key有设置ttl嘛？
Dev： 有，3 天
Dev: 相同的key，18:01设置的key（3d过期），18:06丢失了 (提供了日志作为依据)
Devops：可能是同步进程挂的时间太长了，源集群过期的key forward了del命令到新集群
Me：你按照删除时间，往前三天看下能否捞到这个用户的写入日志，如果时间对的上，那可以基本上证明是这个原因
Dev：2日刚好有一个写入操作
Me： 2号到5号，该用户还有写入么
Dev: 4号还有一次
Me: 4号几点？
Dev: 4号 18 点
Devops: 4号18点 已经切换集群了, 所以2号写入的key 在老集群, 3天后 过期 forward del命令到新集群充足的日志提供了有力的证据把握各个时间点，成功捉虫：Devops 为了确保安全，没有尽快把同步程序关掉，导致该问题
总结
迁移之后，平均耗时有1～2ms的降低，服务迁移有着比较明显的效果。由于两个地方位于同一个城市，说明调用耗时产生的原因跟距离关系不大，猜测跟机房的网络架构关系很大(之前也遇到过，同一地区同样配置服务，有一个机房就是比其他机房调用慢不少)。
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/09-06-2020/redis-migrate-key-lost.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！