Redis为什么变慢了？常见延迟问题定位与分析.docxVIP

Redis为什么变慢了？常见延迟问题定位与分析 2021-09-30 更多内容关注：fullstack888 Redis作为内存数据库，拥有格外高的功能，单个实例的QPS能够达到10W左右。但我们在使用Redis时，经常时不时会消灭访问延迟很大的情况，假如你不晓得Redis的内部实现原理，在排查问题时就会一头雾水。 很多时候，Redis消灭访问延迟变大，都与我们的使用不当或运维不合理导致的。 这篇文章我们就来分析一下Redis在使用过程中，经常会遇到的延迟问题以及如何定位和分析。 使用简单度高的命令 假如在使用Redis时，发觉访问延迟突然增大，如何进行排查？ 首先，第一步，建议你去查看一下Redis的慢日志。Redis供应了慢日志命令的统计功能，我们通过以下设置，就可以查看有哪些命令在执行时延迟比较大。 首先设置Redis的慢日志阈值，只要超过阈值的命令才会被记录，这里的单位是微妙，例如设置慢日志的阈值为5毫秒，同时设置只保留最近1000条慢日志记录： #?命令执行超过5毫秒记录慢日志 CONFIG SET slowlog-log-slower-than 5000 #?只保留最近1000条慢日志 CONFIG SET slowlog-max-len 1000 设置完成之后，全部执行的命令假如延迟大于5毫秒，都会被Redis记录下来，我们执行SLOWLOG get 5查询最近5条慢日志： :6379?SLOWLOG?get?5 1)?1)?(integer)?32693?#?慢日志ID 2)?(integer)?1593763337?#?执行时间 3)?(integer)?5299?#?执行耗时(微妙) 4)?1)?LRANGE?#?具体执行的命令和参数 2)?user_list_2000 3)?0 4)?-1 2)?1)?(integer)?32692 2)?(integer)?1593763337 3)?(integer)?5044 4)?1)?GET 2)?book_price_1000 ... 通过查看慢日志记录，我们就可以晓得在什么时间执行哪些命令比较耗时，假如你的业务经常使用O(n)以上简单度的命令，例如sort、sunion、zunionstore，或者在执行O(n)命令时操作的数据量比较大，这些情况下Redis处理数据时就会很耗时。 假如你的服务恳求量并不大，但Redis实例的CPU使用率很高，很有可能是使用了简单度高的命令导致的。 处理方案就是，不使用这些简单度较高的命令，并且一次不要猎取太多的数据，每次尽量操作少量的数据，让Redis可以准时处理前往。 存储大key 假如查询慢日志发觉，并不是简单度较高的命令导致的，例如都是SET、DELETE操作消灭在慢日志记录中，那么你就要怀疑能否存在Redis写入了大key的情况。 Redis在写入数据时，需要为新的数据安排内存，当从Redis中删除数据时，它会释放对应的内存空间。 假如一个key写入的数据格外大，Redis在安排内存时也会比较耗时。同样的，当删除这个key的数据时，释放内存也会耗时比较久。 你需要检查你的业务代码，能否存在写入大key的情况，需要评估写入数据量的大小，业务层应当避开一个key存入过大的数据量。 那么有没有什么方法可以扫描现在Redis中能否存在大key的数据吗？ Redis也供应了扫描大key的方法： redis-cli -h $host -p $port --bigkeys -i 0.01 使用上面的命令就可以扫描出整个实例key大小的分布情况，它是以类型维度来呈现的。 需要留意的是当我们在线上实例进行大key扫描时，Redis的QPS会突增，为了降低扫描过程中对Redis的影响，我们需要把握扫描的频率，使用-i参数把握即可，它表示扫描过程中每次扫描的时间间隔，单位是秒。 使用这个命令的原理，其实就是Redis在内部执行scan命令，遍历全部key，然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来猎取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。 而对于容器类型的key，只能扫描出元素最多的key，但元素最多的key不肯定占用内存最多，这一点需要我们留意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清楚的了解。 针对大key的问题，Redis官方在4.0版本推出了lazy-free的机制，用于异步释放大key的内存，降低对Redis功能的影响。即便这样，我们也不建议使用大key，大key在集群的迁移过程中，也会影响到迁移的功能，这个后面在引见集群相关的文章时，会再具体引见到。 集中过期 有时你会发觉，平常在使用Redis时没有延