redis学习笔记之持久化(AOF&RDB)

概述

redis将数据全部在内存中，如果一不小心宕机，那么数据就会丢失，为了解决这个问题redis通过持久化来解决这个问题。在redis中持久化分为两种：RDB(redisDataBase)和AOF(append only file)，接下来我们简单了解下这两种持久化机制。

RDB(redisDataBase)

实现原理

RDB持久化是通过COW(copy on write)机制来实现持久化的。通过fork产生一个子进程，将数据进行遍历读取，然后序列化写到磁盘中。子进程只会对数据进行持久化，并不会对现有的内存数据结构进行修改。

那么如果父进程有数据修改呢，那redis是怎么处理的？

这时候会使用操作系统的cow机制进行数据段页面的分离，数据段是由很多操作系统的页面(一个页面4K)组合而成，当父进程需要对其中一个页面的数据进行修改的时候，会将这个复制页面进行复制一份出来，对这个复制页面进行修改，子进程对应的页面没有变化，还是子进程产生时候之前的数据。另外由于redis实例中冷数据占的比例比较高，所以一般很少会出现所有的页面被分离出来

注意：默认使用的是bgsave(后台持久化)对使用基本没影响，另外一种save（直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止）影响使用

RDB优点

RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
RDB对redis对外提供读写服务的时候，影响非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

RDB缺点

如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据。
RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒

AOF(append only file)

实现原理

AOF是通过fsync将内容写到内存缓存中，然后内核会将数据异步写入磁盘中。redis默认每隔一秒执行一次fsync，这个时间是可以配置的，另外还有两种策略：永不调用fsync（让操作系统自己来决定何时同步到磁盘），每次执行一个命令就调用一次fsunc。

注意：

AOF中是需要先执行命令，确保命令执行成功了，才立即将该指令存储到AOF日志中。
重启是通过AOF日志恢复数据的

AOF日志瘦身

AOF日志是连续的增量备份的，所以很慢慢变大，好多命令也重复（比如说反复执行set 命令）。在redis中提供了一个bgrewirteaof命令对AOF日志进行瘦身，原理是开辟一个子进程对内存进行遍历，转换成一系列的redis操作命令，序列化到一个新的AOF日志文件中。序列化完成后再将操作期间发生的增量AOF日志追加到一个新的AOF日志中，追加完成后代替原来的那个AOF日志

扫描二维码关注公众号，回复： 11846543 查看本文章

AOF优点

AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复

AOF缺点

对于同一份文件AOF文件比RDB数据快照要大。
AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的

数据恢复比较慢，不适合做冷备。

redis混合持久化（4.0）

混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。AOF日志不再是全量的日志，还是自持久化开始到结束的这段增量AOF日志（一般比较小）

重启的时候会先加载RDB部分，在重放AOF日志