Redis 持久化机制

Redis 持久化机制

1 RDB

每隔一段时间，生成一个指定时间点的快照。RDB 使用 fork 子进程进行数据的持久化，数据IO操作在子进程中执行。

1.1 优点

1. RDB 文件简单，它保存的是到某个时间点内所有的 Redis 数据集(键值对)，很适合用于归档。单个文件也很方便地传输给其它数据中心，从而适合灾备。
2. 在数据量比较大时，相较于 AOF 文件，Redis 加载 RDB 文件启动更快。

1.2 缺点

1. RDB 更容易造成数据的丢失，比如 5 分钟生成一个快照，从 Redis 上一次生成快照时间起到 Redis 故障时间点，这一段时间内(最多 5 分钟)的数据就会丢失。可通过 save point 指定快照周期，但是 save point 越小，对性能影响越大。

2 AOF

AOF 记录 Redis 的每一次写命令来记录数据状态。将写命令 append 到 AOF 缓冲区，然后再从 AOF 缓冲区同步到(write)系统缓冲区，最后 fsync 到 AOF 文件。

1. append 命令追加，当开启 AOF 持久化时，每一条写命令都以 Redis 协议格式追加到 AOF 缓冲区。
2. Redis Server 在一个事件循环(event loop)结束时，调用 flushAppendOnlyFile 函数，将 AOF 缓冲区中的数据持久化到 AOF 文件中。
3. flushAppendOnlyFile 函数的行为由 appendfsync 选项来控制。
   a. always，每个事件循环都将 aof_buf 缓冲区中的内容写入 AOF 文件，并且调用 fsync() 将其同步到磁盘。最安全的数据持久性，但是最差的性能。
   b. no，每个事件循环都将 aof_buf 缓冲区中的内容写入 AOF 文件，但不对其进行同步，何时同步至磁盘会让操作系统决定。这种模式下 AOF 的写入速度最快，但是会在系统缓存区积累一段时间的数据，所以 fsync 时间为三者最长。一旦宕机将会丢失自上一次事件循环同步 AOF 文件起所有的数据。
   c. everysec，每个事件循环都将 aof_buf 缓冲区中的内容写入 AOF 文件，Redis 还会每秒在子线程中执行一次 fsync()。在实践中推荐使用这种设置，一定程度上可以保证数据持久性，又不会明显降低 Redis 性能。

2.1 优点

1. AOF 的数据可靠性优于 RDB，根据 appendfsync 选项：no、everysec 和 always，默认是 everysec。意味着最多丢失一秒钟的数据。

2.2 缺点

1. 在相同的数据量下，AOF 文件一般会比 RDB 文件大
2. 相对来说，AOF 对 Redis 性能的影响要高于 RDB，根据 AOF 的 appendfysnc 选项，每次 Redis 事件循环都会触发 AOF 持久化。