Redis调优

一 . redis为什么感觉变慢了？

众所周知 Redis 是单线程，有着极快的响应速度，但是有一天 Redis 突然变"慢"了，运维甚至开发都慌了，开始一系列的骚操作了，但是一点效果都没有，why？

遇到问题不要慌。首先需要确定的是：Redis真的变慢了吗？

今天就来介绍下以什么标准为基线判断Redis变慢了？

首先进行基准性能测试。目的是为了测试是否真的变慢。

延迟是根据自己的机器配置来判断。首先直接在redis服务器上门测试延迟情况，判断是业务服务器延迟还是redis服务器延迟（一台redis的不用区分）。

执行命令

从 2.8.7 版本开始，redis-cli 命令提供了–intrinsic-latency选项，可以用来监测和统计测试期间内的最大延迟，这个延迟可以作为 Redis 的基线性能。

例如120秒。（一般情况下 120s足够监测到最大延迟了）在指定的时间段内，redis-cli会记录每个秒级的最大延迟。这个最大延迟可以反映出Redis本身的性能，不受网络或其他外部因素的影响。

./redis-cli --intrinsic-latency 120
Max latency so far: 17 microseconds.
Max latency so far: 44 microseconds.
Max latency so far: 94 microseconds.
Max latency so far: 110 microseconds.
Max latency so far: 119 microseconds.
 
 
36481658 total runs (avg latency: 3.2893 microseconds / 3289.32 nanoseconds per run).
Worst run took 36x longer than the average latency.

从输出结果可以看到，这 120 秒内的最大响应延迟为 119 微秒（0.119毫秒），就可以把这个定位基线性能。

如果运行的延迟是基线性能的两倍及以上，就可判断出redis是真的变慢了！

切记：一定要在本机上运行测试命令，如果通过客户端则需要考虑网络性能的影响。

你还可以使用以下命令，查看一段时间内 Redis 的最小、最大、平均访问延迟。

$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range

好了，到这一步如果能确定redis已经发生了延迟变慢，现在就要确定原因了。

Redis 自身的操作特性、文件系统和操作系统，它们是影响 Redis 性能的三大要素

 

一个一个分析，先从本身操作特性来说：

第一个特性：慢指令特性查询

当redis性能变慢的时候，可以通过REDIS日志（showlog），或者latency monitor工具，查询变慢的请求，然后根据请求对应的具体命令以及官方文档，确认是否采用了复杂度高的慢查询命令。（如何查询可以参考redis工具使用redis命令解释-showlog showlog如何配置）工具的作用可以查出时间超过N秒的M条命令。默认情况下命令执行时间超过 10ms 就会被记录到日志，这个只记录执行时间，摒弃了 io 往返或者网络延迟引起的响应慢部分。

如果的确有大量慢查询命令，已知又两种处理方式：

1. 用其他高校命令代替。
2. 当需要排序，交集，并集等操作的时候，可以在客户端完成，而不用sort，sunion，sinter等命令，以免拖慢redis实例。（使用SORT、SUNION和SINTER这些命令可能会增加Redis实例的负载，从而减慢性能。下面是具体原因：
3. SORT命令：SORT命令用于排序集合中的元素。由于需要对大量数据进行排序操作，可能会耗费大量的CPU和内存资源。因此，在大规模数据集上使用SORT命令可能导致Redis实例的速度变慢。
4. SUNION和SINTER命令：SUNION命令用于计算多个集合的并集，SINTER命令用于计算多个集合的交集。这两个命令也需要对多个集合进行计算，可能会引起相当大的计算开销，并且需要消耗额外的内存容量。如果处理的集合很大，那么这些命令可能会导致Redis实例的性能下降。

为了避免这种情况发生，我们可以考虑以下建议：

• 使用有序集合（Sorted Set）代替使用SORT命令，有序集合在插入和获取数据时具有较高的性能。
• 在客户端而不是服务器端执行集合的并集和交集计算，减轻Redis实例的压力。
• 对于大型数据集，可以采用分布式方式将数据拆分到多个Redis实例，从而提高整体性能。

1. 总之，为了保持Redis实例的性能，请谨慎使用SORT、SUNION和SINTER等可能增加负载的命令，并根据实际需求进行优化和拆分。）