Redis被广泛使用的一个很重要的原因是它的高性能。因此我们必要要重视所有可能影响Redis性能的因素、机制以及应对方案。影响Redis性能的五大方面的潜在因素，分别是：
Redis内部的阻塞式操作
CPU核和NUMA架构的影响
Redis关键系统配置
Redis内存碎片
Redis缓冲区
在前面的2讲中，学习了会导致Redis变慢的潜在阻塞点以及相应的解决方案，即异步线程机制和CPU绑核。除此之外，还有一些因素会导致Redis变慢。
这一讲，介绍如何系统性应对Redis变慢这个问题。从问题认定、系统性排查和应对方案这3个方面来讲解。
判断Redis是否变慢？最直接的方法，查看Redis的响应延迟。通过绝对值来判断，比如执行时间突然增长到几秒。
但是这个方法在不同配置的机器上的误差比较大。第二个方法是基于当前环境下的Redis基线性能做判断。
基线性能指一个系统在低压力、无干扰下的基本性能。
怎么确定基线性能？从2.8.7版本开始，redis-cli命令提供了-intrinsic-latency选项，可以用来监测和统计测试期间内的最大延迟，这个延迟可以作为Redis的基线性能。其中，测试时长可以用-intrinsic-latency选项的参数来指定。
一般来说，运行时延和基线性能对比，如果运行时延是基线性能的2倍及以上时，就可以认定Redis变慢了。为了避免网络对基线性能的影响，直接在服务器端运行。
如何应对Redis变慢？影响Redis的关键因素有三个：Redis自身的操作特性、文件系统和操作系统。
Redis自身操作特性的影响Redis有两个操作会对性能造成较大影响，分别是慢查询命令和过期key操作。
慢查询命令慢查询命令，就是指在Redis中执行速度慢的命令，这会导致Redis延迟增加。
排查：通过Redis日志、或者是latency monitor工具。
解决方法：
用其他高效命令代替。比如不要使用SMEMBERS命令，而是用SSCAN多次迭代返回；
当需要执行排序、交集、并集操作时，可以在客户端完成，而不要用SORT、SUNION、SINTER这些命令。
还有一个比较容易遗漏的慢查询命令是KEYS命令，它用于返回和输入模式的所有key。因为KEYS命令需要遍历存储的键值对，所以操作延时高。KEYS命令一般不被建议用于生产环境中。
过期key操作过期key的自动删除机制，它是Redis用来回收内存空间的常用机制，本身会引起Redis操作阻塞，导致性能变慢。
排查：检查业务代码在使用EXPIREAT命令设置key过期时间时，是否使用了相同的UNIX时间戳。因为这会造成大量key在同一时间过期，导致性能变慢。
解决方法：
根据实际业务需求来决定EXPIREAT和EXPIRE的过期时间参数。
如果一批key的确是同时过期，可以在EXPIREAT和EXPIRE的过期时间参数上，加上一个一定大小范围内的随机参数
文件系统的影响在基础篇讲过，为了保证数据可靠性，Redis会采用AOF日志或者RDB快照。其中，AOF日志提供了三种日志写回策略：no、everysec、always。这三种写回策略依赖文件系统的两个系统调用完成：write和fsync。
write只要把日志记录写到内核缓冲区即可；
fsync需要把日志记录写回磁盘，时间较长。
排查：
首先，检查Redis配置文件中的appendfsync配置项；
其次，确认业务对数据可靠性的要求是否需要每一秒或每一个操作都记日志。
解决方法：
如果业务应用对延迟非常敏感，但同时允许一定量的数据丢失，把配置项no-appendfsync-on-rewrite设置为yes：
no-appendfsync-on-rewrite yes