Redis知识总结(3)-redis的持久化

Redis持久化概述

redis的持久化是为了快速恢复数据而不是为了存储数据
redis的持久化不保证数据的完整性

RDB

RDS(redis database) ，是redis默认的存储方式，RDB方式是通过快照完成的

触发快照的方式

1. 符合自定义配置的快照规则，漏斗设计，提高性能

save "" #不使用RDB，不能主从
save 900 1 #表示15分钟(900秒)内至少一个键被更新则进行快照
save 300 10 #表示5分钟(300秒)内至少10个键被更新
save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。

3. 执行save或bgsave命令

127.0.0.1:6379> bgsave 
Background saving started

4. 执行flushall命令
5. 执行主从复制操作

RDB执行原理

1. Redis父进程首先会判断：当前是否在执行save/bgsave/bgwriteof的子进程，如果执行则bgsave则直接返回
2. 父进程执行fork操作创建子进程，之歌复制过程中父进程是阻塞的，redis不能执行来自客户端的任何命令
3. 父进程fork后，bgsave命令返回“background saving started” 信息并不再阻塞父进程，并可以相应其他命令
4. 子进程创建RDB文件，根据父进程内存快照生成快照临时文件，完成后对原有文件进行原子替换(RDB始终完整)
5. 子进程发送信号给父进程表示完成，父进程更新统计信息
6. 父进程fork子进程后，继续工作
   

RDB优缺点

优点

1. RDB是二进制压缩文件，占用空间少，便于传输(传给slaver)
2. 主进程fork子进程，可以最大化redis性能，主进程不能太大，redis数据量不能太大，复制过程中主进程阻塞

缺点

不保证数据完整性，会丢失最后一次快照后所更改的数据

AOF

AOF(append only file) 是redis的另一种持久化的方式。redis默认情况下是不开启，开启后，将所有对数据库进行过写入命令及其参数记录到AOF文件，以此达到记录数据库状态的目的。
AOF会记录过程，RDB只负责结果

AOF配置

配置redis.conf

appendonly yes # 可以通过修改redis.conf配置文件中的appendonly参数开启
dir ./ # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
appendfilename appendonly.aof# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改

AOF原理

1. 命令传播：redis将执行完的命令、命令的参数、参数个数等信息发送到AOF程序中
2. 缓存追加：AOF程序根据接收到的命令数据，将命令转换成网络通信协议的格式，然后将协议内容追加到服务器的AOF缓存中
3. 文件写入和保存：AOF缓存中的内容被写入到AOF文件末尾，如果设定的AOF保存条件被满足的话，fsync函数或者fdatasync函数会被调用，将写入的内容真正地保存在磁盘中

AOF保存模式

1. 不保存 AOF_SYNC_NO
2. 每秒保存一次（推荐） 每秒钟执行一次
3. 每执行一个命令保存一次
   

AOF重写、触发方式、混合持久化

AOF记录数据的变化过程，越来越大，需要重写瘦身。可以在后台重写瘦身，在后台子进程进行

混合持久化：RDB头+AOF身子

RDB与AOF对比

1. RDB存在某个时刻的数据快照，采用压缩二进制压缩存储，AOF操作命令，采用文本存储(混合)
2. RDB性能高，AOF性能低
3. RDB在配置触发状态会丢失最后一次快照以后更改的所欲数据，AOF设置为每秒保存一次，则最多丢失2秒数据
4. Redis以主服务器模式运行，RDB不会保存国企键值对数据，redis以从服务器模式运行，RDB会保存过期键值对，当主服务器向从服务器同步时候，再清空过期键值对

RDB与AOF应用

1. 内存数据库： rdb+aof数据不容易丢失
2. 有原始数据源：每次启动都从原始数据源中初始化，则不用开持久化(数据量较小)
3. 缓存服务器rdb 性能高
4. 数据还原时：有rdf+aof则换原aof，因为rdb会造成文件丢失，aof相对数据要完整。只有rdb则换原rdb