一次Redis缓存引发的生产事故排查与反思

上周生产环境经历了一次系统”惊魂”——抢购期间系统严重卡顿，带宽瞬间被打满，但各节点的 CPU 和内存指标却一切正常。

现象：带宽打满，资源正常

活动开始的瞬间，监控系统告警频发：

第一反应是遭到了 DDoS 攻击，但阿里云控制台并没有触发任何攻击警报。

登录阿里云安全控制台查了一圈，没有发现异常流量特征。排除 DDoS。

在服务器上用 iftop、nethogs 等工具查看各进程的网络流量，发现流量最大的竟然是 Redis 服务。

深入检查 Redis 配置，发现了一个致命问题——

Redis 被配置成了公网地址，而非阿里云内网地址。

这意味着所有 Redis 通信都要走公网链路，带宽限制极低。而最近为了”提高系统可用性”，大范围引入了缓存策略，但实现方式非常粗暴——直接把整个对象塞进 Redis，没有任何优化。

用 Redis GUI 工具看了一下，单个商品列表的缓存体积竟然达到了 1.4MB。

将 Redis 地址更换为阿里云内网地址，立即缓解了公网带宽压力。

对缓存进行了精细化改造：

这次事故最深刻的教训是——如果提前做过压力测试，网络配置问题和缓存策略的问题大概率能在上线前发现。

缓存是把双刃剑。用得好是加速器，用得不好就是定时炸弹。

几个关键感悟：

希望这个事故复盘对你有帮助，欢迎留言交流。