Redis持久化总结

Redis之因此能被称之为内存数据库而不仅仅是内存缓存是由于其有本身的持久化机制,能够持久化数据库到硬盘当中，在宕机以后能及时的恢复，其持久化方式主要有两种，AOF和RDB,下面的内容是对这两种方式的总结。

AOF

基本概念

AOF方式也就是Append Only File，其是在执行命令以后，将对应的日志写到日志文件中的，由于是先执行操做，再写日志，所以不会阻塞当前的写操做。

什么时候将日志刷盘，决定了Redis宕机恢复时丢失数据的多少，Redis提供了三种策略

• Always: 同步写回，命令执行完成，立马写回到磁盘
• Everysec: 每秒写回，隔一秒就将缓存页数据写回磁盘
• No: 依赖操做系统控制的写回，操做系统本身决定刷盘时机。

以上三种策略，对数据的可靠性要求越高的对性能的影响也就越大，所以如何配置是一个取舍问题。

AOF日志写的格式是执行命令的Redis协议内容，Redis协议是文本协议，天然占据空间比较大，而因为其记录的是操做流，对同一个Key的不断修改使得AOF日志中记录了不少历史的Value,为了解决这个问题，Redis引入了AOF重写机制,如何重写，是否影响Redis对外提供的服务是咱们关心的内容，下面是关于AOF重写过程的总结,以问题的形式呈现。

AOF重写

1. 什么时候开启重写

这是由redis中的配置决定的，能够根据百分比和文件大小设置，相关的配置是auto-aof-rewrite-*

2. 重写过程当中会不会影响Redis对外提供服务？

不会,重写过程是后台子进程bgrewriteaof来完成的，因为在fork过程当中操做系统会拷贝页表等相关信息,这个过程会阻塞，可是拷贝完成以后,子进程会同父进程共享内存空间，而父进程也因为Copy On Write机制对内存的修改不会影响到子进程。子进程重写AOF，父进程对外提供服务，同时工做，总体上来看仍是不会影响的。

3. 重写过程会直接删除原来的AOF日志么?

不会，原来的日志依然会使用，直到AOF重写完成。

4. 重写AOF的日志的进程内存空间是快照,那重写过程当中的数据怎么办?

在重写过程当中，数据会写到两个缓存中，一个是原来的AOF缓存，一个是AOF重写缓存区，当重写完成以后，重写缓冲区记录的最新操做也会写入新的AOF文件中，以保证数据库最新的记录，完成以后进行替换

RDB

上面讲到了AOF来记录Redis操做,当进行数据恢复的时候，AOF须要从头至尾执行命令才能恢复到最新的状态，而若是可以直接将内存快照下来，就会快不少，这就是RDB也就是Redis Data Base 执行RDB操做有两个命令能够直接执行

• save
• bgsave

其中save是在主进程中执行save操做,会阻塞主进程，而bgsave会建立一个子进程，来负责生成快照，子进程如何作到不阻塞在上面AOF中有解释。

对于RDB,还有一个问题是快照频率的问题，从可靠性的角度出发，巴不得每时每刻均可以建立快照，可是因为拷贝的是整个Redis内存数据，开销和空间占用都比较大，对磁盘的压力都很大。此时AOF的优点就展示了出来，所以引出在Redis4.0中提出的AOF和RDB混合模式

AOF与RDB混合模式

混合模式同时使用了两种方式来生成快照，在配置文件中指定的时间周期生成RDB，最后又将过程当中发生的写操做以AOF的形式写到快照文件中。