一旦 Redis 请求延迟增加，可能就会导致业务系统“雪崩”。

我在单身红娘婚恋类型互联网公司工作，在双十一推出下单就送女朋友的活动。

谁曾想，凌晨 12 点之后用户量暴增，出现了一个技术故障。用户无法下单，当时老大火冒三丈。

经过查找发现 Redis 报 Could not get a resource from the pool。

获取不到连接资源，并且集群中的单台 Redis 连接量很高。

大量的流量没了 Redis 的缓存响应，直接打到了 MySQL，最后数据库也宕机了……

于是各种更改最大连接数、连接等待数。虽然报错信息频率有所缓解，但还是持续报错。

后来经过线下测试，发现存放 Redis 中的字符数据很大，返回数据平均需要 1 秒。

可以发现，一旦 Redis 延迟过高会引发各种问题。

今天「码哥」跟大家一起来分析下如何确定 Redis 有性能问题和解决方案。

1 Redis 性能出问题了吗？

最大延迟是客户端发出命令到客户端收到命令的响应的时间，正常情况下 Redis 处理的时间极短，在微秒级别。

当 Redis 出现性能波动的时候，比如达到几秒到十几秒，这个很明显我们可以认定 Redis 性能变慢了。

有的硬件配置比较高，当延迟 0.6 毫秒，我们可能就认定变慢了。硬件比较差的可能 3 毫秒我们才认为出现问题。

那我们该如何定义 Redis 真的变慢了呢？

所以，我们需要对当前环境的 Redis 基线性能做测量。也就是在一个系统在低压力、无干扰情况下的基本性能。

当你发现 Redis 运行时时的延迟是基线性能的两倍以上，就可以判定 Redis 性能变慢了。