本文基于Redis 6.0.9版本，前提至少 Redis 3.0或更高版本。
目录
1.Redis延迟监控框架
1.1.事件和时间序列
1.2.如何启用延迟监控
1.3.使用LATENCY命令进行信息报告
1.Redis延迟监控框架
Redis通常用于要求苛刻的用例环境中，在这种情况下，每个实例每秒处理大量查询，并且同时，对于平均响应时间和最坏情况下的延迟都有非常严格的延迟要求。
虽然Redis是内存系统，但是它以不同的方式处理操作系统，例如，在持久化到磁盘的情况下。 此外，Redis实现了丰富的命令集。 某些命令是快速的并且以恒定或对数(logarithmic)时间运行，其他命令是较慢的O(N) 命令，这会导致延迟峰值。
最终，Redis是单线程的：从每个内核可以执行的工作量的角度来看，这通常是一个优势，并且在延迟数据方面它可以提供，但是同时从延迟的角度来看，这也带来了挑战，因为单线程必须能够以不影响所服务的其他客户端的方式递增地执行某些任务，例如键到期。
由于所有这些原因，Redis 2.8.13引入了一项称为“延迟监视（Latency Monitoring）”的新功能，该功能可帮助用户检查并解决可能的延迟问题。 延迟监视由以下概念部分组成：
- 延迟挂钩对不同的延迟敏感代码路径进行采样。
- 延迟尖峰的时间序列记录按不同事件拆分。
- 报告引擎从时间序列中获取原始数据。
- 分析引擎根据测量结果提供可读的报告和提示。
本文档的其余部分介绍了延迟监视子系统的详细信息，但是，有关Redis和延迟的一般主题的更多信息，请阅读本文档中的Redis延迟问题故障排除页面。
1.1.事件和时间序列
不同的受监视代码路径具有不同的名称，称为事件（events）。 例如，command 是一个事件，用于测量可能执行缓慢命令的延迟峰值，而fast-command是用于监视 O(1)和O(log N) 命令的事件名称。 其他事件的通用性较低，它们监视由Redis执行的非常具体的操作。 例如，fork事件仅监视Redis执行fork(2)系统调用所花费的时间。
延迟峰值是比配置的延迟阈值更长的时间运行的事件。 每个监视事件都有一个独立的时间序列。 时间序列是这样工作的：
- 每次发生延迟尖峰时，都会将其记录在适当的时间序列中。
- 每个时间序列由160个元素组成。
- 每个元素都是一对：测量延迟峰值的时间的Unix时间戳，以及事件执行所花费的毫秒数。
- 合并在同一秒内发生的同一事件的延迟峰值（通过采用最大延迟），因此，即使为给定事件测量了连续的延迟峰值，例如由于用户设置了非常低的阈值，也至少需要历史的180秒是可用。
- 对于每个元素，都会记录所有时间的最大延迟。
框架监视并记录这些事件的执行时间中的延迟峰值：
-
command: 常规命令. -
fast-command: O(1) 和 O(log N) 命令. -
fork: 系统调用fork(2). -
rdb-unlink-temp-file: 系统调用unlink(2). -
aof-write: 写入AOF - 捕获系统调用事件fsync(2). -
aof-fsync-always: 由appendfsync allways策略被调用时，系统调用fsync(2). -
aof-write-pending-fsync: 当挂起的写入时，系统调用执行fsync(2). -
aof-write-active-child: 当子进程执行时,系统调用fsync(2). -
aof-write-alone: 当主进程执行时,系统调用fsync(2). -
aof-fstat: 系统调用fstat(2). -
aof-rename: 完成BGREWRITEAOF之后，系统调用rename(2)以重命名临时文件. -
aof-rewrite-diff-write: 编写执行BGREWRITEAOF时累积的差异. -
active-defrag-cycle: 主动的碎片整理周期. -
expire-cycle: 到期周期. -
eviction-cycle: 驱逐周期. -
eviction-del: 在逐出周期中删除.
1.2.如何启用延迟监控
一个用例的高延迟不是另一个用例的高延迟。 在某些应用程序中，必须在不到1毫秒内为所有查询提供服务，并且在某些应用程序中，不时有小部分客户端遇到2秒的延迟是可以接受的。
因此，启用延迟监视器的第一步是设置延迟阈值（以毫秒为单位）。 只有花费超过指定阈值的事件才会记录为延迟尖峰。 用户应根据需要设置阈值。 例如，如果对于基于Redis的应用程序的要求，最大可接受延迟为100毫秒，则应将阈值设置为这样的值，以便记录阻塞服务器的所有事件的时间等于或大于100毫秒。
可以使用以下命令在生产服务器中的运行时轻松启用延迟监视器：
CONFIG SET latency-monitor-threshold 100默认情况下，即使延迟监视的实际成本接近零，监视也会被禁用（阈值设置为0）。 但是，尽管延迟监视的内存需求非常小，但没有充分的理由提高运行良好的Redis实例的基准内存使用率。
1.3.使用LATENCY命令进行信息报告
等待时间监视子系统的用户界面是LATENCY命令。 像许多其他Redis命令一样，LATENCY接受修改其行为的子命令。 这些子命令是：
- LATENCY LATEST - 返回所有事件的最新延迟样本.
- LATENCY HISTORY - 返回给定事件的延迟时间序列.
- LATENCY RESET - 重置一个或多个事件的延迟时间序列数据.
- LATENCY GRAPH - 呈现事件延迟样本的ASCII-art 图.
- LATENCY DOCTOR - 回复易读的延迟分析报告.
有关更多信息，请参考每个子命令的文档页面。
