Redis三种持久化机制

Redis的确是将数据存储在内存的，但是也会有相关的持久化机制将内存持久化备份到磁盘，以便于重启时数据能够重新恢复到内存中，避免数据丢失的风险。而Redis持久化机制由三种，在4.X版本之前Redis只支持AOF以及RDB两种形式持久化，但是因为AOF与RDB都存在各自的缺陷，而在4.x版本之后redis还提供一种新的持久化机制：混合型持久化（但是最终生成的文件还是AOF）。

RDB 持久化

RDB 持久化把内存中当前进程的数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发：

• save：阻塞当前 Redis，直到 RDB 持久化过程完成为止，若内存实例比较大 会造成长时间阻塞，线上环境不建议用它

• bgsave：redis 进程执行 fork 操作创建子进程，由子进程完成持久化，阻塞时间很短（微秒级），是 save 的优化

• bgsave过程：通过fork创建子进程，RDB 持久化过程由子进程负责，会在后台异步进行快照操作，快照同时还可以响应客户端请求

  而且RDB 是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，重启时加载这个文件达到数据恢复。

• redis RDB持久化默认开启 save 900 1 – 900s内存在1个写操作 save 300 10 – 300s内存在10个写操作 save 60 10000 – 60s内存在10000个写操作 如上是RDB的自动触发的默认配置，当操作满足如上条件时会被触发。

• RDB优缺点：

  • 优点：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能；而且RDB文件存储的是压缩的二进制文件，适用于备份、全量复制，可用于灾难备份，同时RDB文件的加载速度远超于AOF文件。
  • 缺点：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候，因为RDB无法做到实时持久化，而且每次都要创建子进程，频繁创建成本过高；备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（需要的内存是原本的两倍）；还有一点，RDB文件保存的二进制文件存在新老版本不兼容的问题。

AOF持久化

而AOF持久化方式能很好的解决RDB持久化方式造成的数据丢失，AOF持久化到硬盘中的并不是内存中的数据快照，而是和MySQL的belog日志一样记录写入命令，AOF的持久化策略也有三种：

• appendfsync always：同步持久化形式，每次发生数据更改都将命令追加到AOF文件，因为每次写入时都记录会产生大量磁盘IO，从而性能会受到影响，但是数据最安全。
• appendfsync everysec：redis开启AOF后的缺省配置，异步操作，每秒将写入命令追加到AOF文件，如果在刚持久化之后的一秒内宕机，会造成1S的数据丢失。
• appendfsync no：redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因 OS 配置有关。

AOF持久化机制优缺点：

• 优点：根据不同的fsync策略可以保证数据丢失风险降到最低，数据能够保证是最新的，fsync是后台线程在处理，所以对于处理客户端请求的线程并不影响。
• 缺点：文件体积由于保存的是所有命令会比RDB大上很多，而且数据恢复时也需要重新执行指令，在重启时恢复数据的时间往往会慢很多。虽然fsync并不是共用处理客户端请求线程的资源来处理的，但是这两个线程还是在共享同一台机器的资源，所以在高并发场景下也会一定受到影响。

AOF rewrite操作

随着redis在线上运行的时间越来越久，客户端执行的命令越来越多，AOF的文件也会越来越大，当AOF达到一定程度大小之后再通过AOF文件恢复数据是异常缓慢的，那么对于这种情况redis在开启AOF持久化机制的时候会存在AOF文件的重写，缺省配置是当AOF文件比上一次重写时的文件大小增长100%并且文件大小不小于64MB时会对整个AOF文件进行重写从而达到“减肥”的目的。

而AOF rewrite 操作就是“压缩”AOF 文件的过程，当然 redis 并没有采用“基于原 aof 文件”来重写的方式，而是采取了类似 snapshot 的方式：基于 copy-on-write，全量遍历内存中数据，然后逐个序列到aof 文件中。因此 AOF rewrite 能够正确反应当前内存数据的状态，这正是我们所需要的；rewrite 过程中，对于新的变更操作将仍然被写入到原 AOF 文件中，同时这些新的变更操作也会被 redis 收集起来。当内存数据被全部写入到新的 aof 文件之后，收集的新的变更操作也将会一并追加到新的 aof 文件中，此后将会重命名新的 aof 文件为 appendonly.aof, 此后所有的操作都将被写入新的 aof 文件。如果在rewrite 过程中，出现故障，将不会影响原 AOF 文件的正常工作，只有当 rewrite 完成之后才会切换文件，因为 rewrite 过程是比较可靠的，触发 rewrite 的时机可以通过配置文件来声明，同时 redis 中可以通过 bgrewriteaof 指令人工干预。

项目中redis采用的是那种持久化方式

在项目中如果redis中不仅仅只是用来做缓存，其中还存储着一些MySQL中不存在的数据，所以数据的安全性要求比较高，而RDB因为并不是实时的持久化，会出现数据丢失，但是采用AOF形式在重启、灾备、迁移的时候过程异常耗时，也并不理想，所以在我们线上是同时采用两种形式的。

线上双开加载顺序：

RDB和AOF同时开启时，会优先加载AOF文件，因为AOF文件的数据完整性是最高的，如果没有AOF文件，则加载RDB，存在RDB文件，则加载RDB文件，加载成功则启动成功。

4.x之后的混合型持久化

在redis4.x之后推出了混合型持久化机制，因为RDB虽然加载快但是存在数据丢失，AOF数据安全但是加载缓慢，redis为了解决这个问题，带来了一个新的持久化选项——混合持久化。

将RDB文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量 的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小。redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，恢复效率因此大幅得到提升（混合型持久化最终生成的文件后缀是.aof，可以通过redis.conf文件中 aof-use-rdb-preamble yes 配置开启）。

混合型持久化优点：

结合了RDB和AOF的优点，使得数据恢复的效率大幅提升

混合型持久化缺点：

兼容性不好，redis-4.x新增，虽然最终的文件也是.aof格式的文件，但在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。