如何用慢查询找到 Redis 的性能瓶颈？
【作者】姜文浩，从事银行业务系统开发运维多年，前期偏向于传统的业务中间件、消息中间件以及SOA、ESB架构，近期逐渐转向于分布式架构以及开源中间件、NoSQL 数据库等，在系统优化、系统架构方面有着一定经验。
Redis数据库是一个基于内存的 key-value存储系统，现在redis最常用的使用场景就是存储缓存用的数据，在需要高速读/写的场合使用它快速读/写，从而缓解应用数据库的压力，进而提升应用处理能力。
由于Redis的单线程架构，所以需要每个命令能被快速执行完，否则会存在阻塞Redis的可能，理解Redis单线程命令处理机制是开发和运维Redis的核心之一。
许多数据库会提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当然在数据库中最常见的就是select这些sql语句了，当超过预设阀值，就将这条命令的相关信息（例如：发生时间，耗时，命令的详细信息）记录下来，Redis也提供了类似的功能。
那么如何使用Redis所提供的慢查询功能呢？Redis主要提供了slowlog-log-slower-than和slowlog-max-len两个配置参数来提供这项功能。两项参数分别用来设置慢查询的阈值以及存放慢查询的记录。首先对redis的这两个配置进行一个说明 ：
从字面意思就可以看出，可以通过slowlog-log-slower-than参数设置什么情况下是慢语句，只有redis命令执行时间大于slowlog-log-slower-than的才会定义成慢查询，才会被slowlog进行记录。它的单位是微秒（1秒=1000毫秒=1000000微秒），在初始情况下默认值是10000，也就是10ms，假如执行了一条比较慢的命令，如果它的执行时间超过了 10ms ，那么它将被记录在慢查询日志中。（如果slowlog-log-slower-than=0会记录所有的命令，slowlog-log-slower than<0对于任何命令都不会进行记录）
从字面意思看，slowlog-max-len说明了慢查询日志最多可以存储多少条记录，实际上Redis使用了一个列表来存储慢查询日志，slowlog-max-len就是列表的最大长度，它自身是一个先进先出队列，当slowlog超过设定的最大值后，会将最早的slowlog删除。简而言之当一个新的命令满足慢查询条件时会被插入到这个列表中，当慢查询日志列表已处于其最大长度时，最早插入的一个命令将从列表中移出，例如slowlog-max-len设置为 50 ，当有第51条慢查询插入的话，那么队头的第一条数据就出列，第51条慢查询就会入列。
接下来详细介绍一下如何配置这两个参数，有两种方式进行配置，以下截图全部使用了redis -5.0.5版本 ：
方式一：通过配置redis.conf文件进行配置。
通过修改redis .conf文件之后重启redis服务 ， 配置即可生效 。
方式二：通过CONFIG命令进行动态配置
配置查询时间超过1毫秒的命令进行记录
保存500条慢查记录
通过config get命令确认配置已生效
要注意通过config命令配置的为动态生效 ， 一旦服务重启则会重新恢复为默认设置 ， 所以建议在排查问题时通过config这种方式进行配置 ， 但是服务稳定后通过修改配置文件方式进行最终确认 （可以通过config rewrite命令持久化到本地文件 ， 但要主要启动redis时要指定redis . conf文件 该命令才可以生效）。
相关的参数已经设置完成了 ， 那么如何查看记录的信息呢 ？要想查看所记录的日志 ， 主要使用 SLOWLOG GET 或者 SLOWLOG GET number 命令，前者将会输出所有的 slow log ，最大长度取决于 slowlog-max-len 选项的值，而 SLOWLOG GET number 则只打印指定数量的日志。
查看当前日志数量: 使用SHOW LEN命令查看日志数量。
因为我是新安装的redis ， 所以现在还没有耗时长日志 ， 所以条数是 0，如果日志条数过多，还可以使用slowlog reset命令进行日志清空 。
为了方便演示 ，我将所有的执行命令都记录了下来，以第一条为例，
1、(integer) 1 # 唯一性(unique)的日志标识符
2、(integer) 1562075522 # 被记录命令的执行时间点，以 UNIX 时间戳格式表示
3、(integer) 93 # 查询执行时间，以微秒为单位
4、1."CONFIG" # 执行的命令，以数组的形式排列
5、"GET"
6、" " # 这里完整的命令是 CONFIG GET
慢查询功能可以有效地帮助我们找到Redis可能存在的瓶颈，但在实际使用过程中要注意以下几点：
slowlog-max-len配置建议：线上建议调大慢查询列表，记录慢查询时 Redis会对长命令做截断操作，并不会占用大量内存。增大慢查询列表可以减缓慢查询被剔除的可能，例如线上可设置为 2000 以上（5.0.5版本默认为128）。
slowlog-log-slower-than配置建议：默认值超过10毫秒判定为慢查询，需要根据Redis并发量调整该值。由于Redis采用单线程响应命令，对于高流量的场景，如果命令执行时间在1毫秒以上，那么Redis最多可支撑OPS不到1000。因此对于高OPS场景的Redis建议设置为1毫秒（OPS指每秒操作次数）。
慢查询只记录命令执行时间，并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制，慢查询会导致其他命令级联阻塞，因此当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞。
由于慢查询日志是一个先进先出的队列，也就是说如果慢查询比较多的情况下，可能会丢失部分慢查询命令，为了防止这种情况发生，可以定期执行slow get命令将慢查询日志持久化到其他存储中，然后可以进行相关的监控、告警、分析工作。
原题：Redis 性能瓶颈分析之慢查询 如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
Redis最佳实践——以支付标记化为例
http://www.talkwithtrend.com/Article/240587
redis性能测试与监控
http://www.talkwithtrend.com/Article/244927
Redis选型、调优、监控、数据一致性等四大难点
http://www.talkwithtrend.com/Article/244303
欢迎关注社区以下技术主题，将会不断更新优质资料、文章。地址：
Redis：http://www.talkwithtrend.com/Topic/91
分布式数据库：http://www.talkwithtrend.com/Topic/37323
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场