Redis持久化机制

### 概述
redis有两种持久化方式：快照(RDB)和追加文件(AOF)

- RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照；
- AOF持久化方式则会记录redis收到的所有写操作。在redis启动时，这些记录的操作会逐条执行从而重建出原来的数据；
- AOF文件记录的数据格式与Redis协议一致，以追加的方式进行保存；
- Redis的持久化是可以禁用的，就是说你可以让数据只存在于内存中；
- 两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据；

### RDB

#### 工作原理
```
- Redis调用fork()，产生一个子进程(子进程会拷贝父进程所有的数据)；
- 子进程把数据写到一个临时的RDB文件；
- 当子进程写完新的RDB文件后，把旧的RDB文件替换掉；
```
#### 优点

- RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本；
- 基于上面所描述的特性，RDB很适合用于灾备，因为单文件很方便就能传输到远程的服务器上；
- RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作；
- 比起AOF，在数据量比较大的情况下，RDB的启动速度更快；

#### 缺点
- RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了；
- RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒；

### AOF(Append-Only File)
#### 工作原理
```
- Redis接收到会修改数据集的命令时，就会把命令追加到AOF文件里；
- 重启Redis时，AOF里的命令会被重新执行一次，重建数据；
```
> 由于操作系统写文件时不是每次写操作都活落盘，而是会先写到系统缓存中，然后由系统决定何时写入磁盘。当然你可以可以调用fsync方法来强制落盘，但是这会影响性能。
#### 优点
- 比RDB可靠。你可以配置不同的fsync策略获得不同的可靠性：
	
	- 不主动进行fsync(依赖操作系统完成);
	- 每秒fsync一次;
	- 每次查询进行fsync;
	- 默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
	
- AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。
- 当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis会把新旧文件进行切换，然后开始把数据写到新文件上。
- AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，然后重启服务，这样就能把被刷掉的数据恢复回来。

#### 缺点
- 在相同的数据集下，AOF文件的大小一般会比RDB文件大；
- 在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平；
- 在过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题；

#### AOF日志重写
随着写操作的不断增加，AOF文件会越来越大。例如你递增一个计数器100次，那么最终结果就是数据集里的计数器的值为最终的递增结果，但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录，只需要1个命令就行了，也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能：在不中断服务的情况下在后台重建AOF文件。

工作原理如下：
```
- Redis调用fork()，产生一个子进程；
- 子进程将内存快照中的数据写入新的AOF文件中；
- 主进程把新的变动写到内存里的buffer，同时也会把这些新的变动写到旧的AOF里，这样即使重写失败也能保证数据的安全。
- 当子进程写完内存快照中的数据以后，主进程会获得一个信号，然后把内存里的buffer追加到子进程生成的新的AOF文件中；
- 使用新的AOF文件替换旧文件；
```
### 番外篇
> 操作系统有一种机制叫写时复制(Copy-on-write)：子进程会共享父进程的数据，但是当父进程或子进程需要修改数据时，操作系统才会为子进程创建数据副本。

### 参考
> [Redis持久化](https://segmentfault.com/a/1190000002906345 "Redis持久化")
> [redis持久化方式与优缺点](https://www.huaweicloud.com/articles/f127ac5e8998bdea8bca3e22d70ce21a.html "redis持久化方式与优缺点")