Redis是不是真的变慢了?

本文主要是介绍Redis是不是真的变慢了?，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

大家好，今天我们来学习一下如何确定Redis是不是真的变慢了。

我们在使用redis时一定会遇到变慢的时候，那我们如何来判断Redis是否真的变慢了呢， 一个最直接的方法就是查看Redis的响应延迟，一般情况下，Redis延迟很低，但是在某些时刻， Redis实例会出现比较高的响应延迟，甚至能达到几秒到十几秒，当你发现Redis命令的执行时间突然就增长到了几秒，基本就可以认定 Redis 变慢了。这种方法是看 Redis 延迟的绝对值。当我们不能根据延迟的绝对值来判断redis是否真的变慢了，我们还有一种方法可以判断，那就是redis的基线性能。

redis从2.8.7版本开始，redis-cli命令提供了–-intrinsic-latency 选项，可以用来监测和统计测试期间内的最大延迟，这个延迟可以作为 Redis 的基线性能。其中，测试时长可以用–-intrinsic-latency 选项的参数来指定。比如我们执行redis-cli –-intrinsic-latency 30这个命令，该命令会打印出30秒内检测到的最大延迟。如下所示，这里的最大延迟是3595微妙，所以我们把该redis实例的基线性能是3595微妙。

./redis-cli –-intrinsic-latency 30

Max latency so far: 1 microseconds.
Max latency so far: 4 microseconds.
Max latency so far: 14 microseconds.
Max latency so far: 33 microseconds.
Max latency so far: 48 microseconds.
Max latency so far: 51 microseconds.
Max latency so far: 100 microseconds.
Max latency so far: 110 microseconds.
Max latency so far: 488 microseconds.
Max latency so far: 944 microseconds.
Max latency so far: 1590 microseconds.
Max latency so far: 1921 microseconds.
Max latency so far: 3595 microseconds.

584098163 total runs (avg latency: 0.0514 microseconds / 51.36 nanoseconds per run).
Worst run took 69994x longer than the average latency.

    一般来说，当你观察到Redis运行时延迟是其基线性能的2倍及以上，就可以认定 Redis 变慢了。在确定Redis变慢之后，我们需要去进一步去排查Redis变慢的原因。

    我们不能没有章法的去排查redis是如何变慢的，我们需要基于自己对Redis本身的工作原理的理解， 并且结合和它交互的操作系统、存储以及网络等外部系统关键机制，再借助一些辅助工具来定位原因，并制定有效的解决方案。 影响Redis性能的三大要素是Redis自身的操作特性、文件系统和操作系统。下面我们来分别看一下。

Redis自身操作特性的影响：

下面我们重点介绍两个常见的操作，这两个操作是经常导致redis变慢的罪魁祸首。

1.慢查询命令

当redis变慢时，我们可以通过日志或者latency monitor工具来查看Redis中查询变慢的请求，然后根据请求对应的具体命令以及官方文档，确认下是否采用了复杂度高的慢查询命令。如果的确有大量的慢查询命令，有两种处理方式：

1. 用其它高效命令代替。
2. 当你需要执行排序、交集、并集操作时，可以在客户端完成，而不要用 SORT、SUNION、SINTER 这些命令，以免拖慢 Redis 实例。

2.过期key操作

我们可以对edis的键值对设置过期时间。默认情况下，Redis每100毫秒会删除一些过期key，具体的算法如下：

1. 采样ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 个数的 key，并将其中过期的 key 全部删除；

2. 如果超过 25% 的 key 过期了，则重复删除的过程，直到过期 key 的比例降至 25% 以下。

   如果我们同一时间有大量过期的key要删除，就会触发第二条策略，Redis 就会一直删除以释放内存空间。注意，删除操作是阻塞的（Redis 4.0 后可以用异步线程机制来减少阻塞影响）。所以，一旦该条件触发，Redis 的线程就会一直执行删除，这样一来，就没办法正常服务其他的键值操作了，就会进一步引起其他键值操作的延迟增加，Redis 就会变慢。所以我们需要避免给一批key设置相同的过期时间，

如果业务上确实需要一批key同时过期，我们可以在EXPIREAT 和 EXPIRE 的过期时间参数上 加上一个一定大小范围内的随机数，这样，既可以保证key 在一个邻近时间范围内被删除，又避免了同时过期造成的压力。

文件系统：AOF日志

Redis会采用AOF日志或者RDB来保证数据的可靠性。其中AOF日志提供了三种日志写回策略： no、everysec、always。这三种写回策略依赖文件系统的两个系统调用，也就是write和fsync。write 只要把日志记录写到内核缓冲区，就可以返回了，并不需要等待日志实际写回到磁盘；而fsync 需要把日志记录写回到磁盘后才能返回，时间较长。下面这张表展示了三种写回策略所执行的系统调用：

