目前，Redis的持久化主要有两大机制，即AOF日志和RDB快照。

那么通过这两种方式进行持久化的时候，会不会阻塞redis的读写，造成redis的性能下降呢？

AOF

AOF是写后日志，它是先执行命令，把数据写入内存，然后才记录日志。

AOF日志是在主线程中执行的，采用先存数据再写日志的方式，可以避免对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。

这是因为如果把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而阻塞后续操作。

AOF提供了三种写回策略，也就是AOF配置项appendfsync的三个可选值：

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘。

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

RDB

RDB即内存快照，就是把某一时刻的状态以文件的形式写到磁盘上。

redis提供了两个命令来生成RDB文件，分别是save和bgsave。

save：在主线程中执行，会导致阻塞。

bgsave：创建一个子进程，专门用于写入RDB文件，避免了主线程的阻塞，这也是Redis RDB文件生成的默认配置。

采用bgsave的方式，子进程需要通过fork操作从主线程创建出来。

子进程在创建后不会再阻塞主线程，但是，fork这个创建过程本身会阻塞主线程，而且主线程内存越大，阻塞时间越长。

#########################################################

save 900 1           # 900s内有1个key发生变化，则进行bgsave持久化

save 300 10          # 300s内有10个key发生变化，则进行bgsave持久化

save 60 10000      # 60s内有10000个key发生变化，则进行bgsave持久化

##########################################################

RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

一般不要让 RDB 的间隔太长，否则每次生成的 RDB 文件太大了，对 redis 本身的性能可能会有影响的

redis 持久化阻塞，从监控图上表现为 突然出现断层。

登录redis实例主节点，无法执行任何命令，会夯住。

从redis日志，看不出什么。

如果长时间无法恢复，可以强制杀死主节点，触发主从切换，然后再启动主节点进程，待新的主从数据同步完成。

参考

Redis的AOF和RDB会不会造成阻塞

https://blog.csdn.net/weixin_46374887/article/details/122599586

Redis RDB持久化

https://blog.csdn.net/qq_42500831/article/details/125298579

Redis使用RDB备份的时候会影响阻塞主进程吗？

https://www.zhihu.com/question/457109194/answer/2300211384