Redis持久化RDB和AOF

为什么Redis需要持久化？
因为Redis属于内存型数据库，数据是储存在内存当中的，当遇到不可抗力因素，比如断电，那么储存在内存中的数据就会丢失。所以为了保证数据的完整性，我们需要做持久化操作，来保证数据的完整性。

Redis中都有哪些持久化机制？
Redis早就考虑到了这一点，所以在Redis中，为我们准备了两种持久化的机制，RDB和AOF。
既然Redis为我们提供了两种持久化的机制，那我们到底该选用哪个呢？其实啊，在Redis配置文件中RDB这种机制是默认开启的，而AOF机制是默认关闭的，也就是说如果你不进行配置，那么Redis就默认你使用了RDB这种持久化的机制。而当你开启AOF机制，那么Redis就会优先使用AOF持久化机制来进行数据的持久化操作。

下面我们来了解一下什么是RDB，什么又是AOF。

RDB（Redis Database）：

RDB是Redis用来持久化的一种机制，是把当前内存中的数据集快照写进磁盘中。

在上篇博客中提到过，在redis.conf配置文件中有一个叫做SNAPSHOTTING的配置模块，在里面我们可以看到有save 900 1 ，save 300 10 ， save 60 10000。这里的save配置的是触发持久化操作的条件，save 900 1就是指在900秒内至少有一个key发生了改变，那么我就执行持久化操作，同理save 300 10 ， save 60 10000也是指在300秒/60秒内有至少10/10000个key发生了改变就进行持久化操作。

当目前的数据修改达到我们配置的save条件之后，Redis就会将内存中的数据保存在dump.rdb（默认是dump.rdb，当然这个也可以在配置文件中进行更改）中。当Redis突然宕机重新启动的时候，Redis会读取dump.rdb文件中的数据加载到内存当中，很好的保证了数据的完整性。

RDB优点：

• RDB在执行写操作时是通过从主进程里fork的子进程进行的写入的，能够很好的保证Redis的性能不会受到太大影响。
• 和AOF机制相比，RDB是通过dump.rdb文件来进行恢复数据的，效率更佳。

RDB缺点：

• 即使配置了save 1 1也有可能在1秒之内发生了突发事件导致服务崩溃，进而丢失那一秒钟的数据，适合对数据完整性要求不高的情况下开启此机制。

AOF（Append Only File）：

Redis是默认关闭AOF机制的，他是通过记录我们操作的命令来达到数据持久化操作的目的的。
我们可以在配置文件中把他打开appendonly yes（开启AOF机制）

AOF会把我们执行的命令一条一条追加到文件中的，那么可想而知，随着命令越来越多，那么保存的文件就会越来越大，当文件达到我们配置的一个空间的时候，Redis就会通过BGREWRITEAOF命令来对AOF日志文件进行重写。

auto-aof-rewrite-percentage 100  #AOF文件大小超过上次重写时文件大小的百分之几开始重写，如果之前没有写过，则根据启动时文件大小。
auto-aof-rewrite-min-size 64mb   #允许重写的最小占用空间

同步策略可以通过以下进行配置：

appendfsync always   #当有命令执行时就同步到AOF文件中
appendfsync everysec #每隔1秒同步一次
appendfsync no       #不同步

当AOF和RDB同时开启时Redis是如何决定使用哪种机制的呢？

Redis启动时会读取配置文件，先去检查AOF是否开启，如果开启则加载AOF文件到内存中并启动成功，若AOF没有开启，则去加载RDB文件到内存中并启动成功。

AOF优点：

• AOF文件通过追加的方式写入，所以不用进行内存寻址，写入效率高。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewritelog的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

AOF缺点：

• 同RDB一样，当设置AOF同步策略为everysec时，最多也是每秒执行一次同步，有可能会丢失一秒的数据，但当同步策略设置为always虽然能防止数据的丢失，同时也付出了性能的代价，二则不可兼得。
• 对于相同的数据，AOF文件比RDB文件更占用空间。