Redis 通常是我们业务系统中一个重要的组件,比如:缓存、账号登录信息、排行榜等。

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

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

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

经过查找发现Redis。

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

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

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

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

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

Redis 性能出问题了么?

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

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

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

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

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

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

延迟基线测量

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

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

比如执行如下指令:

redis-cli --intrinsic-latency 100
Max 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 测量客户端到服务端的网络延迟。

如果网络延迟几百毫秒,说明网络可能有其他大流量的程序在运行导致网络拥塞,需要找运维协调网络的流量分配。

慢指令监控

如何判断是否是慢指令呢?

看操作复杂度是否是O(N)。官方文档对每个命令的复杂度都有介绍,尽可能使用O(1) 和 O(log N)命令。

涉及到集合操作的复杂度一般为O(N),比如集合全量查询HGETALL、SMEMBERS,以及集合的聚合操作:SORT、LREM、 SUNION等。

有监控数据可以观测呢?代码不是我写的,不知道有没有人用了慢指令。

有两种方式可以排查到:

  • 使用 Redis 慢日志功能查出慢命令;
  • latency-monitor(延迟监控)工具。

此外,可以使用自己(top、htop、prstat 等)快速检查 Redis 主进程的 CPU 消耗。如果 CPU 使用率很高而流量不高,通常表明使用了慢速命令。

慢日志功能

Redis 中的 slowlog 命令可以让我们快速定位到那些超出指定执行时间的慢命令,默认情况下命令若是执行时间超过 10ms 就会被记录到日志。

slowlog 只会记录其命令执行的时间,不包含 io 往返操作,也不记录单由网络延迟引起的响应慢。

我们可以根据基线性能来自定义慢命令的标准(配置成基线性能最大延迟的 2 倍),调整触发记录慢命令的阈值。

可以在 redis-cli 中输入以下命令配置记录 6 毫秒以上的指令:


redis-cli CONFIG SET slowlog-log-slower-than 6000

也可以在 Redis.config 配置文件中设置,以微秒为单位。

想要查看所有执行时间比较慢的命令,可以通过使用 Redis-cli 工具,输入 slowlog get 命令查看,返回结果的第三个字段以微秒位单位显示命令的执行时间。

假如只需要查看最后 2 个慢命令,输入 slowlog get 2 即可。

示例:获取最近2个慢查询命令
127.0.0.1:6381> SLOWLOG get 2
1) 1) (integer) 6
   2) (integer) 1458734263
   3) (integer) 74372
   4) 1) "hgetall"
      2) "max.dsp.blacklist"
2) 1) (integer) 5
   2) (integer) 1458734258
   3) (integer) 5411075
   4) 1) "keys"
      2) "max.dsp.blacklist"

以第一个 HGET 命令为例分析,每个 slowlog 实体共 4 个字段:

  • 字段 1:1 个整数,表示这个 slowlog 出现的序号,server 启动后递增,当前为 6。
  • 字段 2:表示查询执行时的 Unix 时间戳。
  • 字段 3:表示查询执行微秒数,当前是 74372 微秒,约 74ms。
  • 字段 4: 表示查询的命令和参数,如果参数很多或很大,只会显示部分参数个数。当前命令是hgetall max.dsp.blacklist

Latency Monitoring

Redis 在 2.8.13 版本引入了 Latency Monitoring 功能,用于以秒为粒度监控各种事件的发生频率。

启用延迟监视器的第一步是设置延迟阈值(单位毫秒)。只有超过该阈值的时间才会被记录,比如我们根据基线性能(3ms)的 3 倍设置阈值为 9 ms。

可以用 redis-cli 设置也可以在 Redis.config 中设置;

如何解决 Redis 变慢?

Redis 的数据读写由单线程执行,如果主线程执行的操作时间太长,就会导致主线程阻塞。

一起分析下都有哪些操作会阻塞主线程,我们又该如何解决?

网络通信导致的延迟

客户端使用 TCP/IP 连接或 Unix 域连接连接到 Redis。1 Gbit/s 网络的典型延迟约为 200 us。

redis 客户端执行一条命令分 4 个过程:

发送命令-〉 命令排队 -〉 命令执行-〉 返回结果

这个过程称为 Round trip time(简称 RTT, 往返时间),mget mset 有效节约了 RTT,但大部分命令(如 hgetall,并没有 mhgetall)不支持批量操作,需要消耗 N 次 RTT ,这个时候需要 pipeline 来解决这个问题。

Redis pipeline 将多个命令连接在一起来减少网络响应往返次数。