Redis实现持久化

一、定义

Redis是一个开源的使用ANSIC语言编写，支持网络，可基于内存亦可持久化的日志型，key-value数据库，并且能够提供多种语言的API。

存储类型：String(字符串),list(链表),set(集合),zset(有序集合)，hash(哈希)等几种类型

二、Redis持久化

Redis的所有数据都是保存在内存当中的，如果数据库突然宕机，数据就会全部丢失，因此就需要有一种机制来保证Redis的持久化，有以下几种持久化的方案：

1、RDB快照(默认开启方案，无法关闭)

RDB快照是指在某个时间点的一次全量数据备份，是二进制文件，在存储上十分紧凑

RDB持久化的触发机制分为手动触发和自动触发两个部分。

a.手动触发：

save命令：会阻塞当前服务器，知道RDB完成为止，如果数据量很大的话会造成很长时间的阻塞，所以一般我们不建议使用bgsave命令。

b.自动触发：

配置redis.conf，触发机制，自动执行

在执行shutdown命令关闭服务器时，如果没有开启AOF持久化功能，你们会自动执行一次bgsave命令

RDB执行流程,如下图所示：

 

具体流程为：

a.redis客户端执行bgsave命令或者自动触发bgsve命令

b.主进程会判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回

c.如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作

d.子进程先将数据写入到临时的rdb文件中，等到快照数据写入完成后再原子替换旧的rdb文件

e.同时发送信号给主进程。通知主进程rdb持久化完成，主进程更新相关的统计信息

优点：

RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；
Redis加载RDB文件恢复数据要远远快于AOF方式；

缺点：
RDB方式实时性不够，无法做到秒级的持久化；
每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；
RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全；
版本兼容RDB文件问题；
 

2、AOF

aof方式持久化是使用文本协议将每次的写命令记录到aof文件中，经过文件重写后记录最终的数据

生成命令，在redis启动时，通过执行aof文件中的命令恢复数据。

aof执行流程：

 

append：
aof文件只记录写命令，不记录读命令，当服务端接收到写命令后，redis会将命令写入到aof缓冲区中，之所以写入缓冲区而不直接写入aof文件中是因为如果每次都将命令直接写入到文件中，那么redis的性能将完全取决于硬盘的读写能力，这与redis性能至上的理念不符，另外，写入缓冲区中也便于使用不同的同步策略。

重写（rewrite）
随着写命令越来越多，aof文件的体积也越来越大，此时就需要重写机制来按照特定的机制清除或者合并命令从而达到减小文件体积，便于redis重启加载的目的。

重写机制的流程为：

1、手动或者自动触发文件重写后主进程需要先判断当前是否有子进程存在，如果存在则直接返回，不存在则fork子进程；
2、fork操作完成后，主进程即可响应其他命令，在子进程生成新的aof文件过程中，主进程仍然维持原来的流程以保证原有aof机制的正确性；
3、在子进程生成新的aof文件过程中主进程执行的新命令同时会被写入到aof重写缓冲区中，当新aof文件生成后再将这一部分命令写入到新aof文件中，防止数据丢失；
4、子进程根据内存快照，根据重写规则生成新的aof文件，每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞；
5、父进程把aof重写缓冲区的数据写入到新的aof文件中；
使用新aof文件替换旧的aof文件并发送信号给主进程表示重写完成。
 

优点：

数据安全性较高，每隔1秒同步一次数据到aof文件，最多丢失1秒数据；
aof文件相比rdb文件可读性较高，便于灾难恢复；
缺点：
虽然经过文件重写，但是aof文件的体积仍然比rdb文件体积大了很多，不便于传输且数据恢复速度也较慢
aof的恢复速度要比rdb的恢复速度慢