更新完Redis别忘了端口号，老变真让人头大，得常查着点才行

（用户原话：“更新完Redis别忘了端口号，老变真让人头大，得常查着点才行”）

这话算是说到点子上了,搞技术维护的，尤其是经常跟服务器打交道的人，听到这个肯定深有同感，更新个软件，本来以为是点几下鼠标、敲几行命令的简单事儿，结果偏偏就在最不起眼的地方栽跟头，端口号就是其中最经典、也最让人哭笑不得的一个。

为啥端口号这么容易忘呢？首先啊，像Redis这类服务，在默认情况下，它就用那么一个大家都很熟悉的端口号，比如Redis的6379，平时我们连接它，无论是应用程序里的配置，还是自己手动用命令行工具去连，这个端口号几乎成了肌肉记忆，根本不用过脑子，久而久之，我们就产生了一种错觉：这个服务天生就在这个端口上，雷打不动，所以当更新提示弹出来的时候，我们的注意力全都被新特性、性能提升、安全补丁这些“大事”给吸引过去了，谁会特意去惦记一个感觉上万年不变的端口号呢？

但问题就出在这里,有些更新过程，特别是那种涉及到服务重新安装或者配置文件被覆盖的更新，它可能就会“多此一举”，它也许是为了安全，也许是为了避免冲突，会把端口号重置回默认值，可关键是，咱们的生产环境或者测试环境，往往因为各种历史原因或者特殊需求，早就把端口号给改掉了，可能一台服务器上跑了两个不同版本的Redis做测试，那必须得用不同的端口号区分开啊；又或者，纯粹是为了安全起见，避免被网络上自动扫描的工具轻易发现，所以才不用默认端口，这一重置，可就全乱套了。

等你更新完毕,信心满满地重启服务，然后尝试连接的时候，噩梦就开始了，命令行那边返回一个“Connection refused”（连接被拒绝），或者应用程序疯狂报错说连不上数据库，那一刻，你的第一反应多半是：“咦？服务没启动成功？”于是你赶紧查进程，诶，进程明明好好地在着呢，然后又怀疑是防火墙搞鬼，把防火墙规则检查了一遍，也没问题，这一通折腾，可能十几二十分钟就过去了，急得满头大汗，才猛然一拍脑袋：“哎呀！是不是端口号又变回默认的了？！”赶紧去翻新版本的配置文件一看，果然，那个熟悉的、被你改过的端口号，已经悄无声息地变回了6379，这种时候，真是又好气又好笑，恨不得给自己两下子。

“老变真让人头大，得常查着点才行”这句话，真是经验之谈，是踩过坑之后总结出的血泪教训，它提醒我们，在进行任何软件更新，尤其是服务类软件的更新时，绝对不能想当然。“常查着点” 具体要怎么做呢？其实就是在更新前、更新后，养成几个固定的检查习惯。

更新之前,最好能有个清单，这个清单上第一条就应该记下当前正在使用的配置参数，端口号自然是重中之重，除此之外，还有数据文件存放路径、密码设置、绑定的IP地址等等，把这些关键信息先备份出来，或者干脆就直接写在你的更新操作手册里，这样在更新完成后，就能有个清晰的对照。

更新完成之后,别急着验证功能，先停下来，第一件事就是去核对配置文件，打开新的配置文件，逐行扫一眼，重点检查那些你修改过的关键配置项，确认端口号等设置是否还是你之前设定的那个值，如果被重置了，就老老实实地把它改回来，这个动作虽然简单，但能避免后面绝大部分的麻烦。

像用户说的,光靠脑子记肯定不行，再好的记性也抵不过琐事的干扰，做好文档记录至关重要，哪怕只是一个简单的文本文件，里面记录着哪台服务器上的哪个服务，用的是哪个端口，为什么用这个端口，上次修改是什么时候，这份文档就是你 troubleshooting（故障排查）时的寻宝图。

更新Redis（以及其他任何服务）后忘了端口号，这种事儿就像出门忘了带钥匙，虽然问题本身不复杂，但带来的麻烦和耽误的时间是真真切切的，把“更新完先查端口”这个动作变成一种肌肉记忆，一种条件反射，就能省去很多不必要的焦虑和折腾，这大概就是运维工作中，那些看似微小却至关重要的“基本功”吧。