【项目经验】Redis Sentinel从工程中下线并对业务迁移-进行中

一、背景：

某天，接到DBA通知，Redis sentinel 只支持到3.2.X(这个命题有问题，往下翻，见彩蛋)，为节省运维成本，提升运维效率，决定将工程中使用的Redis sentinel下线，都使用Redis cluster模式，并且给出了当前都有哪些组对哪些Redis sentinel集群有引用。

因为各种历史原因，我们的工程中引用了Redis sentinel和Redis cluster 两种方式，而且组与组之间可能有公用的key。

之前我的文章中也介绍过这两种部署方式，感兴趣的朋友可点击：

Redis-主从复制_哪些场景会触发redis主从全量复是-CSDN博客Redis-sentinel 哨兵_redis sentinel哨兵-CSDN博客Redis-集群_redis-cluster集群模式搭建 5.0.14-CSDN博客

二、期望与目标：

1、下掉对Redis sentinel集群引用；

2、只有自己组使用的key，迁到自己组专用的Redis cluster集群；

3、公用的key，迁到运维搭建好的新的公共集群；

三、时间节点：

X月X日；

四、技术方案：

与运维侧确定了‘期望与目标’后，我和我们领导对整个流程进行了double check，方案如下：

1、统计调用场景

按照运维给出的使用sentinel的工程，梳理该工程中使用sentinel的业务场景，我做了一个简约的表格，如下(以学生信息管理系统为例)：

某工程Redis sentinel使用情况统计
序号	类名	使用场景(调用量)	redis key	未获取到时如何操作?	是否需要其他组check	是否影响主流程	是否可迁移	备注
1	Student	查询学生姓名	s_id	查表	否	否	是
2	Course	写入选该课的学生ID	c_id	提示没有该课	是	是	否	需要确定哪些业务方在读取
3	...	...						...

表头就是我们在整个下线过程考虑方面，后面统计完成后，用此表和其他业务组对接。

2、确定我组修改方案

梳理完成后，我发现我们的工程1中，同时使用了Redis cluster 和Redis sentinel；

工程2，只使用了Redis sentinel。基于此情况，我对组内工程的修改制定了更加详细的方案，并再次和我领导确定。

2.1 通知组内成员，sentinel将下线。

涉及工程1中的新业务，使用现有的Redis cluster模式，停止写入Redis sentinel；

涉及工程2中的新业务，因工程2目前只引入了Redis sentinel，可继续写入，但写入后更新我们的统计文档；

2.2 在工程2中引入我组专用Redis cluster集群。

因为sentinel整体下线需要一段时间，为了避免二次迁移，我们决定在工程2中引入我组之前专用Redis cluster集群。大家新业务就可以写入 Redis cluster中了。

2.3 将只有我组使用的Redis key 迁入我组专用Redis 集群。

3、和其他业务组对接

这部分将于下周进行。ToDo

五、灰度方案：

因为涉及的业务场景不同，所以使用的上线灰度方案也不同，大致如下：

1、组之间公用的key

评估是否还有业务继续使用？是否可用其他方案替代以解耦合？如果没有，将进行单写双读灰度上线。在sentinel中原key的信息处理完成后，再下掉读。

2、可直接迁移的key

评估是否有缓存穿透，雪崩的风险？是否需要提前缓存？

3、无需提前处理，直接上线

灰度异常方案：

如无依赖，各组自行上线，上线异常时，回滚到上一个tag；

如果进行单写双读，依赖方先上线，同时从Redis cluster和Redis sentinel中读；被依赖方后上线，只写入redis cluster.

六、测试方案：

因为涉及的业务场景很多，各组将尽可能提供精确的使用场景，同时测试部门会进行自动化测试，对重要功能节点将进行压测。

七、进展：

暂未上线。目前进行到了技术方案中的2.3，预计下周将进行第3部分。

彩蛋：

1、运维侧说“Redis sentinel 只支持到3.2.X”时，当时我想当然的以为Redis官方针对sentinel只支持到3.2.X，新版本将没有Redis sentinel。后来我觉得有点奇怪，想看看下线的原因，便去查阅了Redis 官方文档，并下载了最新版本，发现最新版本有Redis sentinel模式。于是，我再次和运维确认，才发现我理解错了，是我司目前Redis sentinel 只维护到了3.2.X版本，后续将主要使用redis cluster，只对Redis cluster集群升级。

2、我发现工程2中，一个主流程业务在代码中深度使用Redis sentinel。经过我层层排查，注释掉层层开关配置，发现该代码灰度已结束，真正执行的流程已不再使用Redis sentinel。因为本下线迁移工作周期将很长，于是我跟领导提议，先把这部分确定不使用的下掉，减少后续相关业务的开发负担，提升代码的可读性。代码可读性高，可优化性也将提升。