Redis的持久化方式(RDB和AOF)详解

 

Redis中的数据存在内存中肯定是不安全的，所以需要将数据进行持久化操作，防止数据丢失造成的危害。因为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文件，载入较新的那个，微博就是这种架构。

二者优缺点

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

上述就是对于Redis的详细说明。参考了B站狂神的视频资料。