持久化
Redis 是基于内存的非关系型 K-V 数据库，既然它是基于内存的，如果 Redis 服务器宕机，数据就会丢失。为了避免数据丢失了，Redis 提供了持久化，支持把数据保存到磁盘。Redis提供了?RDB 和 AOF?两种持久化机制。
RDB：把内存数据以快照的形式保存到磁盘上，在指定的时间间隔内，执行指定次数的持久操作，将内存中的数据集快照写入磁盘中，它是 Redis 默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。
AOF?：用日志的形式来记录每个操作命令，追加到文件中，重启时再重新执行 AOF 文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。默认是不开启的。
两种持久化文件加载流程如下：
RDB
在 redis.conf 配置文件中支持配置快照策略：
save?900?1??## 服务器在900秒之内，对数据库进行了至少1次修改
save?300?10?## 服务器在300秒之内，对数据库进行了至少10次修改???
save?60?10000?## 服务器在60秒之内，对数据库进行了至少10000次修改
Redis 后台使用 bgSave 和 save 指令执行快照操作。bgSave 和 save 的操作不同在于：bgSave 指令 fork 一个子进程完成快照存储， 父进程继续执行命令请求，因此不会阻塞正常的命令请求，而 save 则会，直到快照存储完成才能继续处理其他的命令请求。
触发 RDB 操作的条件有以下几种：
- 客户端发送 bgSave 指令创建快照；
- 客户端发送 save 指令创建快照，执行快照期间将不响应其他指令；
- 如果用户设置了 save 配置，当满足条件时，触发 bgSave 指令；
- 收到 shutdown 命令或者 term 信号时，会执行 save 指令阻断所有客户端指令，完成快照之后关闭服务；
- 主从服务之间发送 sync 命令开始复制操作时，主服务可能会执行 bgSave 指令创建快照。
Redis 通过时间和修改次数来确定快照，这样的策略如果遇到服务发生故障，那么用户将丢失最近一次快照之后的数据。因此快照只适合那些丢失一部分数据也不会造成影响的应用程序，适合大规模的数据恢复场景，如备份，全量复制等。
?
AOF
在 redis.conf 配置文件中支持配置开启 AOF：
appendonly no # 是否开启aof
appendfilename?"appendonly.aof"?# 文件名
#磁盘同步策略 默认每秒一次??
# appendfsync always # 每次
appendfsync everysec # 每秒一次
# appendfsync no # 由操作系统执行，默认Linux配置最多丢失30秒
AOF (Append Only File) 持久化默认是关闭的，通过将 redis.conf 中将 appendonly no，修改为 appendonly yes 来开启AOF 持久化功能，如果服务器开始了 AOF 持久化功能，服务器会优先使用 AOF 文件来还原数据库状态。只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。为了兼顾数据安全和写入性能，用户可以考虑 appendfsync everysec。
AOF 持久化功能提供了一种更为可靠的持久化方式，每当 Redis 接受到修改数据集的命令时，就会把命令追加到 AOF 文件里，当你重启 Redis 时，AOF 文件里的命令会被重新执行一次，重建数据。
RDB-AOF 混合持久化
在重启 Redis 服务器时，一般很少使用 RDB 快照文件来恢复内存状态，因为会丢失大量数据。更多的是使用 AOF 文件进行命令重放，但是执行 AOF 命令性能相对 RDB 来说要慢很多。这样在 Redis 数据很大的情况下，启动需要消耗大量的时间。
鉴于 RDB 快照可能会造成数据丢失，AOF 指令恢复数据慢，Redis 4.0 版本提供了一套基于 AOF-RDB 的混合持久化机制，保留了两种持久化机制的优点。这样重写的 AOF 文件由两部份组成，一部分是 RDB 格式的头部数据，另一部分是 AOF 格式的尾部指令。
通过配置 aof-use-rdb-preamble 为 yes 开启此功能：
# 开启AOF-RDB混合持久化机制
aof-use-rdb-preamble yes如图所示，将 RDB 数据文件的内容和增量的 AOF 命令文件存在一起。这里的 AOF 命令不再是全量的命令，而是自持久化开始到持久化结束的这段时间服务器进程执行的增量 AOF 命令，通常这部分 AOF 命令很小。
?
如图所示，将 RDB 数据文件的内容和增量的 AOF 命令文件存在一起。这里的 AOF 命令不再是全量的命令，而是自持久化开始到持久化结束的这段时间服务器进程执行的增量 AOF 命令，通常这部分 AOF 命令很小。
持久化策略选择
在实际生产环境中，根据数据量、应用对数据的安全性要求、预算限制等不同情况，会有各种各样的持久化策略：
- 完全不使用任何持久化功能；
- 使用 RDB 或 AOF 其中一种；
- 同时开启 RDB 和 AOF 持久化；
如果 Redis 中的数据完全丢弃也没有关系（如 Redis 完全用作 DB 层数据的缓存），那么无论是单机，还是集群架构，都可以不进行任何持久化。
在单机环境下，如果可以接受十几分钟或更多的数据丢失，RDB 方案对 Redis 的性能更加有利；如果只能接受秒级别的数据丢失，选择 AOF 方案更合适。