导读
前面文章【一、深入理解redis之需要掌握的知识点 】中，我们对redis需要学习的内容框架进行了一个梳理。
【二、redis中String和List两种数据类型和应用场景 】、【二、redis中Hash、Set、SortedSet应用场景 】两篇文章我们对redis中String、List、Hash、Set、SortedSet五种数据类型做了一下讲解，并且对他们各自的应用场景进行了介绍。
【三、redis数据存储之跳跃表(SKIP LIST) 】深入学习支撑SortedSet排序背后的数据结构，跳跃表；
本篇文章我们将要学习redis中的两种持久化策略：RDB(快照)和AOF(追加日志)；
如果大家在工作、学习、面试中针对redis还有什么疑问或者其他问题，可以评论区告诉我。
为了保证可以连续不间断的获取最新的技术分析及讲解，建议关注本头条号【程序猿的花果山】。
RDB(快照)
介绍：
定时(指定时间间隔)对内存数据进行快照存储，例如每半个小时进行一次。整个内存数据序列化后成为二进制文件(dump.rdb)的形式保存在磁盘上。
优点：
- 1.定时生成，可以根据需求恢复到不同的版本；
- 2.在恢复大数据集方面相比AOF形式，生成速度快恢复速度快。
- 3.rdb文件非常小且紧凑，非常适合容灾备份；
- 4.在生成rdb文件时候，是在redis服务fork出的子进程中进行的，因此可以最大化的保持redis的性能。
缺点：
- 1.只能保存某一时刻的全量数据。如果在某个未进行快照保存的时间窗口内redis服务出现错误或者崩溃，那么当前崩溃时间到上一次执行快照保存时间之间的数据将丢失。如果不能接受丢失一段时间的数据，那么不建议选择这种方式。
- 2.在进行RDB形式的数据持久化时，需要经常fork出子进程。如果数据集很大且CPU和磁盘IO性能较低时候，会对主进程产生影响。
使用示例：
1.可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。你也可以通过调用 SAVE或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。
以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集:
save 60 1000
这种持久化方式被称为快照 snapshotting.
2.
工作方式：
使用写时复制机制保证创建持久化文件时数据安全
- 1.当需要生成.rdb文件时候，redis主进程fork出一个子进程；
- 2.子进程去生成新的rbd文件；
- 3.子进程生成新rdb文件后，主进程用新rdb文件替换原来的rdb文件，并删除原RDB文件。
AOF
介绍：
以redis协议追加的形式把所有的写操作都写入到日志文件末尾。Redis会对追加的文件进行重写，以保证日志文件不会特别大。当服务器奔溃时，可以从日志文件中恢复所有数据。
优点：
1.提供多种形式的同步策略(fsync):无sync、每秒一次sync(默认)、每次写入操作进行一次sync。Fsync由redis主进程fork出的子进程进行，不会占用太多redis性能；在默认配置项下，即使数据丢失也只丢失1秒的数据。
2.aof文件是一个只可以进行追加的日志文件。即使在磁盘满了、写入过程中服务器奔溃、断电等情况出现时，也可以使用redis-check-aof命令修复aof文件。
3.在aof文件过大时，redis会自动在后台对aof文件进行重写。重写后的文件以最小命令集的方式可以恢复当前数据，并且redis保证这个过程是安全的。
4.aof文件中的所有写入操作命令是有序的并且遵从redis协议简单易读。当出现误操作时(例如执行了FLUSHALL命令)，我们在aof文件中把该误写的命令删除掉，重启redis即可恢复之间的样本数据。
缺点：
1.相对于rdb文件，aof文件体积较大，更加占用磁盘空间。
2.根据所使用的sync策略，aof的速度可能慢于RDB。不过这种缺点也是相对的，如果AOF形式下使用无SYNC策略，那么AOF可以与RDB一样快；如果在实际使用过程中，对REDIS的写入操作超级多，那么AOF形式的速度要慢于RDB的。
AOF持久化模式下的三种SYNC策略：
- 1.每个写入操作都进行SYNC操作(非常慢、但是安全)；
- 2.每秒进行一次SYNC操作，即使奔溃也只丢失一秒数据(速度可与RDB媲美)；
- 3.无SYNC操作，速度更快，更加不安全；
注意：推荐使用每秒一次SYNC的方式，该方式也是AOF方式持久化的默认策略，该策略兼顾了安全和速度。
使用示例：
1.配置文件中配置appendonly yes 打开AOF持久化方式；
2.redis2.2之后，redis提供了AOF手动重写的功能，redis2.4之后提供自动重写。使用BGREWRITEAOF命令可以在自动的基础上手动触发AOF重写功能。AOF重写优化示例：对某一个key进行了100次INCR操作，最后结果为100，实际只需要一个SET操作即可解决内存中数据存储问题。
工作方式：
使用写时复制机制保证创建持久化文件时数据安全
1.redis主进程fork一个子进程去创建新的AOF文件。
2.redis主进程继续往旧的AOF文件末尾追加数据，同时把这部分数据放入一个缓存中。
3.子进程完成创建AOF文件后通知主进程，主进程把缓存中的内容追加到新的AOF文件中。
4.主进程把新的AOF文件替换原AOF文件，删除原AOF文件
如何选择哪种形式的持久化
1.如果只希望redis中的数据只有在运行是存在，那么可以不配置任何类型的持久化。
2.如果可以接受一定数据的丢失，那么可以只开启RDB形式。
3.如果想保证全量数据都存在，那么可以开启AOF形式。
4.可以RDB、AOF两种形式都开启。但是redis在重启时会优先使用AOF文件中的数据进行恢复，因为AOF文件中的数据更加完整。
5.更高版本的REDIS中，优化了AOF形式的数据备份。把AOF和RDB进行了整合。Redis4.x之后做了做了整合和混淆。既有RDB又有AOF。
RDB与AOF的相互作用
在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行 BGSAVE。这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用户回复一个 OK 状态， 并告知用户， BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。
当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。
后续还需要学习的内容
