剑指Offer(redis)——Redis如何做持久化

我们都知道，Redis是一种内存存储，所以可以保证查询速度极其快，但也正是因为内存数据库，所以导致，如果一旦断电宕机，就会立刻失去所有的缓存，在企业是很危险的。于是就有了Redis的持久化策略，将缓存信息，边存，边写入到硬盘上，保证数据的存储是完全的。

下面就来介绍几种Redis保证持久化的具体实现。

1.RDB（快照）持久化

首先是RDB实现缓存持久化，它能保存某个时间点的全量数据快照。

上面这么设置的意思就是：
如果900s内有1条写入指令，就产生一次快照，
如果300s内有10条写入指令，就产生一次快照，如果1≤x<10，就会等到900s再产生快照，
第三行同理。

这么配置还是为了数据安全，以及保证Redis的性能

另外还有一个配置也很重要

意思是说，当备份进程出错的时候，主进程就停止继续写入数据了。主要也是为了保证数据一致性的问题。

意思是说将RDB文件压缩之后保存。

而我们如果想主动生成RDB文件，有两个方法：

1. SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕。

但是这种方式有一个很不好的地方在于，SAVE运行在Redis的主线程，而主线程还负责处理所有的请求，那么就会将主线程的请求阻塞。

2. BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程。

如果想自动化触发RDB持久化，也是有方法的：

1. 根据redis.conf配置里的SAVE m n 定时触发（使用的方式是BGSAVE）
2. 主从复制的时候，主节点自动触发
3. 执行Debug Reload
4. 执行Shutdown且没有开启AOF持久化

BGSAVE的原理如下：

系统调用fork的时候，创建进程吗，实现了Copy-on-write

Copy-on Write:
 
如果有多个调用者同时要求相同资源，他们会共同获取相同的资源，直到某个调用者视图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。

但是RDB持久化也是有一定缺点的：

1. 内存数据的全量同步，数据量大会产生多次IO影响性能
2. 可能会因为Redis宕机导致，在透过RDB提取快照的这段时间的缓存丢失。

2. AOF（Append-Only-File）持久化：保存写状态

AOF持久化可以记录除了查询以外的所有变更数据库状态的指令，并且以append的形式追加保存到AOF文件中，换句话说，就是只对增量去进行保存。

默认情况下，都是先启动RDB，而不启动AOF，所以需要我们手动启动AOF。

只需要找到appendonly 改成yes就行了

而关于AOF的配置如下：

启动之后，默认的拷贝配置为everysec，也就是每秒钟同步到硬盘一次，always是总是同步到硬盘，而no的意思是说，缓冲区使用完了，才同步到硬盘。

但是AOF也同样是有问题的，当我们的日志重写之后，需要解决AOF文件大小不断增大的问题，AOF是这么解决的：

1. 调用fork()，创建一个子进程
2. 子进程把新的AOF写入到一个临时文件中，不依赖于原来的AOF文件
3. 主进程持续将新的变动同时写到内存和原来的AOF中
4. 主进程获取到子进程重写AOF的完成信号，往新的AOF中同步增量。

3. RDB和AOF文件共存情况下的数据恢复流程

4. RDB 与 AOF 的优缺点

RDB 的优点：全量数据快照，文件小，恢复快。
RDB 的缺点：无法保存最近一次快照之后的数据。

AOF的优点：可读性高，适合保存增量数据，数据不易丢失。
AOF的缺点：文件体积大，恢复时间长。

5. RDB-AOF混合持久化方式

对于上图有几点需要声明一下：

1. 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。

2. 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。

3. 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。

4. AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。

5. 此种混合持久化方式，是用BGSAVE做镜像全量持久化，AOF做增量持久化。