redis之所以能够提供高速读写操作是因为数据存储在内存中，但是这带来一个风险，在服务器宕机或者断电的情况下，内存中的数据会丢失，为了解决这个问题，redis提供了持久化机制来确保数据的持久性和可靠性
redis的持久化机制分为三种
-
RDB：内存快照
-
AOF：增量日志
-
前两种的混合持久化
RDB持久化
redis持久化默认开启为RDB持久化
在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列号形式）的方式持久化，每次都是从redis中生成一个快照来进行数据的全量备份
-
手动触发
-
save：阻塞当前Redis进程，直到RDB持久化过程完成，如果内存实例比较大会造成长时间的阻塞，尽量不要使用这种方式
-
bgsave：Redis主进程fork创建子进程，由子进程完成持久化，阻塞时间就很短（微秒级）
在持久化过程中，RDB的主进程就会fork一个子进程来进行备份，这个时候主进程跟子进程就共享了一个内存（图中共享内存）子进程会先将共享内存写到临时的rdb文件里面，当这个临时文件写完成之后，就会替换掉已经存在的旧的rdb文件，然后子进程旧退出了，在子进程进行备份的操作中，主进程不参与任何IO操作，还是可以继续处理客户端请求。
在这个过程中，它也是通过cow机制来进行保证的，当我们一个新的写命令过来的时候，cow机制会从我们的共享内存里面将我们的目标key进行一个拷贝，新的这个写操作是针对我们这个内存副本进行操作的，这样旧保证了redis的高性能
这个指定时间内就是体现在主进程fork一个子进程的这一个阶段
基本redis内部所有的RDB操作都是采用bgsave的
2.自动触发
-
配置触发
在配置中集中配置 save m n 的方式，表示 m秒内数据集存在n次修改时，系统自动触发bgsave 操作。
-
shutdown触发
客户端执行shutdown就行
-
flushall触发
flushall清空Redis数据的同时清空dump.rdb文件（等同于删库跑路）
3.优点
-
性能高，RDB是通过生成一个快照文件来保存数据，因此恢复速度非常快
-
文件紧凑，RDB文件是二进制格式的数据库文件，相对于AOF文件来说，文件体积较小
4.缺点
-
可能会丢失数据，由于RDB是定期生成的快照文件，如果Redis意外宕机，最近的一次修改可能会丢失
AOF持久化
-
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
-
然后在服务重启以后，会执行这些命令来恢复数据。
AOF文件重写：
-
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写
-
AOF 文件重写就是把 Redis 进程内的数据转化为写命令，然后同步到新的 AOF 文件中。在重写的过程中，Redis 服务器会创建一个新的 AOF 文件来替代现有的 AOF 文件，新、旧两个 AOF 文件所保存的数据库状态相同，但是新的 AOF 文件不会包含冗余命令。
AOF触发机制：
appendfsync always：每次收到写命令就立即强制写入磁盘 appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。 appendfsync no：完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
优点
-
数据更加可靠，AOF持久化记录了每个写命令的操作，因此在出现故障时，可以通过重新执行AOF文件来保证数据的完整性
-
可以保留写命令历史：AOF文件是一个追加日志文件，可以用于回放过去的写操作
缺点
-
文件较大，由于记录了每个写命令，所以AOF文件体积通常比RDB文件大
混合持久化
RDB虽然加载快但是存在数据丢失，AOF数据安全但是加载缓慢，4.0后面就有混合了
