记一次 Redis 迁移 —— Key 丢失问题排查

上半年，我们将 Redis集群 从旧机房迁移到了服务所在的新机房，迁移过程碰到了一些常见的方法，也遇到一些Key丢失的问题，因此写文章来记录和总结下。

迁移清单

想要平稳顺利的迁移，那么做好准备哦那个工作很重要。最重要的工作就是准备 清单。一个合格的数据库迁移一般要包括：步骤、灰度策略、验证措施、回滚方案。

1. devops 使用 redis-shake 从旧集群持续同步数据到新集群
2. dev 验证新集群功能正常
3. devops 确认新旧集群 Key 一致
4. dev 开始发布的切换到新集群配置

1. 按照地区灰度迁移（在东南亚七个地区提供服务，因此可以优先灰度用户量小的地区）
2. 将服务分为 无风险、低风险、高风险，按照风险等级分组发布和回退
3. 发布群通知所有人开始发布
4. 观察服务监控、并验证服务功能

1. 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 许可协议。转载请注明出处！

# 数据库

1. 深入理解 Redis cluster GOSSIP 协议
2. 如何配置 go-redis 连接池
3. 如何使用 Redis 存储对象
4. Redis cluster 细节与技术选型
5. etcd 实现与选型分析
6.