Redis迁移那些固定key的套路和小技巧，实际用起来还挺有意思的

基于常见的Redis运维实践和开发者社区的经验分享）

说到Redis迁移，很多人可能先想到的是把整个库一股脑儿导过去，比如用那种redis-cli --rdb的方式搞个快照，这个方法对付整库搬迁确实利索，但有时候吧，咱们的需求没那么粗放，我就遇到过好几次这种场景：只需要动那么几个特定的、命名的很有规律的key，其他的数据都得原封不动，这时候，要是再上那种“重型武器”，就有点像用高射炮打蚊子了，不仅动静大，还可能不小心伤及无辜，琢磨出一些专门对付这些固定key的迁移套路,玩起来还真挺有意思的。

第一个套路，我管它叫“精准点名，各个击破”。 这招最适合那种key的名字你心里门儿清，或者有固定前缀的情况，核心武器就是DUMP和RESTORE这一对儿黄金搭档，它的妙处在于，DUMP命令会把key对应的值序列化成一种Redis特有的格式，这个格式是自带类型信息的，你把它拿到目标Redis上，用RESTORE命令一喂，它就能原模原样地恢复出来，不管是字符串、哈希、列表还是集合，都能完美复刻，连原来的TTL（生存时间）都能一并设置上。

具体操作起来就像玩一场接力赛，你在源Redis上，对每个要迁移的key执行DUMP key_name，它会返回给你一串看起来乱码似的二进制数据，你把这串数据小心翼翼地拷贝下来，跑到目标Redis上，执行RESTORE key_name ttl_in_milliseconds serialized-value，这里的关键是那个ttl_in_milliseconds，如果你希望保留原key的过期时间，就得先在源Redis用TTL key_name查一下还剩多少秒，然后乘以1000转换成毫秒填进去，如果key是永不过期的，这个参数就写0，这个过程虽然有点手工劳动的意味，但对于数量不多、又非常重要的核心key来说，这种“精雕细琢”的方式让人特别放心，你可以一个一个地确认,确保每个key都安全着陆了。

第二个套路，可以称之为“批量抓捕，集中押运”。 当要迁移的key多了，手动一个个来肯定不现实，这时候就得请出SCAN命令和管道（pipeline）技术了。SCAN命令是个好东西，它不像KEYS命令那样会阻塞服务器，可以安全地、增量地遍历出所有符合模式的key，比如你要迁移所有以user:session:开头的会话key，就可以写个脚本，用SCAN命令迭代地把这些key找出来。

找出来之后呢？如果还是一个个DUMP再RESTORE，网络来回次数太多，效率低，这时候，管道就派上用场了，你可以在脚本里，先在源Redis上通过管道批量执行DUMP命令，把序列化的值都收集起来，再到目标Redis上，同样通过管道批量执行RESTORE命令，这一下子就能把成百上千个key的迁移操作压缩到很少的几个网络请求中完成，速度嗖嗖的，这种感觉，就像把散兵游勇编成了正规军，行动效率天差地别，不过用这招得稍微小心点，如果一批操作的key太多、value太大，可能会短暂占用较多内存和网络带宽,最好能分一下批次。

第三个有意思的小技巧，是关于如何处理迁移过程中的“动态分子”的。 什么是“动态分子”？就是那些在迁移过程中，可能还在被应用程序频繁读写的key，比如一个用户计数器，你刚把它DUMP出来，还没等RESTORE到新库，源库上的值可能已经变了,这就产生了数据不一致。

对付这种情况，有个土办法但很实用：加个“标记”或者尝试“锁定”，Redis没有真正的事务锁，但我们可以利用它的原子操作来模拟，在迁移某个关键key之前，先在源库上给它设置一个特殊的字段，比如在一个哈希结构里写"migrating": "true"，然后应用程序在读写这个key的时候，先检查这个标记，如果发现正在迁移，可以稍微等待一下或者走降级逻辑，等迁移完成后，再把这个标记清除掉，虽然这需要应用代码做一些配合，但对于保证关键数据的强一致性来说，是值得的，如果做不到应用层配合，那通常就只能选择在业务低峰期，以最快的速度进行操作,尽可能减小数据不一致的时间窗口。

还有个“移花接木”的玩法，特别适合做热迁移或者灰度发布。 我们可能不想一次性把所有流量都切到新的Redis实例上，这时候，可以先用上面说的办法，把固定的key悄悄地、完整地复制到新实例上备着，在应用程序的配置里，逐步地把对这些key的读请求分流到新实例上去试试水，看看延迟、错误率怎么样，写请求暂时还留在老实例，等观察一段时间，确认新实例稳定无误后，再找个时机，把写请求也一次性切换过去，这种循序渐进的方式，心里踏实多了，就算新实例有啥幺蛾子，也能快速切回来,影响范围可控。

迁移Redis里那些固定的key，远不止一种方法，从手工的精准操作，到自动化的批量处理，再到应对数据动态变化的技巧和灰度发布的策略，这里面有很多可以琢磨和尝试的空间，根据不同的场景，灵活组合这些套路和小技巧，不仅能完成任务，还能在这个过程中更深入地理解Redis的行为特性,确实挺有意思的。