一、背景：
某天，接到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 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、复杂的项目，及时与领导沟通方案和汇报进度
及时接收指导和修正，争取得到最好的效果
