redis持久化

持久化

Redis有两种持久化机制，第一种是快照RDB，第二种是AOF日志。快照是一次全量备份，AOF日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而AOF日志记录的是内存数据修改的指令记录文本。AOF日志在长时间运行会变很大，需要定期AOF重写，给AOF日志进行瘦身

快照原理

问题：

1、在服务线上请求同时，Redis还要进行内存快照，内存快照要求Redis必须进行文件IO操作，可文件IO操作不能使用多路复用API

2、为了不阻塞线上业务，Redis要一边持久化、以便响应客户端请求。

Redis使用操作系统的多进程COW（copy and write）机制来实现持久化快照

fork（多线程）

Redis在持久化时会调用glibc的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚产生时，它和父进程共享内存里面的代码段和数据段

fork函数会在父子进程同时返回，在父进程里返回子进程的pid，在子进程里返回0.如果操作系统内存资源不足，pid会是负数，表示fork失败

子进程做数据持久化，只会遍历读取数据结构，然后序列化到磁盘，不会改变现有内存数据结构

父进程，必须持续服务客户端请求，然后对内存数据结构进行不间断的修改

使用COW机制来进行数据段页面的分离。数据段由很多操作系统的页面组合而成，父进程对其中一个页面数据进行修改时，会被共享到页面复制一份分离出来，然后对这个复制的页面进行修改。这是子进程响应的页面是没有变化的，还是进程产生那一瞬间的数据

AOF原理

AOF日志存储的是Redis服务器的顺序指令序列，AOF日志只记录堆内存进行修改的指令记录

Redis会在收到客户端修改指令后，进行参数校验，逻辑处理，没问题，就立即将该指令文本存储到AOF日志中，也就是，先执行指令才将日志存盘

AOF重写

redis提供bgrewriteaof指令对于AOF日志进行瘦身，原理就是开辟一个子进程对内存进行遍历，转换成一系列Redis的操作指令，序列化到一个新的AOF日志文件中。序列化完后在将操作期间发生的增量AOF日志追加到新的AOF日志文件中。

fsync

如果机器宕机，AOF日志文件没有来得及刷到磁盘中

Linux中glibc提供了fsync（int fd）函数可以将指定文件的内容强制从内核缓存刷到磁盘。Redis进程实时的调用fsync函数就可以保证AOF日志不丢失，但是fsync是一个磁盘IO操作，很慢

生产环境中，每隔1s左右执行一次fsync操作

运维

Redis主节点一般不会持久化操作，主要是从节点进行，没有客户端的压力

出现网络分区，从节点长期连不上主节点，会出现数据不一致的问题

要做好监控工作

增加一个从节点以降低网络分区的概率

混合持久化

4.0之前重启Redis时，一般使用aof日志重放

将rdb文件的内容和增量的AOF日志文件存在一起，AOF日志不再是全量的日志，而是自持久化开始到持久化结束这段时间发生的增量AOF日志，通常这部分AOF日志很小

Redis重启时，先加载rdb内容，在重放增量AOF日志，就可以替代之前全AOF全量文件重放，重启效率得到大幅度提升

参考：Redis深度遍历