redis是一个内存的数据库，最大的特点就是访问性能快，但是也有很多时候，我们会遇到响应变慢的情况，今天我们就来聊一聊。
redis是一个单线程的模型，如果主线程阻塞了，肯定会造成响应变慢。下面我们先来看一看阻塞主线程的操作。
1.AOF重写和RDB快照
前面已经讲过了，redis在AOF重写时，主线程会fork出一个bgrewriteaof子进程，而主线程会fork出一个bgsave子进程。这2个操作表面上看不阻塞主线程，但fork子进程的这个过程是在主线程完成的。fork子进程时redis需要拷贝内存页表，如果redis实例很大，这个拷贝会耗费大量的CPU资源，阻塞主线程的时间也会变长。
我们再回顾一下fork bgrewriteaof子进程这张图：
2.内存大页
redis默认支持内存大页是2MB，使用内存大页，一定程度上可以减少redis的内存分配次数，但是对数据持久化会有一定影响。
还是看上面那张图，在AOF重写和RDB快照过程中，不会阻塞主线程，这时候，主线程依然在接收新的写请求。这时就用到了CopyOnWrite。使用了内存大页，即使redis只修改其中一个大小是1kb的key，也需要拷贝1整页的数据，即2MB。在写入量较多时，大量拷贝就会导致redis性能下降。
在操作系统上执行下面命令，可以看到是否开启内存大页：
[root@master ~]# cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never
下面命令可以关闭内存大页，但是重启后会失效，怎么样永久禁用，可以参考网上方法。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
注意:关闭内存大页是一个折中，对子进程的COW有优势，但是会增加redis的内存分配次数。
3.命令复杂度高
这个是非常常见的redis阻塞操作，比如一次查询的数据量太大，再比如对一个set或者list数据类型执行SORT操作，复杂度是O(N+M*log(M))，可以看下面官网描述：
官网：https://redis.io/commands/sort
Time complexity: O(N+M*log(M)) where N is the number of elements in the list or set to sort, and M the number of returned elements. When the elements are not sorted, complexity is currently O(N) as there is a copy step that will be avoided in next releases.
再比如我们对set数据类型执行SMEMBERS命令，复杂度是o(N)，可以看下面官网描述：
官网：https://redis.io/commands/smembers
Time complexity: O(N) where N is the set cardinality.
对于复杂度高的命令，我们要慎重使用，一方面用复杂度低的命令替代，比如用SSCAN替代SMEMBERS。另一方面，对于排序/交集/并集等操作我们可以在客户端完成。
官网对每个命令都给出了复杂度说明，可以参考。地址如下：
https://redis.io/commands/sort
4.bigkey删除操作
对bigkey的删除需要释放大量的空间，空闲内存使用一个链表进行管理，释放的过程就是把需要释放的内存块加入这个链表中，如果释放的太多，加入链表的时间会增加，从而影响redis响应性能。
redis4.0以后引入了layfree机制，可以使用子进程异步删除，从而不影响主线程执行。不过lazyfree默认是关闭的，在redis.conf文件，如下：
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled. # It's up to the design of the application to understand when it is a good # idea to use one or the other. However the Redis server sometimes has to # delete keys or flush the whole database as a side effect of other operations. # Specifically Redis deletes objects independently of a user call in the # following scenarios: # # 1) On eviction, because of the maxmemory and maxmemory policy configurations, # in order to make room for new data, without going over the specified # memory limit. (内存达到maxmemory，需要使用淘汰策略释放内存) # 2) Because of expire: when a key with an associated time to live (see the # EXPIRE command) must be deleted from memory. (key过期了需要删除，这个设置为yes可以防止大量key同时过期) # 3) Because of a side effect of a command that stores data on a key that may # already exist. For example the RENAME command may delete the old key # content when it is replaced with another one. Similarly SUNIONSTORE # or SORT with STORE option may delete existing keys. The SET command # itself removes any old content of the specified key in order to replace # it with the specified string.(删除旧的key) # 4) During replication, when a replica performs a full resynchronization with # its master, the content of the whole database is removed in order to # load the RDB file just transferred.(主从全量同步，从库需要清空数据加载RDB文件) # #(默认是使用阻塞方式删除的，但是把下面的配置改为yes，这样就能像使用UNLINK命令一样使用费阻塞方式来释放内存了) # In all the above cases the default is to delete objects in a blocking way, # like if DEL was called. However you can configure each case specifically # in order to instead release memory in a non-blocking way like if UNLINK # was called, using the following configuration directives. lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no replica-lazy-flush no # It is also possible, for the case when to replace the user code DEL calls # with UNLINK calls is not easy, to modify the default behavior of the DEL # command to act exactly like UNLINK, using the following configuration # directive: #把用户所有的DEL操作都使用UNLINK替代，即使用layfree，这里不建议打开，因为不是bigkey的情况删除效率是非常高的 lazyfree-lazy-user-del no
我把注解一块贴了出来，加了一下自己的翻译。如果lazyfree-lazy-user-del不设置为yes，redis是否采用异步删除，还是要看删除的时间的，对于底层采用整数数组和压缩列表的情况，redis是不会采用异步删除的，还就就是String类型，所以尽量不要存String类型的bigkey。
5.从节点全量同步
从节点全量同步过程中，需要先清除内存中的数据，然后再加载RDB文件，这个过程中是阻塞的，如果有读请求到来，只能等到加载RDB文件完成后才能处理请求，所以响应会很慢。
另外，如果redis实例很大，也会造成RDB文件太大，从库加载时间长。所以尽量保持redis实例不要太大，如果超过4G，建议采用切片集群。
6.AOF同步写盘
之前在讲《redis灵魂拷问：聊一聊AOF日志重写》中，讲到appendfsync策略有3种。如果采用always，每个命令都会同步写盘，这个过程是阻塞的，等写盘成功后才能处理下一条命令。
所以是严格不能丢数据的场景，我们尽量还是采用everysec这种策略，当然如果对丢失数据不敏感，那也可以采用no。
7.内存达到maxmemory
上面也提到过，内存达到maxmemory，需要使用淘汰策略来淘汰key，可以采用lazyfree异步删除。但是选择key的过程是阻塞的，这时候就需要选择较快的淘汰策略，比如用随机淘汰来替换LRU和LFU算法淘汰。
这时候也可以扩大切片数量来减轻淘汰key的时间消耗。
阻塞主线程的操作会让redis响应变慢，我们尽量避免使用，当然还有好多可能阻塞主线程的操作，欢迎大家交流。下面我们看一下硬件资源对redis的影响。
1.使用了swap
使用swap的原因是操作系统不能给redis分配足够大的内存，一旦开启了swap，内存数据就需要不停地跟swap换入和换出，对性能影响非常大。
开启swap的原因无非2个，一个是redis需要的内存太大，操作系统没有能力分配，另一个是机器上其他进程使用了大量的内存。
2.网络问题
如果网卡负载很大，对redis性能影响会很大。这一方面有可能redis的访问量确实很高，另一方面也可能是有其他流量大的程序占用了带宽。
这个最好从运维层面进行监控。
3.线程上下文切换
redis虽然是单线程的，但是在多核cpu的情况下，也会发生上下文切换。上下文切换的带来的影响是不能使用一级缓存和二级缓存。我们可以使用下面的命令把redis绑定到一个CPU核上面：
taskset -c 0,6 ./redis-server
这里0,6是同一个物理核的2个逻辑核。这里一定要注意，不能把redis实例绑定到一个逻辑核上面，redis虽然是单线程的，但是如果只用一个逻辑核，fork出的子进程操作会跟主线程争抢CPU资源。
4.磁盘性能低
对于AOF同步写盘的使用场景，如果磁盘性能低，也会影响redis的响应。我们可以优先采用性能更好的SSD硬盘。
redis响应慢的原因有很多，有的是因为阻塞主线程操作引起的，有的是因为硬件资源问题，这跟内存、CPU、网络、磁盘都有一定关系。
本文主要从阻塞主线程的操作和硬件资源方面介绍了redis影响变慢的一些场景。对于redis响应变慢这个问题，原因还要很多，欢迎大家交流。
