linux nredis内存击穿,【Redis运维】Redis为什么变慢了？Redis慢日志与性能优化

首先要明白慢属于一个主观感觉，每个人对慢的定义是不一样的，所以在确定Redis慢之前需要提供一个基线性能标准作为参考，然后根据Redis问题画像快速定位问题方向，然后再详细分析。比如遇到Redis响应变慢问题，对照着这张图就能发现属于Redis性能方向，然后再延续到阻塞、抖动或者是数据结构相关。根据画像图再分享一些常见的问题分析方法。

一、Redis info命令

通过info命令除了可以查看redis服务状态(参见还包含了一些和性能相关的指标需要关注，便于对Redis性能问题进行排查与故障解决。

1、memory模块——排查内存与碎片问题。该模块输出了内存相关信息，比如Redis占用了多少内存、最大可用内存以及内存碎片率等信息

· used_memory_human：把Redis使用的内存总量进行了统计，包含了实际缓存占用的内存和Redis自身运行所占用的内存(如元数据、lua)，但是不包含内存碎片

· used_memory_rss_human：这一项在上一项的基础上包含了内存碎片的统计。如果该值的统计数据大于了maxmemory所设置的值，说明Redis当前有使用swap虚拟内存，效率必然很低。为了避免Redis使用到swap交换内存，建议设置好Key的过期淘汰策略。如果key都有设置TTL过期时间，使用volatile-ttl回收策略最合适；如果没有设置过期时间，使用allkeys-lru比较合适，它会从所有key中挑选最近最少使用的key进行删除(LRU淘汰算法)。

· mem_fragmentation_ratio： 内存碎片率由use_memory_rss除以user_memory所得到，内存碎片率越高，说明未回收的内存越多，意味着浪费的内存空间也就越大。通常来说内存碎片率稍大于1是合理的，如果超过1.5表Redis消耗了实际需要物理内存的150%，有50%都是碎片。若是内存碎片率低于1的话，说明Redis能申请的内存已经达不到期望值，有可能是系统内存不够用了使用了SWAP分区。如果要清理碎片的话需要对Redis进行一次重启操作，让内存碎片失效并重新作为新内存来使用。在重启服务之前可以手动save一次redis数据，这样能保证在执行Redis关闭时不丢失任何数据。修改redis内存分配器也能带来一定的优化效果。Redis支持glibc、jemalloc、tcmalloc几种不同的内存分配器，每个分配器在内存分配和碎片上都有不同的实现。通常使用redis默认的jemalloc内存分配器即可。

· mem_allocator：Redis使用的内存分配器，可以是libc、jemalloc、tcmalloc。libc的性能最次。

· maxmemory_human：Redis最大可使用的内存限制。虽然used_memory_human的值会受到它的限制(比如配置了maxmemory_human为2G，used_memory_human会限制在2G内)，但是因为碎片问题used_memory_rss_human会突破限制。带来的直接问题就是如果maxmemory_human配置的和系统最大内存接近容易发生OOM

2、stats模块——结合慢日志排查复杂度过高的命令带来的慢查询问题

· total_commands_processed参数：对Redis服务处理命令的数量进行统计，这是排查延迟问题的关键值，因为Redis是在单线程模型下工作，会把接收到的客户端命令按顺序执行，如果执行命令过多或者存在很多慢命令就会让整个队列阻塞而导致延迟。由于total_commands_processed的值是递增的，所以要使用Zabbix做监控的话需要统计的是每秒的差值，这样才能知道每秒处理总数是上升还是下降，以便排查。

3、高复杂度的命令

二、Redis慢查询的设置与使用

1、设置Redis慢日志

如果在使用Redis时发现访问延迟突然增大，第一步建议检查Redis慢日志。Redis提供了慢日志命令的统计功能，只需要打开该功能就会记录符合条件的慢日志

# 命令执行超过1秒记录慢日志

CONFIG SET slowlog-log-slower-than 1000000

# 只保留最近1000条慢日志

CONFIG SET slowlog-max-len 1000

2、查询Redis慢日志

redis > slowlog get #显示当前所有慢命令

redis > slowlog get 100 #查看最新的100个慢命令

3、分析Redis慢日志

1>：该行是日志的唯一标识符

2>：该行记录命令的执行时间点，以 UNIX 时间戳格式表示

3>：该行记录命令执行耗时，以微秒为单位。例子中命令使用54毫秒

4>：该行记录执行的具体命令，以数组的形式排列。图上完整命令是config get *

4、清空Redis慢查询日志

127.0.0.1:6379> slowlog reset

OK

5、解决慢日志带来的问题

如果业务经常使用O(n)以上复杂度的命令，例如sort、sunion、zunionstore，或者在执行O(n)命令时操作的数据量比较大，这些情况下Redis处理数据时就会很耗时。如果服务请求量并不大，但Redis实例的CPU使用率很高，很有可能是使用了复杂度高的命令导致的。解决方案就是不使用这些复杂度较高的命令，并且一次不要获取太多的数据，每次尽量操作少量的数据，让Redis可以及时处理返回。另可以定期检查Redis慢查询日志，以便及时发现和改进 Redis在运行中的不合理操作。

三、其它导致性能降低的问题

1、网卡负载过高，如对一个Big key进行大量请求或者高并发请求某个Key都可能导致流量异常。比如一个10K的Key被请求了上万次，那么就是接近百M的流量了

2、缓存雪崩：属于"面"，Key集中过期导致导致大量并发请求到数据库上，在删除大量Key的时候必然会产生阻塞

3、缓存穿透：当缓存和数据库中都不存在数据时，每次请求都会先查询Redis，然后再查询数据库。可以通过布隆过滤器或者前端限流来避免

4、缓存击穿：属于"点"，某个热点数据在Redis中失效，导致大并发请求到数据库上。可以通过将热点数据设置永不过期来防止该问题(需和业务确认)

5、使用了swap