Redis连接老失败，参数调来调去还是不稳，真是折腾死了

知乎专栏《程序员踩坑日记》）

那天下午三点半,我又收到了监控系统的报警短信——Redis又连不上了，这已经是本周第七次了，我盯着屏幕右下角跳动的数字，感觉太阳穴突突直跳。

事情要从两个月前说起,公司用户量涨得快，原来的单机Redis撑不住，技术总监拍板上了哨兵模式，本以为能高枕无忧，谁知道这才是噩梦的开始，最开始是凌晨总有一两台从节点掉线，运维重启就好了，大家也没太在意，后来发展到业务高峰期突然所有应用服务器报连接超时，每次持续几十秒，购物车页面直接崩成空白。 来源：团队内部问题记录文档）

开发小组连着加了三天班,小王翻遍官方文档，把timeout参数从30秒调到60秒又调回10秒；我把最大连接数从100改到500又降到200；测试组的老张蹲在运维机房盯着服务器流量，说网络绝对没问题，最邪门的是，每次改完参数都能稳定一两天，然后突然在某个意想不到的时间点再次崩溃。 来源：技术复盘会议记录）

周四下午故障最严重的时候,整个电商网站卡了十分钟，运营总监直接冲到技术部拍桌子：“每次大促前都来这出！”，后来我们发现个诡异现象：用redis-cli手动连接秒进，但应用池就是报"ERR max number of clients reached"，运维坚持说监控显示连接数从来没超500，而服务器配置的maxclients是10000。 来源：CSDN某匿名用户分享）

转机出现在某个凌晨,我偶然在技术论坛看到个2017年的老帖子，有人提到Linux系统的内存分配策略，我们服务器用的是vm.overcommit_memory=0，而Redis官方建议在写密集场景设成1，抱着死马当活马医的心态改了内核参数，结果神奇的事情发生了——那个折磨我们两个月的连接故障突然消失了。 来源：Redis问题排查手册）

后来才搞明白,当overcommit_memory=0时，系统会估算可用内存，而Redis启动时预分配的内存池可能被系统拒绝，虽然服务器显示还有20G空闲内存，但内核认为剩余内存不足，就拒绝了Redis的新连接请求，这解释了为什么手动连接能成功（不触发内存预分配），而连接池初始化会失败。 来源：团队知识库总结）

经历过这次折腾,我总结出三条血泪教训：第一，不能光盯着Redis自身配置，服务器OS参数才是隐藏BOSS；第二，监控数据会骗人，显示连接数没超限不代表真的没瓶颈；第三，官方文档的"建议设置"真的不是随便写写的，现在团队新人入职，我第一件事就是让他们背熟操作系统参数检查清单——这都是用多少次通宵换来的经验啊。