Redis持久化

概念:

Redis 是内存数据库，如果不将内存中的数据保存到磁盘，那么一旦服务器进程退出，服务器中

的数据也会消失。所以 Redis 提供了持久化功能！       

Redis提供了两种持久化方式

RDB

• RDB 是 Redis 默认的持久化方式,Redis 使用 dump.rdb 文件作为其默认的数据持久化方式之一。这个文件是 Redis 通过快照（Snapshotting）机制生成的二进制格式数据文件，用于保存某一时刻Redis数据库中的所有键值对数据。

一、RDB的触发规则

1.save的规则满足的情况下，会自动触发rdb规则

Redis官方文档倾向于用户 避免直接使用save命令，在实际生产环境中，由于save命令会导致Redis服务器阻塞所有客户端请求直到持久化完成 因为save是同步阻塞的

转而依赖于 配置文件中定义的自动触发条件或者通过脚本、程序逻辑调用 bgsave命令。

Redis配置文件中定义的自动触发条件save指令设置的是自动触发RDB持久化的条件

# 默认配置示例
save 900 1     # 如果900秒（15分钟）内至少有1个key发生变化，则保存
save 300 10    # 如果300秒（5分钟）内至少有10个key发生变化，则保存
save 60 10000  # 如果60秒内至少有10000个key发生变化，则保存

这意味着Redis会根据上述条件之一满足时自动执行bgsave命令进行后台保存操作，而不是直接使用save命令。

2、执行 flushall 命令，也会触发我们的rdb规则！

FLUSHALL命令是一个非常强大的命令，执行这个命令后，Redis实例将删除所有数据库中的所有键值对（但不会影响如AOF或RDB这样的持久化文件本身）。

这意味着内存中的数据将被清空 当 FLUSHALL执行后会产生dump.rdb文件将反映最新的数据状态，即为空状态。

3、退出redis，也会产生 rdb 文件！

该文件包含了Redis服务器在关闭前某一时刻的数据快照。即使没有手动或自动触发规则，Redis在退出时也会尝试执行一次持久化操作来保存当前内存中的数据到磁盘上

二、恢复rdb文件

只需要将 rdb 文件放在我们 redis 启动目录就可以， redis 启动的时候会自动检查 dump.rdb 恢复其中

的数据！

查看启动目录的位置:

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb 文件，启动就会自动恢复其中的数据

三、RDB的优缺点

优点：

1 、适合大规模的数据恢复！

2 、对数据的完整性要不高！

缺点：

1 、需要一定的时间间隔进程操作！如果 redis 意外宕机了，这个最后一次修改数据就没有的了！

2、 fork 进程的时候，会占用一定的内容空间

AOF

• 在Redis中，AOF（Append-Only File）是一种持久化机制，它通过记录并追加服务器执行的所有写命令到磁盘上的日志文件来实现数据的持久存储。与另一种持久化方式RDB不同，AOF不是定期生成数据集的快照，而是采用增量的方式持续记录命令流,将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！

一、开启AOF

默认是不开启的，我们需要手动进行配置！我们只需要将 appendonly 改为 yes 就开启了 aof ！

重启， redis 就可以生效了！

二、AOF的其他配置

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，
rdb完全够用！
appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会 sync。消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！

三、AOF的优缺点

优点：

1 、每一次修改都同步，文件的完整会更加好！

2 、每秒同步一次，可能会丢失一秒的数据

3 、从不同步，效率最高的！

缺点：

1 、相对于数据文件来说， aof 远远大于 rdb ，修复的速度也比 rdb 慢！

2 、 Aof 运行效率也要比 rdb 慢，所以我们 redis 默认的配置就是 rdb 持久化