前言
- redis在项目中是经常会使用的一种缓存数据库，了解其一些配置和设计思路有利于我们更有效安全的使用它
- 这次分析一下redis的数据持久化机制，知其然知其所以然。
解析过程
RDB快照处理
- 在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中
- 可以对Redis进行设置，让它在“N秒内数据至少有M个改动”这一条件被满足，自动保存一次数据快照。
- 在Redis的默认配置如下:
save 900 1
save 300 10
save 60 10000
- 其意思是Redis满足：900秒内有一个数据被改动，或300秒内有10个数据被改动，或60秒内有10000个数据被改动条件，就会执行RDB持久化保存数据快照。
- 除了自动满足触发条件进行RDB持久化外，还可以手动命令执行生成RDB快照，在Redis客户端执行save或者bgsave命令会生成dump.rdb文件。
- 每次命令执行都会将所有redis内存数据快照到一个新的dump.rdb文件，并覆盖原有rdb快照文件。
bgsave-写时复制机制
- Redis借助操作系统提供的写时复制机制（copy-on-write，cow），在生成快照的同时，依然可以处理客户端的读写操作命令。简单来说，bgsave子进程是由主进程fork生成的，可以共享主线程的所有内存数据。
- bgsave子进程运行后，会开始读取主进程的内存数据并写入RDB文件。此时如果主进程是一些对数据的读操作，那么主进程和子进程互不影响。但如果主进程对数据进行写操作，那么这块被写入的数据被会复制一份，然后子进程把复制的备份写入到RDB文件中，而这个过程中主进程是依旧可以对客户端进行读写操作的。
save和bgsave对比
| 命令 | save | bgsave |
|---|
| IO类型 | 同步 | 异步 |
| 是否阻塞redis其他命令 | 是 | 否（在主进程生成子进程调用fork函数时会有短暂阻塞） |
| 复杂度 | O(N) | O(N) |
| 优点 | 不会消耗额外内存 | 不会阻塞客户端命令 |
| 缺点 | 阻塞客户端命令 | fork子进程，消耗内容 |
- 注意：配置自动生成rdb文件redis使用的是bgsave方式。
AOF 持久化机制
- 使用RDB快照持久化数据，会因为redis宕机或其他故障原因，导致服务器将会丢失掉最近插入且未保存到rdb文件的数据。所以从Redis 1.1版本后，Redis新增一种 AOF持久化机制，将修改的买一条指令都记录到appendonly.aof中（先写入os cache，在隔一段时间fsync到磁盘）
- 比如执行命令"set iamzrh 24"，aof文件记录如下：
*3
$3
set
$6
iamzrh
$2
24
- 这是一种resp协议格式数据，* 后面数字代表有多少个参数，$后面数字代表参数的字符。
- 可以通过修改配置文件来打开AOF持久化
appendonly yes
- 每当Redis执行一个写命令时，例如set，这个命令就会添加到AOP文件末尾。当Redis重启时，程序可以通过执行AOF文件的命令来达到重建数据库的目的。
- 关于配置Redis多久才将数据fsync到磁盘中，可以通过以下三个命令配置：
appendfsync everysec
- always：每次有新的命令追加到AOF文件就执行一次fsync，效率低，但数据安全。
- everysec（推荐）：每秒fsync一次，效率较高，产生故障只丢失一秒数据，这种策略兼顾速度与安全。
- no：从不fsync，将数据交给操作系统处理，更快也更不安全。
AOF 重写
- AOF文件可能存在很多没用的指令，所以AOF会定期根据内存的最新数据身材AOF文件。
redis-6379:0>incr iamzrh
(integer) 1
redis-6379:0>incr iamzrh
(integer) 2
redis-6379:0>incr iamzrh
(integer) 3
redis-6379:0>incr iamzrh
(integer) 4
redis-6379:0>incr iamzrh
(integer) 5
redis-6379:0>incr iamzrh
(integer) 6
*3
$3
SET
$6
iamzrh
$1
6
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
- aof文件自上一次重写后文件大小增长了100%会触发重写。
- aof文件要达到64M才会重写。
- AOF还可以手动执行重写，在Redis客户端执行命令bgrewriteaof重写AOF，注意：aof重写redis会fork一个子进程去做，不会阻塞redis客户端读写命令。
RDB和AOF比较
| 命令 | RDB | AOF |
|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 容易丢数据 | 根据策略决定 |
Redis 4.0 混合持久化
- 在Redis重启时，很少使用RDB来恢复内存，因为可能会丢失大量数据。所以通常使用AOF文件恢复数据，但AOF文件恢复shuj相对于RDB来说要很慢，在Redis实例多的情况下，启动可能会话费大量时间。
- Redis 4.0为解决这个问题，推出一种新的持久化机制-混合持久化。可以通过如下配置开启混合持久化配置（必须先开启aof）:
aof‐use‐rdb‐preamble yes
- 开启混合持久化后，在AOF重写是，不再单纯将内存数据转化为RESP命令写入AOF文件，而是将重写这一刻之前的内存作为RDB快照，并且将RDB快照和增量的AOF修改内存数据的命令存放在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
- 在Redis重启时，可以先加载RDB文件，然后在重放增量的AOF日志就可以完全替代之前的AOF全量数据重放，因此启动效率得到提示。
- 混合持久化AOF文件格式如下：
Redis数据备份的策略
- 写crontab定时调度脚本，每小时copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
- 每天都保留一份当日数据到一个目录中，可以保留最近1个月备份
- 每次copy备份时，把太旧的数据删除
- 每天晚上将当前机器的数据备份到另一台机器，防止机器损坏
最后
