【项目经验】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。因为本下线迁移工作周期将很长，于是我跟领导提议，先把这部分确定不使用的下掉，减少后续相关业务的开发负担，提升代码的可读性。代码可读性高，可优化性也将提升。领导肯定了我的提议，预计下周安排这部分上线。

目前学到了什么？

        之所以这部分工作还未进行完，我就开始进行了总结，原因之一：是这个工程很大，影响范围广，周期长，需要记录节点并根据具体情况对方案进行修正；另一个很重要的原因：进行到目前为止，收获已经颇丰！

        1、公共资源隔离；

        除了Redis，还有我们常说的MySQL 垂直分库，垂直分表，都有资源隔离，解耦的目的。

        如果一定要使用同一个资源，一定写好注释和文档，标明写入方，调用方，使用场景等。目前发现业务中用Redis实现了一个队列的功能，我发push，还不知道哪方在读取，读取后用作什么。。。

        2、使用Redis时，设置超时时长，获取异常方案；

        3、灰度结束后的代码及时下掉；

        长期无引用的代码，百害无一利。

        4、复杂的项目，及时与领导沟通方案和汇报进度

        及时接收指导和修正，争取得到最好的效果