欢迎光临我的博客[http://poetize.cn]，前端使用Vue2，聊天室使用Vue3，后台使用Spring Boot
Redis持久化
- RDB持久化能够在指定的时间间隔能对你的数据进行快照存储。
- AOF持久化以日志的方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
AOF命令以redis协议追加保存每次写的操作到日志文件末尾。
- 你也可以同时开启两种持久化方式,在这种情况下：当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
对比
只需要保证数据完整性，那么优先考虑使用 AOF 方式
RDB 非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
RDB
RDB 方式可以保存过去一段时间内的数据，并且保存结果是一个单一的文件
RDB 是一个非常紧凑的文件，它保存了某个时间点的数据集。恢复大数据集的时候，RDB 方式会更快一些
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:
Redis 调用 forks 产生一个子进程，同时拥有父进程和子进程。
（当数据集比较大的时候, fork 的过程是非常耗时的）
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
RDB持久化的开启与配置
默认下，持久化到dump.rdb文件，并且在redis重启后，自动读取其中文件
官方默认的触发条件在 redis.conf 中
save 900 1
save 300 10
save 60 10000
服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000次修改。
满足触发条件后，数据就会被保存为快照
以上配置默认启用，如果不需要它可以在配置文件中将3个配置注释掉，并新增 save "" 即可
save ""
AOF
AOF 文件的体积通常要大于 RDB 文件的体积
可以使用不同的 fsync 策略：
无 fsync、每秒 fsync 、每次写的时候 fsync 。
使用默认的每秒 fsync 策略, Redis 的性能依然很好：
fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求,一旦出现故障，你最多丢失1秒的数据。
AOF文件是一个只进行追加的日志文件
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：
重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面。
即使重写过程中发生停机，现有的 AOF 文件也不会丢失。
而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF持久化的开启与配置
默认是不开启 AOF 的，如果想要启用则需要到 redis.conf 配置文件中开启
appendonly yes
appendfsync always #每次有数据修改发生时都会写入AOF文件（安全但是费时）。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
