Redis是内存数据库，是把数据存储在内存中的，但是内存中的数据不是持久的，如果想要做到持久，那么就需要让redis将数据存储到硬盘上。
Redis持久化有两种策略：
- RDB ==> Redis DataBase RDB机制采取的是定期备份
- AOF ==> Append Only File AOF机制采取的是实时备份
接下来将好好说说这两种策略~
RDB
RDB会定期地将Redis中的数据生成一份快照，接着将这份快照保存到硬盘中。后续Redis重启了，就会读取这份快照，将数据恢复回来。
定期具体点，又分为两种方式：1.手动触发 2.自动触发
手动触发
用户通过redis客户端，执行特定的命令，手动地触发快照生成。
- save：执行save的时候，redis会全力以赴地进行“快照生成”操作，此时会阻塞redis的其它客户端的命令，导致类似keys *的后果，基本不采取。
- bgsave：Redis进程执行fork操作创建出子进程，RDB持久化过程交由子进程去操作，完成后自动结束。阻塞只发生在fork阶段、一般时间很短。
自动触发
1.在redis的配置文件中，设置save配置。如”save m n“表示m秒内，数据集发生了n次修改，自动RDB持久化。
2.也可以从节点进行全量复制操作时，主节点自动进行RDB持久化，随后将RDB文件内容发送给从结点。
3.还可以执行shutdown命令，关闭redis，执行RDB持久化。
bgsave流程说明
1.执行bgsave命令后，redis父进程首先会判断当前是否存在正在执行的子进程，如果有，则返回。
2.如果没有，则通过fork创建子进程，在创建子进程时会阻塞父进程。创建完成后，bgsave会返回“background saving started”信息，不再阻塞父进程，父进程接着下面的操作。
3.子进程创建出来后，会创建RDB文件，由于子进程继承了父进程的内存、文件描述符等等，因此可以根据父进程中的内存的数据生成快照，并且对原有的RDB文件进行替换，结束后发送信号通知父进程表示完成，接着子进程结束。
RDB文件
redis生成的RDB文件，是在redis的工作目录中的，可以在redis的配置文件中进行设置。生成的RDB文件为：dump.rdb
RDB为使用LZF算法，将数据进行压缩，并且以二进制的形式，保存在这个文件中。虽然压缩会消耗CPU资源，但是能节省不少空间。
在redis服务器启动的时候，如果dump.rdb文件被损坏，那么服务器会启动失败（使用RDB机制的情况下）。因此redis提供了RDB文件的检测工具：redis-check-dump。
dump.rdb文件始终只有一个：尽管进行多次的RDB持久化，RDB会把要快生成的快照数据先保存在一个临时文件中，等快照数据生成完毕，会删除原来的dump.rdb，生成新的dump.rdb。
RDB的优缺点
优点：
①RDB是一个压缩的二进制文件，代表着某个时间点中redis的内存中的数据，非常适用于备份，全量复制等场景。
②redis加载RDB数据比AOF数据快。
缺点：
①RDB没办法进行实时持久化，每次运行bgsave都需要创建子进程，执行成本高。
②RDB有多个版本，兼容性存在问题。
RDB最大的问题在于不能实时持久化，在两次生成快照期间，可能会由于某种因素导致redis服务器重启，从而导致数据丢失的问题。
AOF
AOF介绍
AOF提供的是实时的持久化，解决RDB不能持久化的问题。AOF类似于MySQL中的binlog，会将用户的每一个操作，记录在文件中。当redis服务器重启后，会读取AOF的文件来恢复数据。
在redis的配置文件中，将AOF机制启动：
启动后重启redis服务器，则开启aof，在工作目录（/var/lib/redis）中出现了appendonly.aof的文件，这个文件就是用于记录redis内存数据的文件。
AOF是一个文本文件：
AOF工作流程
AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。
所有的写入（append） 会追加到aof_buf缓冲区中，接着AOF会根据策略向硬盘做出同步操作。
如果AOF文件过大，需要进行重写（rewrite），进行压缩，节省空间。
当redis服务器启动时，会加载AOF文件进行数据的恢复。
AOF过程中为什么需要aof_buf这个缓冲区？
换句话说，引入AOF后，redis又要写内存又要写硬盘，这样效率会降低吗？其实不会，因为AOF机制，会先将数据放入aof_buf缓冲区中，数据累积到一定的量后，统一写入硬盘，降低IO次数，并且采取的是顺序写入，效率高。
同时，redis还提供了不同的缓冲区策略，给用户根据实际情况做出合理的选择。
文件同步
| 可配置值 | 说明 |
| always | 命令写入aof_buf后调用fsync同步，完成后返回。频率和数据可靠性最高，性能最低 |
| everysec | 命令写入aof_buf后只执行write操作，不进行fsync，每秒由同步线程进行fsync。 频率和数据可靠性一般，性能一般 |
| no | 命令写入aof_buf后只执行write操作，由os控制fsync。 频率和数据可靠性低，性能最高 |
系统调用write和fsync
write操作会在写入系统缓冲区后立即返回。
fsync只针对单个文件操作，强制硬盘同步，阻塞直到数据完全写入硬盘。
重写机制
随着AOF文件越来越大，它会影响到redis下次启动的时间，因为redis服务器在启动的时候，需要读取AOF文件，为了解决这个问题，AOF采取了重写机制。
AOF文件记录了用户的操作过程，但实际上，redis启动时读取AOF文件，只关心最终结果。比如用户A对同一个变量做了增加、修改、修改、修改操作，redis在读取时，只关心最后一次的修改，并不关心前面的操作如何。
因此，redis会对AOF文件进行整理，这个整理就是提出冗余的操作，合并一些操作。注意，这个过程，也是重新生成了一份AOF文件，AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件。
AOF重写触发
AOF重写触发可以分为手动触发和自动触发。
- 手动触发：调用bgwriteaof命令
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
auto-aof-rewrite-min-size：表示触发从写时AOF最小文件大小，默认64MB.
uto-aof-rewrite-percentage：代表当前AOF占用大小相较于上次重写时增加的比例。
AOF重写流程
父进程通过fork创建子进程，子进程由于继承了父进程的内存、文件描述符等，可以把父进程fork前内存中的数据获取出来，以AOF的格式写入到一个新的AOF文件中。（内存中的数据，相当于整理后的数据了）。
在子进程写新aof文件的同时，父进程仍然不停地接收新的数据，并将这些数据同时写到aof_buf缓冲区和aof_rewrite_buf缓冲区中。aof_buf缓冲区的数据会被刷新到旧AOF文件中，而aof_rewrite_buf是用于子进程将新aof文件写完后，通知父进程，父进程再把这个缓冲区中的数据写入到新AOF文件中，最后用新AOF文件替换旧AOF文件。
父进程在重写的过程中，还在对旧AOF文件进行写入的目的：
在极端情况下，在子进程重写时服务器突然挂了，重启后，子进程内存的数据会丢失，新AOF文件的内容不完整，可以使用旧AOF文件来保证数据的完整性。
如果在执行bgwriteaof时，此时redis正在进行重写，那么就不执行了。
如果在执行bgwriteaof时，此时的redis正在生成RDB文件的快照时，会等待RDB文件生成完毕，再进行重写。
混合持久化
AOF是按照文本方式进行写入的，后续加载成本较高，因此redis结合RDB和AOF两种方式的特定：
按照AOF的方式将每一个操作记录在文件中，触发AOF重写，就会将当前内存的状态按照RDB的二进制格式写入到新的AOF文件中，后续再进行操作时，依然会按照AOF的文本格式进行追加写入。简单的说就是在重写时采取RDB的二进制格式写入，在其它操作依然采用AOF的文本格式进行写入。
混合持久化在配置文件中需要打开：
Redis的选择
当AOF和RDB同时打开时，redis会优先选择AOF方式，因为AOF中包含的数据会比RDB的安全，完整。
总结
Redis提供了两种持久化方式，就是RDB和AOF。
RDB是对内存数据的快照，采取的是定期持久化，AOF是对修改命令的保存，采取的是实时持久化，并且由有重写机制来定期压缩AOF文件。
RDB和AOF都使用fork创建子进程，利⽤Linux子进程拥有父进程内存快照的特点进行持久化，尽可能不影响主进程继续处理后续命令。