redis 持久化（RDB 与 AOF）的方式比较

持久化：
将内存中的数据在一定时间内保存一次到硬盘，当出现数据丢失（死机等），再次将硬盘中的数据进行读取恢复回来

一、RDB 方式

1.文件保存的方式:

• save 保存
• bgsave(后台执行保存,save 优化)
• 自动执行

2.save 保存方式

(1)配置文件:

dbfilename dumo.rdb
#设置本地数据库文件名，默认为dump.rdb (eg:dump-6379.rdb)
dir
#设置rdb文件的存储路径/一般为data目录
rdbcompression yes
#是否采用压缩数据。若采用为LZF压缩（开启可以使得存储文件得到压缩，但是会增加cpu运行时间，如果关闭文件变得巨大，但可以节约cpu运行时间）
rdbchecksum yes 
#是否在读写过程中进行RDB文件格式校验，默认开启（如果关闭，可能会有数据损坏的风险，但是可以提高读写性能<约10%的时间消耗>）

(2)持久化后的文件:

xxx.rdb

(3)save 工作原理:

redis 单线程任务执行队列,当多个计算机同一时间发送请求时,所有的指令全部进入队列,然后逐一被执行

风险性: 线上环境使用 sava 可能造成长时间的阻塞

优化:采用 bgsave（后台执行保存）

2.bgsave 保存方式:

bgsave 对 save 的阻塞问题进行相应的优化，redis 内部所涉及到的 RDB 操作都是采用 bgsave 的方式进行，save 被弃用

(1)配置文件:

stop-writes-on-bgsave-error yes
#在存储的过程中如果发生错误就停止保存，默认状态都是为开启

(2)工作原理:

当客户端发送一段指令之后,redis 接收后返回 massage,同时调用 fork 函数生成子进程,然后进行 rdb 文件创建后返回.

3.save 与 bgsave 比较:

| 方式 | save | bgsave |

4.自动执行:

redis 会根据你所设置的 save 指令进行每个多少时间达到所监控的数量就进行一次文件的保存

(1)配置文件:

save second change
#在second时间内对key进行变化量监控，达到指定数量就进行持久化,根据自己的需求设置
save 900 1
save 300 10
save 60 100

5.RDB 注意事项注意：

• save 保存的过程要根据业务进行设置，频度过高过低都可能造成灾难性
• save 对于 second 与 changes 的设置通常是互补的对应关系，尽量不出现包含
  自动启动中 save 配置启动后执行的都是 bgsave 操作

6.RBF 优点:

• RDB 是一个紧凑的二进制压缩文件，存储效率高
• 内部存储是 redis 在某个时间的数据快照，适用于数据备份
• RDB 数据恢复的速度比 AOF 快很多
  应用：（容灾设计：服务器每过一段时间就进行 bgsave 备份，将 RDB 文件拷贝至远程服务器，用于灾难恢复）

7:RBF 缺点:

• 无法做到实时持久化，可能存在数据丢失
• bgsave 每次的执行都需要 fork 操作进行子进程创建，要牺牲一部分性能
• Rdis 有许多 RDB 文件格式，版本未进行统一，各个版本之间可能存在无法兼容现象。
• 基于快照思想、数据量巨大时效率低下。

二.AOF 方式:

AOF:以独立日志的方式记录每次写的命令，在重启的时候执行 AOF 中的命令达到恢复数据的目的
AOF 为 Redis 的持久化主流方式，解决了数据的时效性

1.生成文件:

xxx.aof

2.AOF 写数据的三种方式:always（每次）、everysec（每秒）、no（系统控制）

always：每次写入操作的同时将指令同步到 AOF 中，数据 O 误差，但会是性能降低
everysec：每秒将缓冲区指令同步到 AOF 中，数据准确性较高（非 100%）性能较高
no:由操作系统控制每次同步到 AOF 中的周期，整体过程不可控

3.配置文件:

appendonly yes
#是否开启AOF持久化功能，默认不开启
appendfsync always|everysec|no
#配置AOF的保存数据频率
appendfilename filename
#AOF的持久化文件名。默认为：appendonly.aof(eg:appendonly-6379.aof)
dir
#AOF持久化保存文件的位置

4.AOF 重写机制：

• 不断写入指令到 AOF，文件会变得越来越大，为了解决这个问题，Redis 引入了 AOF 重写机制进行文件压缩。
• AOF 重写：将 Redis 进程内的数据转化为命令同步更新到 AOF 文件的过程。将单说就是对同一个数据的若干指令执行结果转化为最终结果用对应指令进行记录

5.作用：

• 降低磁盘的占用量，提高磁盘的利用率
• 提高持久化效率，降低持久化的时间，提高 IO 性能
• 降低数据恢复的用时，提高效率。

6.AOF 重写规则：

• 进程内已经超时的数据不写入文件
• 对数据没有影响的以及无效的指令不写入文件
• 对同一数据的多条写入指令合并为一条指令

7.手动重写:

手动执行指令:bgrewiteaof,之后执行如下图(与 RDB 的 bgsave 过程一样,生成文件不同)

8.自动重写(略):

由 redis 自己判断完成重写.需要增加配置字段:

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
触发条件：
aof_current_size(当前大小)>auto-aof-rewrite-min-size
aof_current_size（当前尺寸）- aof_base_size/aof_base_size>=auto-aof-rewrite-percentage4

三、AOF 与 RDB 对比: