Redis持久化

RDB（快照）持久化：保存某个时间点的全量数据快照

1. save：阻塞redis的服务器进程，直到RDB文件被创建完毕；（save很少被使用，在主线程中保存快照，会阻塞所有client的请求）
2. bgsave：fork出一个子进程来创建RDB文件，不阻塞服务器进程；

自动化触发RDB持久化的方式

1. 根据redis.conf配置里的save m n 定时触发（用的是bgsave）；
2. 主从复制时，主节点自动触发；
3. 执行debug reload；
4. 执行shutdown且没有开启AOF持久化

BGSAVE原理

  系统调用fork()：创建进程，实现了copy-on-write；（旧方法：传统情况下，fork函数在创建子进程时直接把所有资源复制给子进程，这种实现方式简单，但是效率低下，而且复制的资源可能毫无用处。新方法：
Linux为了降低创建子进程的成本，改进fork实现，当创建子进程时，内核只为子进程创建虚拟空间，父子两个使用相同的物理空间，只有父子进程发生更改时才会为子进程分配独立的物理空间，这就是copy-on-write）

copy-on-write

  如果有多个调用者同时要求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。

RDB持久化

缺点：

1. 内存数据的全量同步，数据量大会由于I/O而严重影响性能；
2. 可能会因为redis挂掉从而丢失从当前到最近一次快照期间的数据。

redis.conf 配置

  触发备份条件：
    save 900 1
    save 300 10
    save 60 10000

  禁用rdb设置：save “”

  stop-writes-on-bgsave-error yes —— 当备份进程出错的时候，主进程停止接收新的写入了 ，如果自己的业务有完善的监控系统就可以关闭

  rdbcompression yes —— yes 表示对rdb文件进行压缩之后再保存，redis本身属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，CPU成本比内存成本更高，建议设置为no

  根目录下的dump.rdb文件就是保存数据的文件，是一个二进制文件。

AOF（Append-Only-File）持久化：保存写状态

1. 记录下除了查询以外的所有变更数据库状态的指令；
2. 以append的形式追加到AOF文件中（增量）；

AOF开启配置设置（修改redis.conf）

1. appendonly no ——no表示关闭AOF文件生成，yes表示打开
2. appendfilename “appendonly.aof” ——AOF文件的文件名
3. appendfsync everysec/always/no ——always表示一有变化马上存进去，everysec则表示每隔一秒去写入到AOF文件，no则表示将写入AOF操作交由系统来决定，即等到缓存区满了之后才写入AOF文件。推荐使用everysec。

注：修改完配置文件后需要重启redis才能生效

AOF文件大小不断增大的解决方法——日志重写

1. 调用fork()，创建一个子进程；
2. 子进程把新的AOF临时文件中，不依赖原来的AOF文件（AOF的重写是直接把当前的数据生成对应命令，并不需要读取老的AOF文件进行分析或者进行命令的合并）；
3. 主进程会持续将新的变动同时写进内存和原来的AOF里；（这样即使重写失败，也能保证数据的安全）；
4. 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动；（刚才存进内存的增量变动此刻就可以往新AOF中写入了，最后一句说的就是写入过程中的增量）
5. 使用新的AOF文件替换掉旧的AOF文件

bgrewrite 命令可以重写AOF文件，也可以修改配置定时重写AOF文件

redis数据的恢复

 RDB和AOF文件共存条件下的恢复流程：

RDB 和AOF的优缺点

1. RDB优点：全量数据快照、文件小、恢复快
2. RDB缺点：无法保存最近一次快照之后的数据
3. AOF优点：可读性高、适合保存增量数据，数据不易丢失
4. AOF缺点：文件体积大、恢复时间长

AOF基本上是人类可读的，RDB是人类不可读的。

RDB-AOF混合持久化

  bgsave做镜像全量持久化，AOF做增量持久化