Redis 慢查询原理

许多存储系统（例如MySQL）提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阈值，就将这条命令的相关信息（例如：发生时间、耗时、命令的详细信息）记录下来，Redis也提供了类似的功能。

如下图：慢查询只会记录执行命令的时间。

慢日志的存储

慢日志的存储是基本链表的。

慢查询配置

slowlog-log-slower-than：指定执行时间超过多少微秒(1秒等于1000000微秒) 的命令请求会被记录到日志上

slowlog-max-len：指定服务器最多保存多少条慢查询操作。


从上图可以看出慢日志的存储是以时间倒序存储的。从这点来看有点像list数据类型的lpush。

当慢查询日志超出3条时，最早的一条数据将会被移除。有点类似list数据类型的 brpop。

1) 1) (integer) 5      #标识ID
   2) (integer) 1635586821  # 时间戳
   3) (integer) 4		#命令运行的时间
   4) 1) "set"			#运行的命令
      2) "name"
      3) "b2"
   5) "127.0.0.1:33768"
   6) ""

扩展学习 pipeline

redis的客户端和服务器之间是通过TCP协议连接的，不论是客户端向redis发送命令还是客户端接收redis的执行结果，都需要网络通信，都需要一定时间，由于网络性能的不同往返时间也不同，大致的来说这个时间相当于redis处理一条简单命令（比如插入一个值到链表）的时间。如果我们执行较多的命令，一来一回，这个往返时间累加起来还是对性能有一定影响的。

由于redis是单线程，所以在执行多个命令时，都需要等待上一条命令执行完，才能执行下一条命令。因此，redis底层通信协议提供了对管道技术的支持。通过管道可以一次性发送多条命令并在执行完后一次性将结果返回,当一组命令中每条命令都不依赖于之前命令的执行结果时就可以将这组命令一起通过管道发出。管道通过减少客户端与Redis的通信次数来实现降低往返时延累计值的目的

未使用pipeline

使用pipeline

优点：
1.运行时间相对来说少了很多

缺点：
1.执行不具备原子性，所以可能会丢失数据。
2.因为命令等待也比较占内存