Redis持久化（RDB 和 AOF）

一、RDB持久化

RDB（Redis DataBase）：

配置文件中对其的相关配置：

触发机制：

恢复rdb文件：

优点：

缺点：

二、AOF持久化

AOF（Append Only File）：

配置文件中对其的相关配置：

恢复aof文件：

优点：

缺点：

---

Redis中的数据存在内存中肯定是不安全的，所以需要将数据进行持久化操作，防止数据丢失造成的危害。

 

一、RDB持久化

RDB（Redis DataBase）：

在指定时间间隔内将内存中的数据快照集体写入磁盘，也就是Snapshot快照，恢复时将快照文件直接读到内存中。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程都结束，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

默认情况下是 RDB，一般不需要修改这个配置！

在主从复制中，rdb就是备用，从机上！

配置文件中对其的相关配置：

1、RDB保存的文件 dump.rdb （在生成环境中经常将rdb文件备份）

2、RDB默认的保存规则：900s中发生一次修改就进行保存

触发机制：

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

2. 执行flushall命令，也会触发rdb规则

3. 退出redis（shut down 合理退出命令），也会产生rdb文件

备份就自动生成一个 dump.rdb 文件

恢复rdb文件：

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

2. 查看需要存放的位置：config get dir

优点：

1. 适合大规模的数据恢复！（父进程不参与数据的保存恢复，而是fork子进程管理，效率高）

2. 对数据完整性要求不高！（比如300s内更新了9次突然宕机了，那最后的数据没来得及保存就丢失了）

缺点：

1. 需要一定的时间间隔进行操作！如果redis意外当即，最后一次修改数据就没

2. fork进程的时候，会占用一定的资源！

 

二、AOF持久化

AOF（Append Only File）：

以日志的形式将我们的所有命令都记录下来（写记录读不记录），秩序罪加文件不可更改文件，redis重启会去读该文件重新构建数据，换言之，把这个文件中指令全部再执行一遍。

配置文件中对其的相关配置：

1、保存在 appendonly.aof（默认不开启，开启需要手动配置）

2、持久化策略（默认每秒写一次）

3、重写规则

默认是文件的无限追加，文件会越来越大！

当文件大小超过64m，fork一个新的进程来讲我们的文件进行重写

 

恢复aof文件：

破坏/损坏 aof 文件后，无法启动redis（如果默认时aof模式下）

此时，可以用 redis-check-aof 来修复

 

优点：

1. 每次修改都同步，文件的完整性会更好！

2. 没秒同步一次，可能会丢失一秒的数据！

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

缺点：

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

2. aof运行效率也要比rdb慢，所以redis默认配置是rdb！

性能建议：

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够 了。

如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的 AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后 将 rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，,默认超过原大小100%大小重写可以改到适当的数值。

如果不Enable AOF，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也 减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时挂了，会丢失十几分钟的数据， 启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。