Redis软连接这事儿真不简单，重启过程中各种坑和折腾让人头大

（一）

这事儿还得从上个月公司服务器迁移说起,领导一句话，要把老服务器上的Redis数据平滑迁移到新机器上，说是平滑，实际操作起来那叫一个磕磕绊绊，我们运维小哥一开始觉得没啥，不就是个软连接嘛，把新Redis的数据目录软连接到老位置，感觉分分钟就能搞定，结果，第一个坑就在重启服务那儿等着呢。

按照网上搜来的“标准”操作流程（来源：某技术社区帖子《Redis迁移实战》），我们先是停了老Redis服务，然后把整个数据目录打包拷贝到新服务器上，接着在新服务器上配置好Redis，并把dir配置项指向一个临时目录，关键一步来了：我们删掉了原来老数据目录的物理文件，然后创建了一个软连接（soft link），把这个软连接指向新服务器上的那个临时数据目录，心想，这样应用程序还是读取原来的路径，但实际数据已经指向了新地方，完美！

结果sudo systemctl restart redis命令一敲，服务是起来了，日志也没报错，但用redis-cli连上去一看，傻眼了：之前的数据全没了，就像一个刚装好的新库！当时心里就“咯噔”一下，赶紧检查，发现软连接是存在的，指向也没错，权限什么的看起来都正常，为啥数据没加载进来呢？折腾了半天才发现，原来是Redis服务的启动用户（我们用的是redis用户）对软连接所指向的实际路径的父目录没有执行（x）权限！（来源：排查过程参考了Redis官方文档关于权限的说明，但当时完全没往这儿想）软连接本身只是个“快捷方式”，Redis进程最终需要去访问真实文件，如果对路径上的某个父目录没权限，它就傻傻地认为数据目录是空的，或者干脆就失败了。

（二）

权限问题解决了,以为这下总该稳了吧？太天真了，重新配置好权限，再次重启Redis，这次服务启动倒是读取到数据了，我们长舒一口气，但没过多久，监控报警就响了，显示有部分应用报错，连接Redis超时。

赶紧排查,发现一个诡异的现象：用redis-cli在本机直接连接是通的，执行命令也很快，但从远程应用服务器连接过来，就时好时坏，大部分请求超时，这又是什么鬼？又是一通翻日志、查网络，最后发现，问题出在重启顺序和防火墙规则上。（来源：此坑为团队内部复盘总结）

我们的新服务器启用了一套更严格的防火墙策略,在老服务器上，Redis监听的端口是默认放行的，迁移到新服务器后，虽然我们记得在防火墙里开了Redis的端口，但重启Redis服务的时间点，和防火墙规则完全生效的时间点，存在一个细微的时间差，可能Redis服务先启动成功，开始监听端口了，但此时防火墙规则还没完全加载或生效，导致外部请求在那个瞬间能被接收到一部分，但紧接着防火墙规则彻底生效，可能会干扰到已经建立的连接或新的连接请求，这个时间窗口非常短，但足以造成应用端连接池里产生大量无效或僵死的连接，从而引发连锁反应般的超时，我们不得不先彻底停掉Redis，确保防火墙规则万无一失地配置好并生效，然后再启动Redis服务，这个问题才消失，一个重启的顺序，差点让我们阴沟里翻船。

（三）

连上之后,以为噩梦结束了？并没有，平稳运行了几个小时后，又有报警，这次是Redis响应速度变慢，登录服务器用info命令一看，发现connected_clients连接数比迁移前高出了一大截，而且有几个连接已经空闲了很长时间没断开。

这才想起来,老Redis配置里为了兼容一些老应用，设置了一个比较大的timeout值（连接空闲超时时间），在迁移过程中，我们用的是新版本的Redis配置文件，虽然大部分核心参数都对照着改了，但这个不起眼的timeout参数被忽略了，新配置里用的是默认的0（永不超时）。（来源：自身疏忽，对比配置文件时遗漏）导致很多应用连接上去之后，即使完成了操作也不再主动关闭，Redis服务器也不会主动清理它们，连接数就这么一点点堆积起来，消耗了不少资源。

这还没完,我们还遇到了AOF重写带来的问题，重启后，Redis会根据配置可能触发AOF重写（BGREWRITEAOF）来压缩日志文件，不巧的是，我们迁移期间数据量比较大，重写过程持续了挺长时间，那段时间Redis主进程的磁盘IO被占用了不少，导致偶尔有写操作延迟变高，又触发了另一波监控报警，虽然这属于正常现象，但在本来就神经紧绷的迁移过程中，任何一点风吹草动都让人心惊肉跳。

（四）

回过头来看这次Redis软连接迁移,真不是简单地创建一个符号链接就完事了，它涉及到文件系统权限的细枝末节（软连接本身的权限和指向路径的权限是两码事），系统服务依赖（比如防火墙、SELinux等）的启动顺序和协调，配置文件参数的逐字校对（一个不起眼的参数可能埋着大雷），以及Redis自身持久化机制在重负载下的表现。

每一步都觉得考虑周全了,但重启那个按钮按下去，就像开盲盒一样，不知道下一秒会跳出什么错误，那种感觉，就像在拆一个复杂的炸弹，剪错一根线就前功尽弃，网上那些看起来“一步到位”的教程，在实际的运维环境中总会遇到各种意想不到的“特色”问题，所以啊，以后谁再说“Redis软连接迁移很简单”，我非得拉着他好好聊聊我们这次重启过程中遇到的这些坑，保准让他也头大一把，经过这一番折腾，最大的教训就是：任何涉及核心服务的变更，尤其是重启操作，一定要有详尽的检查清单，并在业务低峰期做充分的预演，否则线上环境分分钟教你做人。