Redis 的数据持久化

2.1 RDB 方式(默认的备份方式)

对内存中数据库状态进行快照

RDB 方式：将 Redis 在内存中的数据库状态保存到磁盘里面，RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成 RDB 文件时的数据库状态（默认下，持久化到 dump.rdb 文件，并且在 redis 重启后，自动读取RDB文件中的数据，据悉，通常情况下一千万条字符串类型键，或1GB大小 的快照文件，同步到内存中的时间是 20-30 秒）

RDB 的生成方式：

1）执行命令手动生成

有两个 Redis 命令可以用于生成 RDB 文件，一个是 SAVE，另一个是 BGSAVE;（保存）
SAVE 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求
BGSAVE 命令会派生出一个子进程，然后由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理命令请求，创建 RDB 文件结束之前，客户端发送的 BGSAVE 和 SAVE 命令会被服务器拒绝
save
bgsave

2）通过配置自动生成(默认开启)

可以设置服务器配置的 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令，可以通过 save 选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令

例如：

放开其中一个

# save 3600 1
# save 300 100
# save 60 10000
那么只要满足以下三个条件中的任意一个，save 命令就会被执行服务器在
 3600 秒之内，对数据库进行了至少 1 次修改服务器在
 300 秒之内，对数据库进行了至少 100 次修改服务器在
 60 秒之内，对数据库进行了至少 10000 次修改

2.2 AOF 方式

AOF 持久化方式在 redis 中默认是关闭的，需要修改配置文件开启该方式。

AOF：把每条命令都写入文件，类似 mysql 的 binlog 日志

AOF 方式：是通过保存 Redis 服务器所执行的写命令来记录数据库状态的文件。

AOF 文件刷新的方式，有三种存储策略：

appendfsync always 
每提交一个修改命令都调用 fsync 刷新到 AOF 文件，非常非常慢，但也非常安全

appendfsync everysec 
每秒钟都调用 fsync 刷新到 AOF 文件，很快，但可能会丢失一秒以内的数据

appendfsync no 
依靠 OS(操作系统) 进行刷新，redis 不主动刷新 AOF，这样最快，但安全性就差默认并
推荐每秒刷新，这样在速度和安全上都做到了兼顾

redis.conf里面开启（开启方法）：
appendonly yes

手动开启aop持久化方案,数据不仅会持久化到aop中,还有持久化到rdb中,这样的持久化数据有两份
但是aop开启的时候,数据恢复是从aop文件中恢复的,只有在关闭(appendonly no)时,才会从rdb中恢复数据

AOF 数据恢复方式

服务器在启动时，通过载入和执行 AOF 文件中保存的命令来还原服务器关闭之前的数据库状态，具体过程：

载入AOF文件模拟客户端从AOF 文件中读取命令使用模拟客户端执行命令循环读取并执行命令，直到全部完成
如果同时启用了 RDB 和 AOF 方式，AOF 优先，启动时只加载 AOF 文件恢复数据,想要加载RDB需要把AOF关闭

RDB 和 AOF ，我应该用哪一个？
命令    RDB    AOF
启动优先级    低    高
体积    小    大
恢复速度    快 (二进制文件)    慢
数据安全性    容易丢数据    根据策略决定
生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。