redis持久化处理

redis数据持久化主要有两大机制，AOF日志和RDB快照。
1、AOF日志实现：
和数据库日志（写前日志，记录修改后得数据）逻辑相反，AOF是写后日志，就是先执行命令，将数据写入内存然后再记录日志（记录redis收到得每一条命令），如图所示：

1.1、AOF优点： redis为了避免额外得检查开销，在记录日志得时候不会校验语法，所以先执行命令，再记录日志，而且不会阻塞当前线程。
1.2、AOF风险有两点： 1、就是执行完命令还没记录日志redis就宕机了，会导致当前数据无法恢复。2、AOF避免了对当前命令得阻塞，但也是在主线程中执行得写入磁盘操作，写盘较慢会阻塞后续操作。
1.3、redis解决这两个风险得方法：三种写回策略（AOF配置项appendfsync三个可选值）

总结起来：高性能选择NO策略，高可靠选择Always策略，两者折中选择everysec策略（允许数据有一点就是，性能有一定保障）。
1.4、AOF重写机制：
日志文件过大会导致一些性能问题：1、文件系统对文件大小有限制；2、文件过大追加命令效率低；3、故障恢复非常缓慢。
重写机制能够将多条命令变成一条命令如下图所示：

当一个键值被多条命令反复修改，AOF会在重写得时候基于最新状态生成一条命令。这样就会将日志文件缩小。
1.5、AOF重写流程：

a、AOF重写机制如图所示：重写过程由后台bgrewiteaof子进程完成，第一步，使用操作系统的写实复制（copy on write）机制，主线程copy必要的数据结构给子进程，两者指向相同的内存地址空间，fork子进程开始执行AOF重写；第二步、主线程写操作会同时将操作写入到旧的日志缓冲区和新得日志缓冲区，子进程执行完之后会将新日志缓冲区也写入到AOF日志文件，就可以替换旧文件了。
b、AOF重写流程阻塞点：
fork子进程会阻塞主线程，实例内存越大，实例越大，内存页表越大，阻塞时间越长。
c、AOF触发时点：
两个配置项在控制AOF重写的触发时机：
1.auto-aof-rewrite-min-size: 表示运行AOF重写时文件的最小大小，默认为64MB
2. auto-aof-rewrite-percentage: 这个值的计算方法是：当前AOF文件大小和上一次重写后AOF文件大小的差值，再除以上一次重写后AOF文件大小。也就是当前AOF文件比上一次重写后AOF文件的增量大小，和上一次重写后AOF文件大小的比值。AOF文件大小同时超出上面这两个配置项时，会触发AOF重写。
2、内存快照RDB
内存快照是指内存中的数据某一时刻的状态记录。
2.1、save和bgsave
save:在主线程中执行，会导致阻塞；
bgsave:创建一个子进程，专门用于写入RDB文件，redis默认采用的配置。bgsave执行流程如下：

主要借助操作系统的写时复制技术（Copy-On-Write,COW），bgsave子进程是由主进程fork生成的，可以共享主线程的所有内存数据。bgsave子进程运行后，开始读取主线程内存，并写入RDB文件。如果对同一个数据发生写操作，这块数据会被复制一份，主线程对副本进行修改，子进程继续写入原来的数据到RDB文件。
2.2、增量快照

两次快照间隔期间如果发生宕机，会导致在这期间别修改的数据块无法恢复，如上图所示，所以如果想保证数据尽可能恢复，快照间隔需要尽可能短。虽然bgsave执行不会阻塞主线程，但还会有两方面开销：
a、对磁盘压力较大，会出现磁盘带宽竞争情况。
b、fork子进程这个过程本身是会阻塞主线程的，且内存越大，阻塞时间越长。且在redis中有一个bgsave在运行，不会创建第二个。
解决这个问题的方法，增量快照（redis4.0采用混合使用AOF和内存快照的方法来实现增量快照）

如上图所示，在T1和T2两次增量快照期间将写操作记录到AOF日志中，在第二次进行全量快照时，清空AOF日志。就可以解决频繁fork和文件过大两个问题。
3、针对持久化的建议
3.1、数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
3.2、如果允许分钟级别的数据丢失，可以只使用 RDB；
3.3、如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。