前段时间，我司内网环境发生了一件有关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的游标