前段时间,我司内网环境发生了一件有关Redis
阻塞的事情。由于公司业务规模较大,很多数据保存在Redis
中,测试人员压测时,压测结果总是不尽人意,出现大批量的timeout
的情况,查看服务器时发现CPU
飙升,导致请求处理缓慢。经过一番努力,终于找到了事情的源头,新来的开发在本地调试RedisTemplate
,这不是重点,重点在于他执行的是keys
的模糊匹配,导致Redis
阻塞,从而影响压测,好在这仅仅是在内网环境,如果在外网环境使用模糊匹配等耗时的命令,后果不堪设想。
Redis是单线程的,这个特性再重点标记一下,单线程意味着任何一条命令的执行都是串行的,也就是按顺序一条一条的执行。那么当你执行的命令耗时就会导致后续的Redis
访问都会阻塞。
对于Redis
的keys * 、flushdb、flushall
等耗时命令,我们应当慎用,或者禁止使用,这类命令我们可以配置redis.conf
禁用这些命令
对于时间复杂度为O(n)
的数据操作命令,也应该根据自己的数据量使用,命令如下:
List: lindex、lset、linsert
Hash: hgetall、hkeys、hvals
Set: smembers、sunion、sunionstore、sinter、sinterstore、sdiff、sdiffstore
Sorted Set: zrange、zrevrange、zrangebyscore、zrevrangebyscore、zremrangebyrank、zremrangebyscore
使用scan替代keys命令
scan
命令用来分批次扫描Redis
记录,保证Redis
不会因为耗时导致服务不可用。
语法:
scan cursor [MATCH pattern] [COUNT count]
案例:
scan 0 match report:* count 10
1) "3932160"
2) 1) "report:12360412"
2) "report:12749274"
scan 第一个参数是游标,表示从游标开始
返回的第一行是游标,第二行是匹配到的数据,
如果第一行返回0,表示没有更多数据,否则下次使用scan时,就要用第一行返回的值作为scan的游标