RDB和AOF持久化的由来？
因为Redis中的数据是基于内存的，所以如果出现服务器断电或者服务器宕机，那么Redis中存放的数据就会直接丢失。RDB和AOF就是针对Redis提供的两种持久化机制，可以将Redis中的数据持久化到磁盘中。当Redis实例故障重启后，就可以根据备份的文件来进行数据的恢复
二、RDB
概述:
RDB也被叫做Redis数据快照，简单来说就是把内存中所有的数据都记录在磁盘中，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前的运行目录（RDB可以理解周期定时任务,任务内容就是全量备份数据）
每次触发RDB的时候，就会重新生成一个新的RDB文件，覆盖旧的RDB文件文件，这样就可以确保备份得到最新的数据。
RDB的触发策略：
① 关闭Redis实例的时候，redis会在关闭之前主动的进行一次RDB（关闭不是宕机，宕机则数据丢失）
② 当你使用save/bgsave命令的时候，redis也会进行内存数据的持久化
③ 通过配置文件的配置触发：redis.conf配置文件
save 900 1
– 表示在900秒内，redis中有1个key发生改变，那么就进行一次bgsave
save 300 10
– 表示在300秒内，redis中有1个key发生改变，那么就进行一次bgsave
save 60 10000
– 表示在60秒内，redis中有10000个key发生改变，那么就进行一次bgsave
save/bgsave的不同
前面说到可以使用save命令或者bgsave命令来触发RDB，那么两者有什么区别呢？
- 如果使用的是save命令，数据备份就是由主线程来操作的，由于Redis是单线程的，所以如果使用save命令来进行内存的数据备份，那么在数据备份的时候redis是无法响应用户的请求的。当需要备份的数据非常大的时候，就可能导致请求被阻塞超时的情况
- 如果使用的是bgsave命令，那么实际上是主线程fork个子线程，让子线程来进行RDB操作，主线程只是在fork子线程的时候阻塞，之后便可以继续响应用户的请求。接下来子进程即可读取内存数据并进行持久化，生成新的RDB文件替换旧的RDB文件
RDB缺点：
- RDB执行间隔时间长，两次RDB之间写入数据有丢失风险
- fork子进程、压缩、写出RDB文件都比较耗时
RDB优点：
- 使用RDB文件进行数据的恢复速度快、效率高（类似于文件拷贝）
- 相比于AOF持久化的文件，RDB的文件更小
RDB的相关配置：
- 在redis.conf配置RDB文件压缩
# 表示的是是否开启压缩，不建议开启，虽然节省空间，但是会耗费CPU
rdbcompression yes- 在redis.conf配置RDB文件名
# 默认的rdb文件名称
dbfilename dump.rdb- 在redis.conf配置rdb文件存放路径
dir ./- 在redis.conf配置触发策略
# 15分钟内有1个key发生改变，那么就保存
save 900 1
# 5分钟内有10个key发生改变，那么就保存
save 300 10
# 1分钟内有10000个key发生改变，那么就保存
save 60 10000
# 执行的都是bgsave三、AOF
概述：
AOF的全称叫做Append Only File（追加文件）Redis处理的每一个命令都会记录在AOF文件中，可以看做是命令日志文件（AOF存放的不是数据本身而是执行redis写操作的命令，类似于存放insert/update等这类命令而不是数据）
触发策略：根据配置文件触发redis.conf
- 每执行一次命令，立即记录到AOF文件（性能最差，是有主进程执行）
appendfsync always- 写命令执行完先放入AOF缓存区，然后每间隔1s将缓冲区中的数据写到AOF文件，默认设置（性能较好，但是可能丢失1s内的数据）
appendfsync everysec- 写命令执行完先放入AOF缓冲区中，由操作系统决定合适写回磁盘（可靠性比较低，性能最好）
appendfync no配置项 |
刷盘时机 |
优点 |
缺点 |
Always |
同步刷盘 |
可靠性低，几乎不丢数据 |
性能影响大 |
everysec |
每秒刷盘 |
性能适中 |
最多丢失1s数据 |
no |
操作系统控制 |
性能最好 |
可靠性较差，可能丢失大量数据 |
AOF的重写机制：
由于AOF记录的是命令，那么当执行了很多命令的时候，就会记录到很多的冗余命令，例如：
# 添加key1的值
set key1 v1
# 修改key1的值
set key1 v2
# 删除key1的值
del key1实际上key1最后被删除了，那么所有关于key1的命令实际上都是没有作用的，但是AOF中却记录了所有的命令，这样就会导致AOF文件很大而且存放了很多冗余命令。
通过使用bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果，执行完该指令后，所以的冗余指令就会被删除，达到AOF文件压缩的效果。
AOF优点：
- 通过配置，可以使得备份的数据更加完整安全
- 每次进行AOF时占用的CPU资源较少（因为是追加，RDB则是全部重新复制一遍）
AOF缺点：
- 通过使用AOF文件进行恢复的速度较慢，需要依次执行所有指令
- AOF文件可能会比RDB大得多，记录的是所有的写操作
AOF配置：
- 在redis.conf配置AOF开启
# 表示的是开启，默认是no
appendonly yes- 在redis.conf配置AOF文件名
# 这里表示的是AOF文件名称
appendfilename "appendonly.aof"- 在redis.conf配置重写触发策略
# AOF文件比上次文件增长超过百分之百则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才能触发重写
auto-aof-rewrite-min-size 64mb四、RDB和AOF的对比
RDB |
AOF |
|
持久化方式 |
定时对整个内存做快照 |
记录每一次执行的命令 |
数据完整性 |
不完整，两次备份之间会丢失 |
相对完整，取决于刷盘策略 |
文件大小 |
会有压缩，文件体积较小 |
记录命令，文件体积很大 |
宕机恢复速度 |
很快 |
慢 |
数据恢复优先级 |
低，因为数据完整性不如AOF |
高，因为数据完整性更高 |
系统资源占用 |
高，大量CPU和内存消耗 |
低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源 |
使用场景 |
可以容忍数分钟的数据丢失，追求更快的启动速度 |
对数据安全要求较高常见 |
五、知识点：
- 默认方式开启的是RDB，AOF默认是关闭的
六、实际使用
在实际使用中，一般不会单独的开启其中的一个，一般都会使用两者结合的方式一并使用。RDB根据有容灾性，可以周期性的进行RDB得到指定时间点的备份文件。AOF则数据更加的完整，仅仅有非常少的数据的丢失。