Redis 系列--持久化

Redis 持久化是面试中的热门，重要性不言而喻。对开发者来说，掌握 Redis 的持久化不仅可以从容应对面试，在实际工作中对 Redis 的使用也有重要的指导意义。

众所周知 Redis 通常是作为一个内存数据库来使用的，也正是由于所有的数据都存储在内存中，Redis 才能够在单个主线程的情况下提供较高的吞吐量，但是数据存在内存中有一个致命的问题就是一旦出现故障数据就会全部丢失，辛辛苦苦几十年，一夜回到解放前，鉴于此 Redis 提供了持久化的功能。Redis 的持久化大体上可以分为三种：RDB，AOF 和混合持久化。RDB 和 AOF 持久化机制各有千秋，混合持久化将两者结合取其精华。

1. RDB

RDB 的持久化方式是对 Redis 内存数据快照进行序列化并持久化到磁盘，因此当 Redis 缓存的数据比较大时，这将是一个很耗时的操作，耗时一方面是在对数据的序列化上，另一方面是在数据的刷盘上。考虑到持久化时不影响用户体验，Redis 采用 fork 子进程的方式进行 RDB 持久化。子进程被 fork 成功后，直至完成持久化，它看到的内存数据是静态的，那么在子进线进行持久化的同时，主线程还能支持修改操作吗，答案是肯定的，主线程采用操作系统的多进程 CopyOnWrite 机制，当需要对数据进行操作时，主线程会复制数据的副本，在副本的基础上进行操作，这样既能满足子进程数据的静态性，有保证主线程可以同时对外服务。

在采用主从模式的冗余部署方式中，当从节点加入时，会先进行全量同步，全量同步完成之后再进行增量同步来追赶主库的数据。在全量同步时，采用的就是 RDB 的持久化方式，先将数据进行快照持久化，在经网络发送给从服务器，当缓存的数据量比较大时，对从服务器来说将是一个漫长的等待，假如在从服务器设置的连接超时时间内，主服务器仍未能完成持久化，从服务器会认为这次同步请求连接超时，会重新请求，最后形成死循环。因此在设置连接超时时间时需要考量数据量。Redis 自身也考虑到这种情况，它为我们提供的方案是采用无盘复制，即直接将快照经网络发送给从服务器。

2. AOF

AOF（Append Only File）持久化方式默认是不开启的，需要在配置文件中将 appendonly no 修改为 appendonly yes，AOF 文件中记录的是数据的修改指令，因此当数据量比较大或者 Redis 运行时间较长之后，AOF 文件会非常大，也正是因此 Redis 提供了 AOF 文件重写的功能，重写本质上是对指令的合并，比如一条数据被多次修改后到达最终的状态，在重写时，会像 RDB 那样扫描缓存的数据，一条记录可能只有一条指令，可以通过如下的配置参数指定重写的条件，这两个条件是叠加的，当其中一个满足时即触发重写。重写是一个比较耗时的操作，因此 Redis 也将其放到子进程中去执行以避免影响用户体验，重写时 Redis 会缓存重写期间的修改指令，当重写完成后将这些指令追加到新的 AOF 文件中，追加完成后使用新的 AOF 覆盖原来的 AOF 即达到重写。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

写 AOF 文件是在主线程中完成的，当修改指令执行完成后，会进行此修改指令的 append 操作，这里会涉及到刷盘的策略，因为实际是将数据先写到内核为用户分配的缓冲区中，再从缓冲区刷到磁盘（IO），如果每次 append 时都触发一次耗时的刷盘，势必会对用户体验带来不好的影响，比如卡顿，因此我们还可以选择由操作系统去决定何时刷盘，但是这样在出现故障时，我们可能会丢失较多的数据，比较常用的时采用每秒一次刷盘，这也是 Redis 默认的刷盘策略，这种方式采用了折中的思想。

# appendfsync always
appendfsync everysec
# appendfsync no

3. 混合持久化

由于 RDB 持久化方式比较耗时，持久化期间丢失的数据较多，同时又由于采用 AOF 持久化的文件过大，虽然丢失少，但是数据恢复耗时长，因此 Redis4.0 开始引入了一种新的持久化选项——混合持久化。打开混合持久化之后，在 AOF 重写的时候，AOF 中的前面是 RDB 格式的内容，后面是 AOF 的内容，在数据恢复时会先读取 RDB 持久化的部分，再重现 AOF 指令，这样即具有了 RDB 恢复的速度，也弥补了数据缺失严重的问题。混合持久化在 Redis4.0 中默认时关闭的 aof-use-rdb-preamble no，在 Redis5.0 中已经不存在此配置项了，它时默认开启的。