‘‘‘ save(同步) 1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件 2 会造成redis的阻塞（数据量非常大的时候） 3 文件策略：如果老的RDB存在，会替换老的 4 复杂度 o(n) ‘‘‘ ‘‘‘ bgsave(异步，Backgroud saving started) 1 客户端执行save命令----》redis服务端----》异步创建RDB二进制文件（fork函数生成一个子进程（fork会阻塞reids），执行createRDB，执行成功，返回给reids消息） 2 此时访问redis，会正常响应客户端 3 文件策略：跟save相同，如果老的RDB存在，会替换老的 4 复杂度 o(n) ‘‘‘ ‘‘‘ 自动（通过配置） 配置 seconds changes save 900 1 save 300 10 save 60 10000 如果60s中改变了1w条数据，自动生成rdb 如果300s中改变了10条数据，自动生成rdb 如果900s中改变了1条数据，自动生成rdb 以上三条符合任意一条，就自动生成rdb，内部使用bgsave
日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上
always：redis--》写命令刷新的缓冲区---》每条命令fsync到硬盘---》AOF文件
everysec（默认值）：redis——》写命令刷新的缓冲区---》每秒把缓冲区fsync到硬盘--》AOF文件
no:redis——》写命令刷新的缓冲区---》操作系统决定，缓冲区fsync到硬盘--》AOF文件
AOF 重写：
本质就是把过期的，无用的，重复的，可以优化的命令，来优化
这样可以减少磁盘占用量，加速恢复速度**
配置
appendonly yes #将该选项设置为yes，打开 appendfilename "appendonly-${port}.aof" #文件保存的名字 appendfsync everysec #采用第二种策略 dir /bigdiskpath #存放的路径 no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失
原文：https://www.cnblogs.com/fjn839199790/p/12860536.html