Redis数据持久化

redis的数据持久化就是为了保障数据安全性问题。将内存数据存储到磁盘当中，即持久化问题。Redis提供了两种方式去保障数据的持久化问题。

RDB（Redis Data Base）：内存快照

内存快照：就是指内存中数据在某一时刻的状态记录。

RDB是Redis中默认的持久化方案。RDB持久化会将内存中的数据写入到磁盘中，在指定的目录下生产一个dump.rdb文件。Redis重启时会加载dump.rdb文件恢复数据。

Redis中提供了两个命令生成RDB文件。分别save和bgsave。

save:在主进程中执行，会导致阻塞

bgsave:创建一个子进程，用户写入RDB文件，避免了主线程的阻塞，该方式是RDB文件生成的默认配置

 bgsave命令执行原理

1、执行bgsave命令

2、Redis中的父进程判断当前是否存在正在执行的子进程，如果存在，命令直接返回

3、父进程fork操作创建子进程

4、父进程完成fork操作之后，父进程可以继续接受并处理用户请求，而子进程负责将内存中的数据写入到磁盘中临时文件

5、当子进程完成所有数据写入后会用临时文件替换旧的RDB文件

触发RDB方式 

1、手动触发：用户执行save或者bgsave命令

2、被动触发

根据自己配置的规则进行自动快照，就是持久化数据的时机

格式：save <seconds> <changes>

# save 3600 1 //每3600秒至少1个key发生改变，产生快照

# save 300 100 //每300秒至少10个key发生变换，产生快照

# save 60 10000//每60秒至少10000个key发生改变，产生快照

优点 

1、RDB加载Redis恢复数据远远快于AOF的方式

2、使用单独的子进程来进程持久化，主进程不会进行任何的IO操作，保证Redis的高性能

缺点

1、RDB方式数据无法做到实时持久化，可能会存在数据丢失问题

2、存在格式不兼容问题，RDB文件使用特定二进制格式保存，Redis在版本升级后，可能存在老版本Redis无法兼容新版本RDB格式问题

AOF(Append Only File)增量日志

AOF持久化，以独立的日志的方式记录每次写命令，redis重启是会重新执行AOF文件中的命令达到回复数据的目的。AOF主要作用是解决数据持久化的实时性。默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数启用:apendonly yes,开启AOF方式持久化每执行一条命令，Redis就会将命令写入到aof_buff缓冲区，AOF缓存去会根据对应的策略向磁盘做同步操作，默认情况在30秒就会执行一次同步操作，为了防止缓冲区数据的丢失。

AOF持久化执行流程：

 1、所有的写入命令会追加到AOF缓冲区

2、AOF缓冲区根据对应的策略向磁盘同步

3、随着AOF文要件越来越大，需要定期对AOF文件进行重写，达到压缩文件体积的目的，AOF文件重写是吧Redis进程内的数据转化为写命令同步新AOF

4、当Redis进行重启时，可以加载AOF文件进行数据恢复

AOF保存文件：appendonly.aof

AOF缓冲区同步文件策略

AOF机制提供了三个选择，即通过appendfsync配置三个可选项

有三种方式，默认是每秒everysec执行一次

always：同步写回，每个写命令执行完，立马同步将日志写回磁盘，保证完全持久化，最慢

everysec：每秒写回：每个命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区的数据写入磁盘

no：操作系统控制写回：每个命令执行完，先把日志写到AOF文件的内存缓冲区，由操作系统决定何时从缓冲区写回此判断，性能最好，持久化没法保证

优点

1、AOF可以更好的保护数据不丢失，可以配置AOFeverysec操作，每秒执行一次，如果Redis挂掉，最多丢失1秒的数据

2、AOF是以Append-only的模型写入，没有磁盘寻址的开销，写入性能比较高

缺点

1、对于同一份文件AOF文件比RDB数据快照要大

2、数据恢复比较慢

RDB VS AOF总结

	RDB	AOF
过程
存储内容	键值对数据	写指令
占用存储空间	小（数据级：压缩）	大（指令级：重写）
文件格式	二进制文件	文本数据文件
存储速度	慢（全量）	快（增量）
恢复速度	快	慢
数据安全性	会丢失数据	依策略而定 （everysec理论丢失1秒数据）
资源消耗	高/重量级	低/轻量级
启动优先级	低（默认）	高