redis持久化机制的理解

如下： 

1. 首先redis提供了两种持久化方案，RDB快照和AOF只追加文件，在生产环境或者说我们实际使用的时候一般都是二者结合。
2. 我们先来说下RDB，RDB存储的是数据快照的压缩二进制文件，它有两种实现方式，一种是save，另一种是bgsave，我们一般很少去使用save来生成rdb文件，因为它是用主线程来实现的，会阻塞主线程处理正常的请求，而bgsave会fork出一个子进程来进行实现，这个子进程能够共享主进程的所有内存数据。
3. 那么我们生成快照是需要时间的，如果这个时间内有请求对数据进行修改，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作，因为为了快照而暂停写操作，这对于追求速度的redis是不可接受的。简单来说，写时复制技术使得主线程要修改一个数据就会生成一个副本，然后在这个副本上进行修改，不会影响子进程正常的快照实现。
4. 虽然说bgsave去生成快照不会阻塞主线程，但是如果频繁的去生成快照，第一fork操作是肯定会阻塞主线程的，第二，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。 redis默认的快照生成是 60s 1w次操作生成一次 或者 300s 10次操作生成一次 或者900s 1次操作生成一次，这里说的操作都是增删改操作，读不会。
5. 接着我们说一下AOF，AOF只追加文件，它记录的是redis已执行的命令，不同于数据库的写前日志WAL技术，AOF是写后日志，也就是redis执行该命令成功后再进行写入，这样的话一定能保证这个命令是正确的，而且不会阻塞我们当时redis的操作。
6. AOF 的写回策略机制有三种，分别为 always(每个写命令执行完，立马同步地将日志写回磁盘)、everysec(每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘)、no(交由操作系统进行文件同步)。我们一般会使用everysec的写回策略，这样的话出现故障会有1s的命令丢失。
7. 那么我们redis怎么去加载AOF的呢，也就是怎么通过AOF实现宕机恢复的，因为我们AOF中存的是命令，但是redis不能去自己执行命令，必须有人去发送这个请求然后redis进行处理。这个时候redis是采用的伪客户端模拟请求，让redis去加载数据。
8. AOF以文件的形式记录所有的写命令，那这样的话随着写命令主键增多，AOF也会越来越大，而且其实中间有许多无用的状态，如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用。
9. 这个时候就需要进行AOF的重写，AOF重写是由后台子进程bgrewriteof来完成的，这也是为了避免阻塞主线程使得数据库的性能下降，不过务必注意一点，AOF重写不要在redis繁忙的时候进行，因为redis繁忙肯定会频繁的生成快照，结合我们之前谈到的快照生成的时间会自动开启子进程生成快照，而快照生成是bgsave，这个时候由于开启了AOF重写，就会把这个bgsave请求拒绝掉。
10. 那么AOF重写具体是如何实现的呢，可以总结为一处拷贝，两处日志。一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 出来的子进程能够共享主线程数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。那么由于主线程并未阻塞，还能够继续处理新操作，此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。这个日志是由主线程进行写入的。而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。
11. Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。