在 redis.conf 中配置两种持久化模式

1、RDB

RDB 文件非常紧凑，它保存了 Redis 某个时间点上的数据集。RDB 恢复大数据集时速度要比 AOF 快。但是 RDB 不适合那些对时效性要求很高的业务，因为它只保存了快照，在进行恢复时会导致一些时间内的数据丢失。实际在进行备份时，Redis 主要依靠 rdbSave()函数，然后有两个命令会调用这个函数 SAVE 和 BGSAVE，前者会同步调用，阻塞主进程导致会有短暂的 Redis-server 停止工作，后者会 fork 出子进程异步处理。

# RDB文件名
dbfilename "dump.rdb"
# RDB文件和AOF文件路径
dir "/usr/local/var/db/redis"

# 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
# save <seconds> <changes>
# 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作，比如：900秒之内至少一次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作都会触发发生快照操作
save 900 1
save 300 10
save 60 10000

2、AOF(append only file)

快照备份的频率有时候不能够满足读写的需要，可以开启aof机制。补充快照技术的时间频率。

AOF 可以通过设置的 fsync 策略配置，如果未设置 fsync ，AOF 的默认策略为每秒钟 fsync 一次，在这种配置下， fsync 会在后台线程执行，所以主线程不会受到打扰。但是像 AOF 这种策略会导致追加的文件非常大，而且在恢复大数据时非常缓慢，因为要把所有会导致写数据库的命令都重新执行一遍。AOF文件中实际存储的是 Redis 协议下的命令记录，因此非常易读。当然 Redis 考虑到了 AOF 文件过大的问题，因此引入了 BGREWRITEAOF 命令进行重建 AOF 文件，保证可以减少大量无用的重复写操作。重建命令并不会去分析已有的 AOF 文件，而是将当前数据库的快照保存。

默认是关闭的 appendonly yes 是开启 appendfsync （always，everysec，no） 改完之后重启redis服务 ok

# redis默认关闭AOF机制，可以将no改成yes实现AOF持久化
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF持久化同步频率，always表示每个Redis写命令都要同步fsync写入到磁盘中，但是这种方式会严重降低redis的速度；everysec表示每秒执行一次同步fsync，显示的将多个写命令同步到磁盘中；no表示让操作系统来决定应该何时进行同步fsync，Linux系统往往可能30秒才会执行一次
# appendfsync always
appendfsync everysec
# appendfsync no

# 在日志进行BGREWRITEAOF时，如果设置为yes表示新写操作不进行同步fsync，只是暂存在缓冲区里，避免造成磁盘IO操作冲突，等重写完成后在写入。redis中默认为no  
no-appendfsync-on-rewrite no   
# 当前AOF文件大小是上次日志重写时的AOF文件大小两倍时，发生BGREWRITEAOF操作。  
auto-aof-rewrite-percentage 100  
#当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。  
auto-aof-rewrite-min-size 64mb  
# Redis再恢复时，忽略最后一条可能存在问题的指令(因为最后一条指令可能存在问题，比如写一半时突然断电了)
aof-load-truncated yes
#Redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
aof-use-rdb-preamble no