一. redis官网关于延迟问题的topic

http://redis.io/topics/latency

有一些针对降低延迟的非常好的建议。

Measuring latency(测量延迟):

如果遇到延迟问题或者非常明显的延迟问题，可能需要在应用程序的环境中进行测量，redis-cli可以被用来测试redis服务的毫秒级的延迟时间：

redis-cli –latency -h `host` -p `port`

使用redis内部的延时监控子系统

Redis 2.8.13开始，redis提供了延迟监控能力，能够采样不同的执行路径来知道redis阻塞在哪里。这使得调试各种延时问题变得简单，因此建议尽快开启延时监控。

如何开启延时监控

开启延时监控的第一步是设置一个毫秒单位的延时阈值，仅那些花费时间超过指定阈值的事件会被记录为延时峰值，用户应该根据需求设置阈值。如果最大可接受的延时是100ms，那么阈值应该被设置为这个值，以便记录所有阻塞redis时间等于或超过这个阈值的事件。

通过以下命令可以很容易的在生产服务器上开启延时监控：

CONFIG SET latency-monitor-threshold 100

默认情况下延时监控是关闭的(阈值为0)，即使实际的开销可以忽略不计。然而虽然延时监控对内存需求是非常小的，也没有一个好的理由去提高那些工作良好的redis实例的基准内存使用。

intrinsic latency(固有延迟):

由于操作系统或虚拟机/容器带来的延迟，需要在redis-server的机器上进行测量，而非客户端上。这是一个延迟时间的底线，换句话说，运行在这个环境的redis进程不可能达到比这个更低的延时。

redis-cli –intrinsic-latency 100

通常，我们需要在持久化和性能/延迟之间进行权衡，下表从更好的数据安全性到更低的延迟进行排序：

1. AOF + fsync always: 非常慢，仅当你知道自己在干什么的时候使用它.

2. AOF + fsync every second: 这是一个比较好的折中.

3. AOF + fsync every second + no-appendfsync-on-rewrite option set to yes: 与上面类似，但避免在aof重写时做fsync以进一步降低磁盘压力。

4. AOF + fsync never. fync取决于内核，更低的磁盘压力和延时.

5. RDB. 你有一个更大范围的权衡，取决于save的配置。

http://redis.io/topics/latency-monitor

二. 

http://stackoverflow.com/questions/27735411/understanding-latency-using-redis-cli

三.

http://idning.github.io/redis-latancy.html

四. 

https://www.datadoghq.com/blog/how-to-collect-redis-metrics/