什么是 Redis 持久化，如何理解？

其实 redis 就是一种高级的以键值对形式存储数据的数据库，而它的好处就是他可以支持数据的持久化，其实 redis 之所以会有这样的优点，主要是因为，redis 的数据都是存放在内存中的，如果不配置持久化，那么在 redis 进行重启的时候，就会造成数据的丢失，于是 redis 开启了数据的持久化功能，将所有的数据保存到磁盘中，当 redis 重启之后，就可以直接从磁盘中恢复数据，所以 redis 的持久化功能，主要就是为了防止服务器宕机而造成的数据丢失。

redis 也提供了两种不同的持久化方式：

第一种是：RDB 持久化，RDB 是 Redis DataBase 的缩写，redis 默认的持久化方式，简单来讲就是将 redis 在内存中的数据库记录按照指定的时间转存到磁盘当中，其实就是一定时间间隔内对你的数据进行一个快照存储，在默认的情况下，redis 在完成快照存储后就会将这些数据保存在一个 dump.rdb 的文件中，当 redis 运行的时候，RDB 就会将内存中的数据集存储到磁盘当中，在 redis 进行重启的时候，就可以通过载入 RDB 文件到 RDB 程序进行数据的同步恢复。

优点：因为服务区在执行保存 dump.rdb 文件时，首先需要 redis 去调用 forks()时，就会同时拥有父进程和子进程，而子进程其实就是将这些数据写入到一个临时的 RDB 文件当中，当子进程完成写入后，redis 就会用一个新的 RDB 文件替换掉旧的 RDB 文件，并且将旧的 RDB 文件删除，所以因为这样的工作方式，RDB 持久化方式就只有一个 dump.rdb 文件，非常方便持久化，而且由子进程完成写的操作，让主进程可以继续处理命令，这样可以使得 IO 最大化，使用单独的子进程来进行持久化，主进程就不会进行任何的 IO 操作，这样可以保证 redis 的高性能。

缺点：因为 RDB 是按照指定的时间每隔一段时间就要进行一次持久化，如果在持久化的过程中 redis 发生故障，那么依然会发生数据丢失，所以一般都在数据要求不太严谨的时候使用这种方式。

第二种：AOF 持久化，AOF 是 Append Only File 的缩写，默认 AOF 是不开启的，需要在 redis.conf 配置文件中手动开启，这种持久化方式就是将 redis 执行的每一次命令记录到单独的日志文件当中，当还原数据时，只需要将这些备份的指令再重新执行一遍即可。redis 的配置文件中存在三种不同的 AOF 持久化方式，分别是：

appendfsync always：每次有数据修改发生时都会写入 AOF 文件，这样会严重降级 Redis 的速度

appendfsync everysec：每秒钟同步一次，将多个写命令同步到硬盘

appendfsync no：让操作系统决定何时进行同步

而且由于 AOF 持久化对日志文件的写入操作采用的是 append 模式，使用这种模式的好处就是，即使在写入的过程中出现宕机现象，也不会破坏日志文件中已经存在的内容，然而如果我们本次操作只写入了一半数据就出现了系统奔溃问题，也不用担心，在 redis 下一次启动之前，我们可以通过 redis-check-aof 工具来帮忙解决这种数据一致性的问题。

优点：数据安全，因为 AOF 有写回策略机制，比如：always，意思就是可以在每个执行命令执行完之后，立刻同步的将日志写回磁盘，而且 AOF 持久化快，能够减少数据丢失的量，在配置 everysec 的情况下最多只会丢失秒级数据

缺点：在同等数据量的情况下，AOF 文件的大小要比 RDB 问价大很多，如果使用它进行内存的恢复需要一定的时间。

针对以上阐述，在选择持久化方式上，一般来说，如果想要达到足以媲美关系型数据库的数据安全性，那么就应该同时使用两种持久化功能（redis4.0 开始支持 RDB 和 AOF 混合持久化），在这种情况下，当 redis 重启的时候就会优先载入 AOF 文件来恢复原始数据，因为通常这种情况下，AOF 文件保存数据集要比 RDB 文件保存数据集更加完整，如果你非常关心你的数据，但是仍然可以承受一些保持在分钟之内的数据丢失，那么你可以只选择使用 RDB 持久化，因为它可以更快，但是会有一些分钟之内的数据丢失是它的缺点。有很多人都只使用 AOF 持久化，但其实不太推荐，因为定时生成 RDB 快照非常方便于进行数据库的备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快，除此之外，使用 RDB 也可以有效规避 AOF 程序的 bug，当然如果你只希望你的数据在服务器运行的时候存在，也可以不选择使用任何持久化方式。