Redis持久化方式RDB和AOF

Redis持久化方式RDB和AOF

Redis是一个可基于内存亦可持久化的日志型、Key-Value数据库，当它基于内存作为缓存服务器使用时，大部分情况下底层会有其他的持久化数据库做数据支撑，发挥Redis作为内存数据库访问快的优势，不必太多的考虑服务器宕机或者进程结束造成数据丢失（缓存大部分数据都来源于mysql，orcal等持久化的数据库）。
　　同时也提供了内存数据持久化到文件的两种方式，一种是写RDB文件方式，另一种是写AOF文件，默认为RDB，它们的原理和使用场景都大不相同

一、RDB持久化

RDB持久化是把当前进程以快照的形式保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发，把保存在内存中的数据Snapshot写到RDB文件。RDB 保存的文件是一个经过压缩后的二进制的文件，压缩的主要作用是减少文件的大小，这样带来的好处主要有三点
　　一：磁盘内存小
　　二：做主从复制时，主服务器会将这个二进制文件传输给从服务器，性能更高
　　三 ：可以存储更多的数据
　　
save 个和bgsave 命令

• save：阻塞式，内存较大的实例在执行过程中会造成长时间的阻塞，影响主进程上的正常服务请求。Reids是单进程单线程模型的 KV 数据库，由C语言编写。Reids在执行sava操作时，需要执行完成释放CPU资源后才能处理服务请求。在新的版本中已经被废弃。
• bgsave：
  a. 主进程fork一个子进程，RDB持久化的过程在子进程中进行，主进程继续处理用户请求。
  b. 持久化完成后自动结束进程。阻塞发生在fork阶段，时间 较短。
  c. Redis是单进程单线程的，所以bgsave只能Fork一个子进程，而不是创建一个线程处理。
  d. 同一时刻两个bgsava 不能同时进行。多个进程同时对同一份共享资源进行写操作会发生静态条件

1.1 RDB文件创建的方式

1.1.1 手动执行
连接redis服务器之后，手动执行bgsava命令，成功之后可以在安装目录 /data 下生成一个名为dump.rdb文件（文件名和目录都可以在配置文件中更改）

1.1.2 被动执行
　　满足RDB持久化条件后会自动执行持久化过程。满足四种条件之一就会执行bgseve

- 使用save相关配置
　　使用save相关配置.配置格式：save < seconds > < changes > 表示< seconds >秒内数据集存在次修改时，自动触发bgsave。 默认配置：
　　
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
#fork子进程内存不足或rdb文件所在的文件夹没有写入权限
rdbcompression yes
dbfilename dump.rdb
rdbchecksum yes
dir ./

实现原理：

serverCron服务定时器每100ms执行一次检查
　if(now()-rdb_last_save_time < m(指定秒数) and rdb_changes_since_last_save>n(修改次数)){
　　　 bgsave();
　 }
　
注释：
　　通过定时任务的方式，去检测记录中rdb_last_save_time 和 rdb_changes_since_last_save 2个属性的值能不能满足配置文件里配置的svae 中的任意一个，如果满足就执行bgsave操作并结束后重新记录 rdb_last_save_time 和 rdb_changes_since_last_save 的值

- 从节点执行全量复制操作
　　如果搭建的是主从形式的服务，新节点在设置主节点之后，会进行一次自动的bgsave操作全量复制

- debug reload命令
　　 手动执行debug reload命令的时候，也会自动的执行bgsave

- shutdown命令，如果没有开启aof自动执行bgsave
　　在Redis 3.2 版本之后，执行shutdown时会提示一个可选项 shutdown [save:nosave] 是否执行bgsava

１.2 RDB持久化步骤

fork 子进程 和 生成.rdb 文件的过程中，Redis服务器将会拒绝写操作（看配置文件的参数设置 ）

AOF no ，redis 只负责将新数据写入到AOF缓存区，缓存区和文件的同步任务交给操作系统来处理，但是操作系统执行同步任务的时间是不可控的，持久化实时性很差

文件重写 主要就是 多AOF 文件进行压缩，减少文件大小，是重新生成一个新的文件 来覆盖原有的文件
那么文件重写是怎么减少AOF的文件大小呢？
1 .过期数据不再写入 ：对于一些设置了过期时间的key ，过期后内存当中不会再保留这个key的数据，但是磁盘的AOF文件中依然是存在的。文件重写时是将 当前时间点Redis进程的内存数据 同步到（覆盖）AOF文件
2. 无效的命令不再写入 ：多次写入同样的一个key =“hello” ，只会追加到AOF文件末尾，不会去改变AOF之间的记录，这样的就符合文件重写时压缩减少的数据量
3. 多条命令合并为一个 ： 主要针对以后 set list 添加的元素合并。这个就很像list 可以add 和addAll()
例如：
sadd mySet a, sadd mySet b 就可以合并为 sadd mySet a,b
减少文件大小，更大的作用是 Reids在重新启动的时候，更快的被加载

Rdb 三个自动触发的条件只要满足一个，就会保存
AOF 需要2个条件同时的满足
都是通过定时任务的方式 实现

AOF和RBD 可以同时生效 ，如果执行AOF文件重写时，当前有一个文件重写任务正在执行，那么放弃当前的这次操作，如果有一个RBD 的BGsave 正在执行，那么就等bgsave执行完成后再执行当前的文件重写

执行文件重写 fork（）之后，或增加一个aof _rewrite_buf。分层2分分别进行保存。新的aof文件生成成功前，依旧会将set 保存到aof缓存区，然后同步到旧的的aof文件。主要的作用就是：即使aof文件重写失败，不会丢失这个过程时间内新的数据 。增加aof_rewrite_buf 的作用是：在fork（）执行完成和生成新的AOF文件之间的这段时间内，服务器接收到的请求命令也要写入到新的AOF文件中，不然也会造成数据丢失
子进程生成新的AOF文件后，会通知父进程已经生成完毕，父进程接收到通知后，将aof_rewrite_buf 中的数据同步到新的AOF文件中，并覆盖替换旧的aof_buff 完成重写