redis是一个基于内存的数据库，但是如果电脑重启，或者宕机，那么数据就会消失。所以redis中也有持久化操作，用于数据恢复。redis提供两个机制就是RDB和AOF
RDB
将某一时刻redis的内存快照以二进制的方式写入磁盘，生成dump.rdb文件。触发RDB持久化有手动触发，还有自动触发。
- 手动触发
- save：这个命令会阻塞主进程，直到RDB持久化完成后，主进程才会继续响应客户端。慎用
- bgsave：这个命令会让操作系统给我们主进程fork出一个子进程。这对父子进程有一块共享内存，redis数据库中的数据都在这个共享内存里面。主进程在调用fork函数，只会在子进程创建过程中阻塞一会，当子进程创建完成后，主进程将不会进行阻塞。 我们这里又会有一个写时拷贝的概念，原因是由于在fork子进程在将内存快照写入到磁盘中时，主进程是不会阻塞的，也就意味着redis内存数据可能在时时刻刻的变化，那么如果是要将5.00这个时刻的内存快照写入磁盘，那么过了0.01秒，内存数据变了。在写入过程中那么就不是写入5.00这个时刻的内存数据了。此时我们就需要用到写时拷贝，就是主进程在进行对内存数据进行写操作时，不会去真正操作共享区域的内存数据，主线程会临时拷贝写的这条数据到另外一片空间。此时共享内存中的数据就不会变，那么fork子进程就会准确的写入5.00这个时刻的内存数据。 当写入完成后，主进程再将修改的数据写回共享内存中。
- 自动触发
- save m n：在m秒内，n个键发生改变则会自动触发持久化，通过bgsave执行。
- flushall：用于清空redis所有数据库的内容，并生成一个dump.rdb不过该文件没有内容
优点：
- 整个redis只会生成一个dump.rdb。文件不大，在数据量大的情况下，比AOF启动效率更高
- 容灾性好，容易备份。
- 保证了redis高性能，该持久化可以fork出子进程来进行持久化操作，不会影响主进程的执行。
缺点：
- 数据安全性不能保证。因为RDB是每间隔一段时间进行持久化，假如每隔五分钟进行一次持久化，但是当redis故障时，我们仍然会有接近五分钟的数据丢失。
AOF
以日志的形式记录服务器处理的每一个写操作，以文本的方式进行记录。类似于MySQL中的binlog。
所有写操作都会被记录到AOF内存缓存区中，然后根据对应的刷盘策略将内存中的内容同步到磁盘中。当操作越来越多时，AOF文件也会逐渐变大，此时需要定期对AOF文件进行重写，达到压缩的目的。 当r重启redis时，可以根据AOF文件进行数据恢复。
同步策略：
- 每秒同步：异步操作，每间隔1秒时间进行刷盘操作。可能会丢1秒时间的数据
- 每修改同步：每一次写操作都会被进行刷盘操作。最多丢一条数据
- 不同步：由操作系统自己控制。可能会丢大量数据
优点：
- 相对于RDB来说，可选的策略前两个数据安全性都比RDB高。
- 通过append追加的方式进行写入文件，即使在写入一条记录时宕机了，也不会对之前的记录造成影响。并且可以通过redis-check-aof工具对之前写入的那条数据进行恢复。
缺点：
- AOF文件比RDB文件要大，恢复速率比RDB低。
- 数据量大的时候没有RDB启动快
当我们这两种机制都选择时，那么redis优先选择AOF
