Redis专题：Redis两种持久化的方式

redis的数据缓存到内存当中，但是如果遇到一些不可控的因素，比如断电或者服务器宕机导致数据丢失的时候，需要提前将数据保存到永久存储的设备中，此过程称为数据的持久化，redis提供了两种数据持久化的方式 ：RDB持久化以及AOF持久化。redis中默认开启的持久化方式为RDB方式。

1. RDB持久化

1.1 持久化的两种机制

1.1.1 save方式

阻塞当前Redis主线程，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞

1.1.2 bgsave方式

redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级）

1.2 RDB持久化的优缺点

1.2.1 优点

1. 压缩后的二进制文件，方便备份，复制以及灾难恢复
2. RDB数据加载到内存的速度优于AOF持久化

1.2.2 缺点

1. 无法实时持久化，每次创建子进程的系统开销大
2. 保存的二进制文件可能导致版本不兼容

2. AOF持久化

2.1 AOF持久化

1. no : 操作系统调用数据缓存到磁盘
2. always : 同步持久化，每次数据变更的时候记录都磁盘
3. everysec : 每秒同步一次

2.2 AOF持久化的优缺点

1.2.1 优点

1. 持久化的速度远远优于RDB持久化
2. 数据相对可靠，丢失少

1.2.2 缺点

1. .由于AOF文件过大，导致每次灾难恢复的时候效率非常低
2. 主进程对外提供请求的效率造成影响，接收请求、处理请求、写 入aof文件这三步是串行原子执行的。而非异步多线程执行的

2.3 AOF重写机制

当缓存区保存的命令数量过多时候就会造成数据的冗余，例如添加删除同一条数据的命令都保存在了同一个AOF文件中。所以引入了重写机制避免了空间的浪费。

2.3.1 AOF重写机制的流程

对AOF文件重写时候，主进程会创建一个子进程完成对AOF文件的重新，主进程继续执行其他的客户端请求，如果此过程中有新的命令写入AOF文件，那么该命令写入到子进程重写之后的AOF文件，待重写完成之后将重写之后的AOF文件追加到原有的AOF文件。