服务迁移 - Redis 服务迁移

关注公众号【1024个为什么】，及时接收最新推送文章！

前面我们说过了数据库服务的迁移，今天继续聊一下 Redis 服务的迁移。

由于纯 [主 - 从] 结构主节点挂掉后不能自动切换的缺陷，生产环境一般很少使用此结构，我们就直接从哨兵结构说起。

哨兵结构的迁移

场景一：只迁移 redis 实例节点

操作步骤

（一）在新的机器上先搭建一套端口相同的主从节点，M2，R2，把 M2 作为从节点，挂在老的 R1 上，通过 Redis 自有的主从同步功能，同步数据。

（二）手动切换哨兵监控的主节点到 M2，触发客户端变更连接的主节点

（三）停掉老的主从节点 M1， R1

由于上一步手动变更哨兵监控主节点时，会自动更新其所监控的节点信息，哨兵监控的节点列表中只有新的主从节点信息，这里可以直接下掉老节点。

场景二：哨兵节点也迁移

此场景是基于场景一的

操作步骤

（一）搭建一套新的哨兵节点 S4 ~ S6，直接监控 M2 节点，哨兵可以相互自动发现监控同一实例节点的其他哨兵，并互相同步哨兵列表和实例节点列表。由于哨兵的自动发现需要一定的时间，官方建议一个一个地添加，间隔 10 秒。操作完成后，检查所有哨兵节点信息是否都正常。

（二）如果域名没变，修改域名解析到 S4 哨兵节点；

如果域名变了，需要业务服务修改域名配置，重启服务后连接到新的哨兵节点。

（三）停掉老的哨兵节点 S1 ~ S3。

由于哨兵节点不会自动忘记其已记录的其他哨兵节点，需要手动重置哨兵节点，使哨兵列表更新到最新。

集群结构的迁移

集群结构的迁移其实就是扩容、缩容。

操作步骤

（一）先向集群中添加一个主节点 M4，此时 M4 节点是空的，没有任何数据

（二）从其他节点迁移数据给 M4，迁移的数据量，从哪些节点迁，都是可以指定的，但一般为了节点的负载均衡，会从现有节点中平均各迁一部分到新的节点。

我们假设往 M4 上迁 3000 个槽位的 key ，即从 M1、M2、M3 各迁出 1000 个槽位的 key。

（三）迁移完成并检查节点数据正常后，再给 M4 挂上从节点。

之所以迁移完数据之后再挂从节点，是为了尽快完成数据迁移，避免迁移过程中主从同步的消耗。

其他节点以此类推。

节点添加完成后，就可以操作删除老节点，删除节点正好是添加节点的逆向，需要先把节点内的数据迁移到其他节点，数据迁移完成后，再停掉该节点。以此类推，直到所有要下掉的节点都删除完。

Redis 迁移几乎是平滑的，只需观察业务服务是否正常即可。

原创不易，多多关注，一键三连，感谢支持！