redis性能调优

1.根据链路追踪判断是不是操作redis操作

你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。

判断到redis服务之间的网络延迟

1. ** 60s内最大的延迟时间 **
   命令 redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
   2.** 查看一段时间内 Redis 的最小、最大、平均访问延迟 **
   命令 redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1

运行延迟是正常 Redis 基准性能的 2 倍以上，即可认为这个 Redis 实例确实变慢了

** 使用复杂度过高的命令 **

1. 去查看一下 Redis 的慢日志（slowlog）
   命令执行耗时超过 5 毫秒，记录慢日志
   CONFIG SET slowlog-log-slower-than 5000
   只保留最近 500 条慢日志
   CONFIG SET slowlog-max-len 500
   导致操作延迟变大：

经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令
使用 O(N) 复杂度的命令，但 N 的值非常大
第一种情况导致变慢的原因在于，Redis 在操作内存数据时，时间复杂度过高，要花费更多的 CPU 资源。

第二种情况导致变慢的原因在于，Redis 一次需要返回给客户端的数据过多，更多时间花费在数据协议的组装和网络传输过程中。

另外，我们还可以从资源使用率层面来分析，如果你的应用程序操作 Redis 的 OPS 不是很大，但 Redis 实例的 CPU 使用率却很高，那么很有可能是使用了复杂度过高的命令导致的。
Redis 是单线程处理客户端请求的，如果你经常使用以上命令，那么当 Redis 处理客户端请求时，一旦前面某个命令发生耗时，就会导致后面的请求发生这种情况如何解决呢？

答案很简单，你可以使用以下方法优化你的业务：

尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做
执行 O(N) 命令，保证 N 尽量的小（推荐 N <= 300），每次获取尽量少的数据，让 Redis 可以及时处理返回排队，对于客户端来说，响应延迟也会变长。
** 操作bigkey **
如果已经写入了 bigkey，扫描出实例中 bigkey 的分布情况:
redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01
当执行这个命令时，要注意 2 个问题：

对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒
扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出元素最多的 key。但一个 key 的元素多，不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况
那针对 bigkey 导致延迟的问题，有什么好的解决方案呢？

这里有两点可以优化：

业务应用尽量避免写入 bigkey
如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作，放到后台线程中去执行，从而降低对 Redis 的影响
如果你使用的 Redis 是 6.0 以上版本，可以开启 lazy-free 机制（lazyfree-lazy-user-del = yes），在执行 DEL 命令时，释放内存也会放到后台线程中执行
** 集中过期 **
** 实例内存达到上限 **
当 Redis 内存达到 maxmemory 后，每次写入新的数据之前，Redis 必须先从实例中踢出一部分数据，让整个实例的内存维持在 maxmemory 之下，然后才能把新数据写进来
** fork耗时严重 **

Redis 在 6.0 版本已经推出了新功能，可以通过配置，对主线程、后台线程、后台 RDB 进程、AOF rewrite 进程，绑定固定的 CPU 逻辑核心