微信公众号：DBA随笔
线上的Redis服务经经常有业务反馈响应慢的问题，针对这类问题，最好的分析方法是确定一个Redis的基准性能，然后去分析究竟什么原因导致的Redis变慢。
不同的硬件环境，Redis的基准性能不同，如果你用机械硬盘，那么你的Redis服务性能相比SSD硬盘，肯定有所下降。那么我们如何确定自己的Redis的基准性能呢？
Redis内置了‒intrinsic-latency的选项来测试基线性能，如下：
[root@ ~]# redis-cli --intrinsic-latency 10 Max latency so far: 7 microseconds. Max latency so far: 16 microseconds. Max latency so far: 24 microseconds. Max latency so far: 27 microseconds. Max latency so far: 31 microseconds. Max latency so far: 37 microseconds. Max latency so far: 495 microseconds. Max latency so far: 888 microseconds. Max latency so far: 1095 microseconds. Max latency so far: 10053 microseconds. 1877874 total runs (avg latency: 5.3252 microseconds / 5325.17 nanoseconds per run). Worst run took 1888x longer than the average latency.
命令中的10代表测试10s，一般取最大值作为基线性能，如图为10053微妙，也就是大概10毫秒。一旦超过这个值，那我们就可以认为Redis变慢了。
通常情况下，物理机上的Redis性能要比虚拟机好，因为虚拟机本身会引入虚拟化的软件层，所以基线性能会差一些。
之前文章中，我们说过Redis变慢的两个主要原因，
Redis内部阻塞式的操作或命令CPU多核心及NUMA架构对Redis的影响，其中，我们也对CPU多核和NUMA架构下的Redis性能优化进行了介绍。详情请参考：
Redis变慢了，到底慢在哪儿？（2）
今天我们来看其他方面的性能优化。
Redis命令层面
1、慢查询命令
Redis中有很多命令是O(1)的复杂度，也有很多命令是O(n)的复杂度，一般情况下，对于前者，我们不用理睬，后者由于复杂度和key的数量成正比，如果key很多的情况下，那妥妥的就是慢查询了。
对于慢查询的指令，我们可以选择下面2中方法：
使用其他命令来代替：例如keys * 命令用scan命令来代替，一般情况下，keys * 命令不建议用在生产环境上。在客户端中完成排序、交集等运算，避免使用sort等复杂度很高的命令2、过期的key操作
在Redis中，键值对可以设置过期时间，默认情况下，每100ms会删除过期的key，key删除的策略是采样N个key，删除其中的过期key，如果过期的key占比超过25%,则重复该过程，直到这个比例小于25%。数字N由参数ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP控制。
为什么单独把删除key的操作拿出来说，是因为这个操作会阻塞redis，如果大量的过期key触发了Redis删除机制，Redis在短时间内就无法处理业务的请求。
那么什么情况下，会有大量的key同时过期呢？
当我们频繁使用expireat命令设置过期时间的时候，例如程序硬编码某天的18:00，大量的key过期，就会导致，到那一秒钟，很多key同时过期，阻塞Redis，观察到的现象就是其他命令响应超时。
这种情况应该如何避免？
有一个小技巧，就是在过期时间的基础上，增加一个一定范围大小的随机数，这样既保证了数据在这个时间范围内删除，又避免了所有的key都同时发生删除动作。
AOF刷盘层面
除了命令级别的Redis变慢之外，还有其他层面的Redis变慢问题，我们来看AOF刷盘时候可能导致Redis变慢的一个瓶颈点。
当我们开启AOF的时候，有两处写磁盘的动作，第一处是AOF的刷盘策略，分为always、everysec和no，AOF刷盘的fsync操作会使用到磁盘的IO操作；第二处是为了避免AOF日志不断增大影响磁盘，Redis会对AOF进行重写，重写也会对磁盘进行大量的IO操作。
当上述两种场景相遇时，AOF的重写占用大量磁盘IO，fsync操作必然会被阻塞，虽然fsync是后台子进程负责执行的，但是主线程会监控fsync的执行进度，当主线程准备执行第二次的fsync请求时，如果发现第一次的fsync请求还没有执行完成，此时主线程会进入阻塞状态
为了避免这种情况的发生，Redis还内置了一个参数，no-appendfsync-on- rewrite，如下：
127.0.0.1:6379> config get no* 1) "no-appendfsync-on-rewrite" 2) "no"
当这个参数为yes的时候，代表AOF重写的时候，不进行fsync操作，当然，这会损失一部分Redis的安全性，如果重写时候宕机，那么这段时间内的AOF也会丢失；
当这个参数设置为no的时候，表示AOF重写的时候，也可能进行fsync操作
线上环境中，建议使用固态硬盘来作为Redis的磁盘设备，从而保证高效的内存和磁盘交互。
SWAP内存层面
这个层面的内容，想必大家都了解，当我们的物理内存不够用的时候，linux会使用到swap内存，swap内存本质是将内存数据在内存和磁盘间互相换入换出的机制，由于牵扯到了磁盘，那么速度必然会变慢。
如果分配给Redis的内存不足，或者整个机器的内存不足，都有可能让Redis服务应用到swap内存，那么Redis的性能必然会受影响。
解决这个问题的最佳方案，还是增加内存，如果Redis确实需要占用大量的内存，怎么办？那最好就是使用Redis集群，或者进行Redis的端口拆分了。
Linux内存大页层面
常规的内存页分配是4kb为单位，而Linux支持内存大页的分配方式，这种机制支持每次分配2MB的内存，有的同学可能会认为2MB的分配方式不是更好？能够避免频繁的分配内存操作。其实这一点不可否认，但是同时它也会带来问题，如果采用了内存大页，Redis在持久化RDB的时候，采用的COW机制，会导致拷贝内存的时候，一次性拷贝2MB的内存，当写入请求很多的时候，内存会频繁发生拷贝，这会极大地影响Redis的性能。
在线上环境中，关闭内存大页是一个更好的选择，关闭的命令如下：
echo never /sys/kernel/mm/transparent_hugepage/enabled
