半夜数据库突发宕机，竟是Redis惹的锅？？？

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

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

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

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

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

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

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

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

小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我，后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备！
所有资料都整理到网盘了，需要的话欢迎下载！私信我回复【111】即可免费获取
 

目录：

1、延迟基线测量

2、慢指令监控

• 慢日志功能

• Latency Monitoring

3、网络通信导致的延迟

4、慢指令导致的延迟

5、Fork 生成 RDB 导致的延迟

6、内存大页（transparent huge pages）

7、swap：操作系统分页

• 获取 Redis 实例 pid

• 解决方案

8、AOF 和磁盘 I/O 导致的延迟

9、expires 淘汰过期数据

• 解决方案

10、bigkey

• 查找 bigkey

• 解决方案

Redis 性能出问题了么？

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

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

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

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

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

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

1、延迟基线测量

redis-cli 命令提供了–intrinsic-latency 选项，用来监测和统计测试期间内的最大延迟（以毫秒为单位），这个延迟可以作为 Redis 的基线性能。

redis-cli --latency -h `host` -p `port`

比如执行如下指令：

redis-cli --intrinsic-latency 100Max latency so far: 4 microseconds.Max latency so far: 18 microseconds.Max latency so far: 41 microseconds.Max latency so far: 57 microseconds.Max latency so far: 78 microseconds.Max latency so far: 170 microseconds.Max latency so far: 342 microseconds.Max latency so far: 3079 microseconds.
45026981 total runs (avg latency: 2.2209 microseconds / 2220.89 nanoseconds per run).Worst run took 1386x longer than the average latency.

注意：参数100是测试将执行的秒数。我们运行测试的时间越长，我们就越有可能发现延迟峰值。

通常运行 100 秒通常是合适的，足以发现延迟问题了，当然我们可以选择不同时间运行几次，避免误差。

运行的最大延迟是 3079 微秒，所以基线性能是 3079 （3 毫秒）微秒。

需要注意的是，我们要在 Redis 的服务端运行，而不是客户端。这样，可以避免网络对基线性能的影响。

可以通过 -h host -p port 来连接服务端，如果想监测网络对 Redis 的性能影响，可以使用 Iperf 测量客户端到服务端的网络延迟。

如果网络延迟几百毫秒，说明网络可能有其他大流量的