持久化

Redis的数据都在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证数据不会因为故障丢失，这种机制就是Redis的持久化机制。

Redis的持久化机制有两种，第一种是快照，第二种是AOF日志。

快照是一次全量备份，AOF日志是连续的增量备份。

快照是内存数据的二进制序列化形式，在存储上非常紧凑，而AOF日志记录的是内存数据修改的指令文本。

AOF日志在长期运行过程中会变得无比巨大，数据库重启时需要加载AOF日志进行指令重放，这个时间会无比漫长，因此要定期进行AOF重写，来为AOF日志进行瘦身。

快照原理

Redis是单线程程序，这个线程要同时负责多个客户端套接字的并发读写操作和内存数据结构的逻辑读写。

内存快照要求Redis必须进行文件IO操作，但文件IO操作不能使用多路复用API，这意味着单线程还要负责文件IO操作，将会拖垮服务器请求的性能，并且为了不阻塞线上的业务，就要边持久化边响应客户端请求，持久化的同时，数据结构还在改变，怎么办？

COW机制

Redis利用操作系统的COW（copy on write）机制来实现快照持久化。

Redis在持久化时，会fork一个子进程，快照持久化完全交给这个子进程处理，由于父子进程内存共享代码和数据，所以进程分离时内存几乎无增长。

子进程遍历读取内存中的数据结构然后序列化到磁盘上，但父进程仍在不断对内部数据进行修改，此时用到操作系统的COW机制来进行数据段页面的分离，父进程如果要修改其中一个页面的数据，就复制一份出来进行修改，而子进程的数据段页面并未改变。

由于Redis实例中冷数据比较多，所以只有很少一部分数据段页面被分离。（每个数据段页面大小为4K，一个Redis实例里面有成千上万的页面）

AOF原理

AOF日志存储Redis服务器的顺序指令序列，只记录对内存进行修改的指令记录，Redis的一个特点就是先执行指令再存日志。

AOF重写

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

fsync

AOF日志是以文件形式存在，当程序对AOF日志文件进行写操作时，实际是将内容写到了内核分配的内存缓存中，然后由内核异步将数据刷到磁盘中。

如果机器突然宕机，AOF日志内容可能还没完全来得及刷到磁盘中，这时就会出现日志丢失，Linux的glibc提供了fsync函数，可以将指定文件的内容强制从内核缓存刷到磁盘，只要Redis进程实时调用fsync就可以保证AOF日志不丢失，但fsync是一个磁盘IO操作，很慢！在生产环境中，通常是每隔1秒左右执行一次fsync操作，周期1秒可以配置。

Redis也提供了另外两种策略，一种是永不fsync，交由系统处理，另一种是来一个指令就fsync一次，这非常慢。

运维

快照是通过子进程的方式来进行的，它会遍历整个内存，并且写磁盘会加重系统负担；而AOF的fsync也是一个耗时的IO操作，它会降低Redis性能并增加系统IO负担。

通常Redis主节点不会进行持久化操作，主要在从节点进行，因为从节点没有来此客户端请求的压力，其操作系统资源往往比较丰富。

Redis 4.0混合持久化

重启Redis时很少使用快照rdb来恢复内存状态，因为会丢失大量数据，通常使用AOF日志重放，但重放AOF日志相对rdb要更慢，4.0中为了解决这个问题，带来一个新的持久化选项，混合持久化。

将rdb文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不是全量日志，而是持久化开始到结束的过程中发生的增量AOF日志。

优质内容筛选与推荐>>
1、ASCII、Unicode、GBK和UTF-8字符编码的区别联系
2、Python 2.6 字符编码转换
3、Skype 1.4 for Linux 掉丢掉更新
4、自定义标题栏控件看第一行代码3.4
5、总结：c 语言与Linux操作系统的关系

持久化