大家好，我是架构摆渡人。这是实践经验系列的第四篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

背景介绍

在高并发的业务场景中，缓存是必须要上的，用来扛高并发。在某个业务场景中，增加了对一个配置信息的缓存，最开始是直接读取DB的，为了性能考虑在前面加了一层缓存。

加完后很长一段时间也没问题，DB的压力也减小了很多。不幸的是在某天的一个时间点内，流量增加了好几倍，RT直线上升，接口各种超时，就这样，一个线上故障诞生了。

整个过程持续了1分钟左右，监控告警稍微有点延迟，刚看完监控告警，准备介入处理时流量已经跌下来了，接口也恢复了正常。

事后，通过监控发现接口超时的原因是因为底层Redis超时了，说到这可能大家都抱着怀疑的态度，Redis这么快也能超时？是的，你没看错，就是Redis超时了。

而Redis超时的原因并不是说Redis性能不行，而是在同一时刻有大量的请求访问了同一个Key，这个Key缓存的内容很大，导致一瞬间就把网络带宽给占用完了，后续请求都进不来。

解决方案

扩容带宽

直接扩容是最简单有效的方式，如果有