第三章:小功能大用处-慢查询分析

这一章书本上的内容有:

  • 慢查询分析:通过慢查询分析,找到有问题的命令进行优化。
  • Redis Shell:功能强大的Redis Shell会有意想不到的实用功能。
  • Pipeline:通过Pipeline(管道或者流水线)机制有效提高客户端性能。
  • 事务与Lua:制作自己的专属原子命令。
  • Bitmaps:通过在字符串数据结构上使用位操作,有效节省内存,为开发提供新的思路。
  • HyperLogLog:一种基于概率的新算法,难以想象地节省内存空间。
  • 发布订阅:基于发布订阅模式的消息通信机制。
  • GEO:Redis3.2提供了基于地理位置信息的功能。
    这里我只会记录其中的慢查询分析、Redis Shel、Pipeline和发布订阅。

3.1 慢查询分析

许多存储系统(例如MySQL)提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间,当超过预设阀值,就将这条命令的相关信息(例如:发生时间,耗时,命令的详细信息)记录下来,Redis也提供了类似的功能。
如图3-1所示,Redis客户端执行一条命令分为如下4个部分:


第三章:小功能大用处-慢查询分析_第1张图片
一条客户端命令的生命周期

需要注意,慢查询只统计步骤3)的时间,所以没有慢查询并不代表客户端没有超时问题。

3.1.1 慢查询的两个配置参数

对于慢查询功能,需要明确两件事:

  • 预设阀值怎么设置?
  • 慢查询记录存放在哪?
    Redis提供了slowlog-log-slower-than和slowlog-max-len配置来解决这两个问题。从字面意思就可以看出,slowlog-log-slower-than就是那个预设阀值,它的单位是微秒(1秒=1000毫秒=1000000微秒),默认值是10000,假如执行了一条“很慢”的命令(例如keys*),如果它的执行时间超过了10000微秒,那么它将被记录在慢查询日志中。
    如果slowlog-log-slower-than=0会记录所有的命令,slowlog-log-slowerthan<0对于任何命令都不会进行记录。
    从字面意思看,slowlog-max-len只是说明了慢查询日志最多存储多少条,并没有说明存放在哪里?实际上Redis使用了一个列表来存储慢查询日志,slowlog-max-len就是列表的最大长度。一个新的命令满足慢查询条件时被插入到这个列表中,当慢查询日志列表已处于其最大长度时,最早插入的一个命令将从列表中移出,例如slowlog-max-len设置为5,当有第6条慢查询插入的话,那么队头的第一条数据就出列,第6条慢查询就会入列。
    在Redis中有两种修改配置的方法,一种是修改配置文件,另一种是使用config set命令动态修改。例如下面使用config set命令将slowlog-log-slowerthan设置为20000微秒,slowlog-max-len设置为1000:
config set slowlog-log-slower-than 20000
config set slowlog-max-len 1000
config rewrite

如果要Redis将配置持久化到本地配置文件,需要执行config rewrite命令
虽然慢查询日志是存放在Redis内存列表中的,但是Redis并没有暴露这个列表的键,而是通过一组命令来实现对慢查询日志的访问和管理。下面介绍这几个命令。

  1. 获取慢查询日志
slowlog get [n]

操作返回当前Redis的慢查询,参数n可以指定条数.慢查询日志里面的参数这里不做介绍。

  1. 获取慢查询日志列表当前的长度
slowlog len
  1. 慢查询日志重置
slowlog reset

3.1.2 最佳实践

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

  • max-len配置建议:线上建议调大慢查询列表,记录慢查询时Redis会对长命令做截断操作,并不会占用大量内存。增大慢查询列表可以减缓慢查询被剔除的可能,例如线上可设置为1000以上。
  • slowlog-log-slower-than配置建议:默认值超过10毫秒判定为慢查询,需要根据Redis并发量调整该值。由于Redis采用单线程响应命令,对于高流量的场景,如果命令执行时间在1毫秒以上,那么Redis最多可支撑OPS不到1000。因此对于高OPS场景的Redis建议设置为1毫秒。
  • 慢查询只记录命令执行时间,并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制,慢查询会导致其他命令级联阻塞,因此当客户端出现请求超时,需要检查该时间点是否有对应的慢查询,从而分析出是否为慢查询导致的命令级联阻塞。
  • 由于慢查询日志是一个先进先出的队列,也就是说如果慢查询比较多的情况下,可能会丢失部分慢查询命令,为了防止这种情况发生,可以定期执行slow get命令将慢查询日志持久化到其他存储中(例如MySQL),然后可以制作可视化界面进行查询.

你可能感兴趣的:(第三章:小功能大用处-慢查询分析)