一、持久化

将数据从掉电易失的内存存放到能够永久存储的设备上

Redis持久化方式
RDB（Redis DB）
AOF（Append Only File）

1、RDB（Redis DB）

默认持久化方式，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中

策略
自动：
redis-conf
按照配置文件中的条件满足就执行BGSAVE，例：
save 60 1000，Redis要满足在60秒内至少有1000个键被改动，会自动保存一次
手动：
客户端发起SAVE、BGSAVE命令

1 save

阻塞 Redis 服务，无法响应客户端请求
创建新的 dump.rdb 替代旧文件

2 bgsave

非阻塞，Redis服务正常接收处理客户端请求
Redis会folk()一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕
父进程用新的dump.rdb替代旧文件

二者对比
1、SAVE不用创建新的进程，速度略快
2、BGSAVE需要创建子进程，消耗额外的内存
3、SAVE适合停机维护，服务低谷时段
4、BGSAVE适合线上执行

2、RDB 特点

优点
完全备份，不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件，方便网络传输，适合灾难恢复
恢复大数据集速度较AOF快

缺点
会丢失最近写入、修改的而未能持久化的数据
folk过程非常耗时，会造成毫秒级不能响应客户端请求

生产环境
创建一个定时任务cron job，每小时或者每天将dump.rdb复制到指定目录
确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照版本
定时任务删除过期的备份
如果有必要，跨物理主机、跨机架、异地备份

3、AOF（Append Only File）

需要手动开启，采用追加的方式保存
会生成默认文件 appendonly.aof
记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库

	vim redis/bin/redis.conf
	
	appendonly no 改为 appendonly yes

策略
appendfsync 选项，这个选项的值可以是 always、everysec 或者 no

Always：
服务器每写入一个命令，就调用一次 fdatasync，将缓冲区里面的命令写入到硬盘，速度慢
不会丢失任何已经成功执行的命令数据

Everysec（默认）：
服务器每一秒重调用一次 fdatasync，将缓冲区里面的命令写入到硬盘，速度快
最多只丢失一秒钟内的执行的命令数据，缓冲区中未能加载的内容

No：
服务器不主动调用 fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘，速度快
丢失命令的数量是不确定的

1 AOF 自优化重新书写机制

由于是将所有操作均写入文档，会面临文档过于冗杂的问题
AOF 会在达成某个条件时，自动对 appendonly.aof 的内容进行优化
合并重复的操作，如覆盖添加内容的简化、多次存储的合并
使用尽可能少的命令来记录

2 重写过程

1、folk() 派生一个子进程负责重写 AOF 文件
2、子进程会创建一个临时文件写入 AOF 信息
3、父进程会开辟一个内存缓冲区接收新的写命令
4、子进程重写完成后，父进程会获得信号，
??????将父进程接收到的新的写操作由子进程写入到临时文件中
5、临时文件替代旧 AOF 文件
注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

3 AOF 重写触发

手动：
客户端向服务器发送 BGREWRITEAOF 命令

自动：
配置文件中的选项，自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>，触发AOF重写所需的最小体积：
当 AOF 文件的体积大于等于 size 时，考虑 AOF 重写，用于避免对体积过小的文件进行重写

auto-aof-rewrite-percentage <percent>，指定触发重写所需的AOF文件体积百分比：
当AOF文件的体积大于 auto-aof-rewrite-min-size 指定的体积，
并且超过上一次重写之后的AOF文件体积的percent （百分比%）时，就会触发AOF重写
（如果之前未进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）
注：将这个值设置为0表示关闭自动AOF重写

例：
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100
当 AOF 文件大于64MB，开始考虑重写 AOF 文件
假设第一次重写后，文件压缩为50MB，此时新写入文件大小为100MB
大于起始大小的100%，开始进行第二次重写

4、 AOF 特点

优点
写入机制，默认 fysnc 每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
重写机制，优化 AOF 文件
如果误操作了（FLUSHALL 等），只要 AOF 未被重写，
停止服务，移除 AOF 文件尾部 FLUSHALL 命令，
重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态

缺点
相同数据集，AOF 文件体积较 RDB 大了很多
恢复数据库速度较 RDB 慢（文本，命令重演）