当AOF配置成everysec时，Redis允许丢失一秒的操作记录，所以Redis主线程不需要确保每个操作记录日志都写回到磁盘。所以，当配置为everysec时，Redis是使用后台的子线程异步完成fsync的操作。当AOF配置成always时，Redis需要确保每个操作记录日志都写回磁盘，如果采用后台子线程异步完成，主线程就无法及时地知道每个操作是否已经完成了。这就不符合 always 策略的要求了。所以，always 策略并不使用后台子线程来执行。

我们在这里知道，Redis持久化机制在使用 AOF 日志时，为了避免日AOF志文件变得太大，Redis 会采用后台子进程来进行AOF重写。但是，这里会出现一个风险点，AOF重写会对磁盘进行大量的IO操作，同时fsync需要等到数据写入到磁盘后才会返回。所以，当AOF重新操作磁盘压力比较大时，就会导致fsync被阻塞。尽管fsync是由后台子线程负责执行的，但是，主线程会监控fsync的执行进度。当主线程使用后台子线程执行了一次 fsync，需要再次把新接收的操作记录写回磁盘时，如果主线程发现上一次的 fsync 还没有执行完，那么它就会阻塞。所以，如果后台子线程执行的 fsync 频繁阻塞的话主线程也会阻塞，导致 Redis 性能变慢。

到目前为止，你已经知道了，当AOF重写导致磁盘压力大时，就会导致fsync阻塞，进而阻塞主线程 ，导致延迟增加。下面我们来看如何排查和解决这个问题。首先，我们可以先检查配置文件中的 appendfsync配置项，查看AOF的写入策略是什么样的。

如果我们的业务方对Redis的延迟很敏感，但是可以允许有一定数据的数据丢失，我们可以设置no-appendfsync-on-rewrite为yes

no-appendfsync-on-rewrite yes

这个配置项设置为 yes 时，表示在 AOF 重写时，不进行 fsync 操作。也就是说，Redis 实例把写命令写到内存后，不调用后台线程进行 fsync 操作，就可以直接返回了。当然，如果此时实例发生宕机，就会导致数据丢失。反之，如果这个配置项设置为 no（默认配置），在 AOF 重写时，Redis 实例仍然会调用后台线程进行 fsync 操作，这就会给实例带来阻塞。如果业务方既需要低延迟也需要高可靠性，我们可以采用固态硬盘作为AOF日志的写入设备。

操作系统：

1.内存swap。

内存 swap 是操作系统里将内存数据在内存和磁盘间来回换入和换出的机制，会涉及到磁盘的读写，所以，一旦触发 swap，其性能都会受到慢速磁盘读写的影响。

Redis是内存数据库，如果没有控制好内存的使用量，就可能会引起操作系统的swap。一旦swap被触发了，Redis的读写操作就会有可能请求到磁盘，从而影响Redis的主线程执行，所以会增大Redis的响应时间。

操作系统触发swap机制，主要是因为物理机的内存不足导致的，所以，当发现操作系统进行了内存swap,最直接的处理方式就是增加物理机的内存大小。

2.内存大页机制。

我们先来看看什么是内存大页？我们都知道，应用程序向操作系统申请内存时，是按内存页进行申请的，而常规的内存页大小是 4KB。Linux 内核从 2.6.38 开始，支持了内存大页机制，该机制允许应用程序以 2MB 大小为单位，向操作系统申请内存。 我们在Redis持久化机制里知道，Redis的持久化是采用写时复制的，也就是说，一旦有数据要被修改，Redis 并不会直接修改内存中的数据，而是将这些数据拷贝一份，然后再进行修改。

如果采用了内存大页，那么，即使客户端请求只修改 1kb 的数据，Redis 也需要拷贝 2MB 的大页。相反，如果是常规内存页机制，只用拷贝 4KB。两者相比，你可以看到，当客户端请求修改或新写入数据较多时，内存大页机制将导致大量的拷贝，这就会影响 Redis 正常的访存操作，最终导致性能变慢。解决这个问题的方式，就是关闭大页机制。

我们在linux执行

cat /sys/kernel/mm/transparent_hugepage/enabled

如果是always,就表明启动了内存大页机制，我们执行

echo never /sys/kernel/mm/transparent_hugepage/enabled

来关闭内存大页机制就好了。

今天的分享就到这里。更多硬核知识，请关注公众号“程序员学长”。

这篇关于Redis是不是真的变慢了?的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！