共计 1319 个字符，预计需要花费 4 分钟才能阅读完成。
因为 Redis 的数据都保留在内存中，所以它能提供高性能的缓存服务。但内存中的数据是非常容易失落的，所以 Redis 提供了长久化机制来保障数据的平安
Redis 长久化有 2 钟形式：快照 (RDB) 和日志(AOF)
RDB 快照
RDB(Redis DataBase)是指 Redis 应用 save 或bgsave命令保留 Redis 在某一时刻的数据，在呈现故障复原后通过导入 RDB 文件来实现原有数据的复原
开启形式
命令行中启动
应用 save 或bgsave生成 RDB 文件
save 与 bgsave 的区别：
- save 会阻塞过程，在 RDB 文件没有生成完结前，会影响应用程序对 Redis 的写操作
- 执行 bgsave 时，主过程会 fork 出一个子过程用来生成 RDB 文件，所以不会阻塞主过程
配置文件
关上 redis.conf 配置文件，找到上图所示配置项。save选项配置了触发快照生成 RDB 文件的条件，dbfilename设置了 RDB 的文件名
save 选项的含意：
- save 900 1 : 900 秒内至多有 1 次的数据更改操作
- save 300 10 : 300 秒内至多有 10 次的数据更改操作
- save 60 10000 : 60 秒内至多有 10000 次的数据更改操作
只有达到 3 个条件中的任何一个，都会触发 RDB 的生成
RDB 文件默认是通过 LZF 算法压缩的二进制文件，保留是间接的数据。在没有很大数据量的状况下，文件通常很小，有利于导入复原数据
AOF 日志
下面简略理解了 RDB 形式，在 Redis 主机宕机后，咱们能够导入之前生成的 RDB 文件来实现数据的复原。然而 RDB 也有它的毛病，使得在生产环境下，不能只依附这一种形式。
AOF(AppendOnlyFile)日志是记录 Redis client 的每一次操作命令，并以肯定的策略将命令追加到磁盘文件中。在 Redis 主机呈现故障复原后，逐条执行日志中的每一条记录，来实现数据的复原。
开启形式
在 redis.conf 文件中，能够找到上述配置项。将选项 appendonly 设为 yes 即可开启 AOF 日志，appendfilename设置了日志文件名称。appendfsync配置了以何种策略来记录日志，有 3 个选项：
- always: 每执行一条记录，就记录到 aof 文件中
- everysec: 每 1 秒记录一次
- no: 不被动去记录，依附操作系统来进行
always会来带资源的耗费，尤其在业务高峰期，写操作过多的状况下对性能有较大的影响；no对性能的影响最小，但如果 Redis 主机宕机，而操作系统还没有对命令刷盘的状况下，失落的数据想比拟会最多；everysec每秒操作一次，所以即便服务呈现故障也只会失落 1s 的数据，是对性能和数据可靠性的一种均衡，所以举荐选用此种策略。
文件内容
AOF 日志保留的是一条条操作命令，而不是间接的数据。文件以上图中的格局来进行命令的追加：
- *2：示意此条命令有 2 局部组成
- $6：示意有 6 个字节
应用 AOF 形式能够在 Redis 宕机后，通过逐条执行命令达到数据的复原。但随着命令越来越多，文件会越来越大。追加操作会耗费肯定的磁盘 IO，同时复原数据时也会须要更多的工夫。
因为是记录每一条记录，所以针对同一个数据会有很多冗余的操作，这时就须要一种机制来对日志进行优化，升高文件的大小，减速数据的复原。
