为什么80%的码农都做不了架构师？>>> 
1、问题描述
某系统在2017/07/21监控高耗时交易时发现在两个时间点缓存操作耗时较高，详情如下：
时间点一:2017/07/21 15:24:51
| LogTime=2017-07-21 15:24:51.242 costTime=372.078ms class=com.dap.cache.api.CacheClien |
时间点二: 2017/07/21 15:31:16
| LogTime=2017-07-21 15:31:16.412 costTime=455.279ms class=com.dap.cache.api.CacheClient |
2、排查过程
2.1慢日志配置
生产环境redis配置了慢日志参数
查看redis慢日志配置，登陆redis服务器，使用redis-cli客户端连接redis server
| 127.0.0.1:6301> config get slow* 1) "slowlog-log-slower-than" 2) "10000" 3) "slowlog-max-len" 4) "1000" 127.0.0.1:6301> |
慢日志说明:
config get slow* 查询有关慢日志的配置信息
查询结果第一条: 1) "slowlog-log-slower-than" 慢日志阈值配置项
查询结果第二条: 2) "10000" 阈值 ,单位微秒，此处为10毫秒，即超过10毫秒的操作都会记录下来
查询结果第三条: 3) "slowlog-max-len" 慢日志记录保存数量，如果保存数量已满，会删除最早的记录，最新的记录追加进来
查询结果第四条: 4) "1000" 慢日志记录保存数量的阈值，此处保存1000条记录
查看慢日志记录
查看redis慢日志记录，登陆redis服务器，使用redis-cli客户端连接redis server
生产环境有三个节点，慢日志记录分别如下:
节点一:
| 127.0.0.1:6301> SLOWLOG GET 1) 1) (integer) 68 2) (integer) 1500873303 3) (integer) 25972 4) 1) "BGREWRITEAOF" 2) 1) (integer) 67 2) (integer) 1500778503 3) (integer) 25279 4) 1) "BGREWRITEAOF" 3) 1) (integer) 66 2) (integer) 1500680103 3) (integer) 24432 4) 1) "BGREWRITEAOF" 4) 1) (integer) 65 2) (integer) 1500621891 3) (integer) 1186934 4) 1) "keys" 2) "*CAP:*" 5) 1) (integer) 64 2) (integer) 1500621779 3) (integer) 1190078 4) 1) "keys" 2) "*" 6) 1) (integer) 63 2) (integer) 1500602102 3) (integer) 22998 4) 1) "BGREWRITEAOF" 7) 1) (integer) 62 2) (integer) 1500530702 3) (integer) 22807 4) 1) "BGREWRITEAOF" 8) 1) (integer) 61 2) (integer) 1500458102 3) (integer) 21908 4) 1) "BGREWRITEAOF" 9) 1) (integer) 60 2) (integer) 1500424802 3) (integer) 21208 4) 1) "BGREWRITEAOF" 10) 1) (integer) 59 2) (integer) 1500352202 3) (integer) 20436 4) 1) "BGREWRITEAOF" 127.0.0.1:6301> |
慢日志说明:
SLOWLOG GET 查询当前所有的慢日志记录
显示结果列表，最左侧 1) 到 10) 有10条记录
已第四条慢日志为例说明如下:
| 4) 1) (integer) 65 2) (integer) 1500621891 3) (integer) 1186934 4) 1) "keys" 2) "*CAP:*" |
| 4) 1) (integer) 65 | 值65数据类型为integer，表示该条日志的id |
| 2) (integer) 1500621891 | 值1500621891数据类型为integer，表示操作redis的unix时间戳，单位秒。 |
| 3) (integer) 1186934 | 操作耗时，单位微秒 |
| 4) 1) "keys" | 操作redis的命令 keys |
| 2) "*CAP:*" | 操作redis的命令keys 的参数，即查询所有包含CAP字符串的key |
把操作redis的unix时间戳换算成北京时间为 2017/7/21 15:24:51 ，与某系统交易耗时的日志时间点一吻合。某系统交易耗时时间点二的问题也是如此。
结论：
Redis命令keys * 、 keys *xxx* 会遍历所有key，以查找符合条件的key，当数据量较大时该命令比较耗时，因为redis是单线程，当该命令执行的过程当中会阻塞其他命令请求，如果此时应用系统请求redis，所有的请求都会等待。在生环境中，严禁使用keys * 、 keys *xxx*，最好的办法是禁用相关命令。
补充说明：慢日志中的"BGREWRITEAOF"是redis fork的另外的线程在执行aof文件重新，该操作不会影响应用对redis的读写请求。