redis持久化
一、redis持久化
1.redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程造成的数据丢失问题，当下次重启时，利用之前持久化的文件即可实现数据恢复。
RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发分为手动和自动
触发机制
手动触发
save命令：阻塞当前redis服务器，直到RDB完成为止，对于内存比较大的实例影响非常大，不建议使用
bgsave命令：redis进程执行fork操作创建子进程，rdb持久化过程由子进程负责，阻塞只发生在fork阶段，一般时间很短
自动触发
1.使用save相关配置 save m n 标识m秒内 数据存在n次修改，自动触发bgsave
2.从节点全量复制时也会执行bgsave
3.debug reload 命令加载redis时，也会触发save操作
4.执行shudown操作时
触发流程
1.执行bgsave，redis父进程会判断当前是否存在正在执行的子进程，存在就直接返回 2.父进程fork子进程，过程中父进程会发生阻塞，通过info stats 的latest_fork_usec可以获取最近一次fork操作耗时，单位为微秒 3.fork完成后，返回background saving started，阻塞完毕， 4.子进程创建rdb文件，根据父进程内存生成临时快照文件，对原文件进行院子替换，执行lastsave可以获取最后一次生成rdb的时间（info命令的rdb_last_save_time） 5.进程给父进程发送信号完成，父进程更新统计信息
RDB的优缺点：
优点：
rdb是一个紧凑压缩的二进制文件，代表redis某个时间点的数据快照
适合用于备份
redis加载rdb恢复数据远远快于aof方式
缺点：
没有办法做到实时持久化
各个版本之间的rdb存在兼容问题
copy-on-write
fork()会产生一个和父进程完全相同的子进程(除了pid)
exec函数的作用就是：装载一个新的程序（可执行映像）覆盖当前进程内存空间中的映像，从而执行不同的任务。 如果按传统的做法，会直接将父进程的数据拷贝到子进程中，拷贝完之后，父进程和子进程之间的数据段和堆栈是相互独立的。 但是，以我们的使用经验来说：往往子进程都会执行exec()来做自己想要实现的功能。 所以，如果按照上面的做法的话，创建子进程时复制过去的数据是没用的(因为子进程执行exec()，原有的数据会被清空) 既然很多时候复制给子进程的数据是无效的，于是就有了Copy On Write这项技术了，原理也很简单： fork创建出的子进程，与父进程共享内存空间。也就是说，如果子进程不对内存空间进行写入操作的话，内存空间中的数据并不会复制给子进程，这样创建子进程的速度就很快了！(不用复制，直接引用父进程的物理空间)。 并且如果在fork函数返回之后，子进程第一时间exec一个新的可执行映像，那么也不会浪费时间和内存空间了。 当父子进程中有更改相应段的行为发生时，再为子进程相应的段分配物理空间。
AOF：（append only file）
AOF以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的
AOF主要作用是解决了数据持久化的实时性，目前是Redis持久化的主流方式
appendonly yes
appendfilename appendonly.aof
OF的工作流程操作：
命令写入（append）
文件同步（sync）
文件重写（rewrite）
重启加载（load）
流程如下：
1.所有的写入命令会追加到aof_buf(缓冲区)中
2.AOF缓冲区根据对应的策略向磁盘做同步操作
3.定期对AOF文件重写，达到压缩目的
4.Redis重启，加载AOF文件进行数据恢复
命令写入：
直接使用文本协议格式追加
为什么写入aof_buf？
1.单线程，如果每次都写入，性能完全取决于硬盘
2.提供多种缓冲区同步硬盘的策略
3.性能和安全性做出平衡
文件同步：
appendfsync 参数控制
always 每次写入都要同步AOF文件，安全，慢，与Redis高性能背道而驰
everysync 每秒同步一次，默认配置，理论上只有在系统宕机丢失1s数据（不严谨）
no 使用操作系统负责同步硬盘 快，但是安全性无法保证（最多30s同步）
重写机制：
随着命令不断写入AOF，文件越来越大，为了解决这个问题，引入了重写机制
1.执行AOF重写请求
2.父进程执行fork创建子进程，开销等同于bgsave
3.1 主进程fork操作完成后，继续接受响应请求
所有修改命令依然写入aof_buf
并根据同步策略同步硬盘，保证原AOF机制正确性
3.2 fork 利用写时复制技术，子进程只能共享fork操作时的内存数据
由于父进程依然响应命令，redis使用aof重写缓冲区保存这部分新数据
防止新aof文件生成期间丢失这部分数据
4.子进程根据内存快照，按照命令合并规则写入新的aof，批量
5.1 aof写入完成之后，通知父进程
5.2 父进程把aof重写缓冲区的数据写入新的aof文件
5.3 使用新aof文件替换老文件，完成aof重写
案例：
触发机制：当AOF文件大小是上次重写后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb2
AOF重写之后文件为什么会变小？ 1.进程内已经超时的数据 不再写入文件 2.旧的aof文件中无效的命令，类似于del 操作。重写使用进程内数据直接生成。这样新的aof文件只保留数据的写入命令（类似于事务日志） 3.多条命令可以合并为一个（100次插入，可以直接 set key 100）
第一步：在/etc/redis.conf 中添加
appendonly yes
appendfilename appendonly.aof
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb2
第二步：service redis restart重启服务
[root@localhost ~]# cd /var/lib/redis/
[root@localhost redis]# ls
appendonly.aof dump.rdb
[root@localhost redis]# redis-cli
127.0.0.1:6379> auth 1234
OK
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get 1
(nil)
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set 1 2
OK
