redis慢查询日志的访问和管理

通过一组命令来实现对慢查询日志的访问和管理

（1）获取慢查询日志

命令：slowlog get

127.0.0.1:6379> slowlog get
1) 1) (integer) 1
   2) (integer) 1513709400
   3) (integer) 11
   4) 1) "slowlog"
      2) "get"
2) 1) (integer) 0
   2) (integer) 1513709398
   3) (integer) 4
   4) 1) "config"
      2) "set"
      3) "slowlog-log-slower-than"
      4) "2"

（2）获取慢查询日志列表当前的长度

命令：slowlog len

127.0.0.1:6379> slowlog len
(integer) 2

（3）慢查询日志重置

命令：slowlog reset

实际是对慢查询日志列表做清理操作。

127.0.0.1:6379> slowlog len
(integer) 6
127.0.0.1:6379> slowlog reset
OK
127.0.0.1:6379> slowlog len
(integer) 1
#为什么还有1个，因为阈值设的比较小，slowlog reset就属于慢查询

注意事项

慢查询功能可以有效的帮助我们找到Redis可能存在的瓶颈，但在实际使用过程中要注意以下几点：

（1）slowlog-max-len配置建议：线上建议调大慢查询列表，记录慢查询时Redis会对长命令做截断操作，并不会占用大量内存。

　　增大慢查询列表可以减缓慢查询被剔除的可能。

（2）slowlog-log-slower-than配置建议：默认值超过10毫秒判定为慢查询，需要根据Redis并发量调整该值。

　　由于Redis采用单线程响应命令，对于高流量的场景，如果命令执行时间在1毫秒以上，那么Redis最多可以支撑OPS不到1000，因此对于高OPS的场景的Redis建议设置1毫秒。

（3）慢查询只记录命令执行时间，并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行的时间。

　　因为命令执行排队机制，慢查询会导致其他命令级联阻塞，因此当客户端出现请求超时，

　　需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞。

（4）由于慢查询日志是一个先进先出的队列，也就是说如果慢查询比较多的情况下，可能会丢失部分慢查询命令，

　　为了防止这种情况发生，可以定期执行slowlog get命令将慢查询日志持久化到其他存储中（例如，MySQL），

　　然后可以制作出可视化界面进行查询。