Redis笔记之持久化(RDB和AOF)

Redis持久化

• 1. 持久化-RDB
• • 1.1 概念
  • 1.2 工作原理
  • 1.3 触发机制
  • 1.4 触发持久化规则
  • 1.5 bgsave
  • 1.6 bgsave和save对比
  • 1.7 RDB优缺点
• 2. 持久化-AOF
• • 2.1 概念
  • 2.2 使用AOF
  • 2.3 AOF优缺点
• 3. RDB和AOF比较
• • 3.1 对比RDB和AOF
  • 3.2 如何选择使用哪种持久化方式？

1. 持久化-RDB

1.1 概念

---

RDB：Redis Database，指在指定时间间隔后，将内存中的数据集快照写入数据库；在恢复时候，直接读取快照文件，进行数据的恢复。

默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中，文件名可以在配置文件中进行自定义。

1.2 工作原理

---

在进行RDB的时候，redis的主线程是不会做IO操作的，主线程会fork一个子线程来完成该操作；

1. Redis 调用forks。同时拥有父进程和子进程。
2. 子进程将数据集写入到一个临时RDB文件中。
3. 当子进程完成对新RDB文件的写入时，Redis 用新的RDB文件替换原来RDB文件，并删除旧的RDB文件。

这种工作方式是的Redis 可以从写时复制（copy-onwrite）机制中获益（因为使用子进程进行写操作，而父进程依然可以接收来自客户端的请求）。

1.3 触发机制

---

1. save的规则满足的情况下，会自动触发rdb原则
2. 执行flushall名， 也会触发我们的rdb原则
3. 退出redis，也会自动产生rdb文件

• save
  使用save命令，会立刻对当前内存中的数据进行持久化，但是会阻塞，也就是不接受其他操作了；

由于save命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

• flushall命令
  flushall命令也会触发持久化

1.4 触发持久化规则

满足配置条件中的触发条件；

可以通过配置文件对Redis进行配置，让它在“N秒内数据集至少有M个改动”这一条件被满足时，自动进行数据集保存操作。

# 持久化规则，持久化到文件  .rdb .aof
save 900 1 # 900秒内至少有1个key进行了修改，就进行持久化
save 300 10 
save 60 10000

只要满足以上任意一个条件，就会触发持久化操作

1.5 bgsave

bgsave 是异步进行，进行持久化的时候，redis还可以继续响应客户端请求；

1.6 bgsave和save对比

命令	save	bgsave
IO类型	同步	异步
阻塞	是	是（阻塞发生在fork()，通常非常快）
复杂度	O(n)	O(n)
优点	不会消耗额外的内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

1.7 RDB优缺点

• 优点：
  1. 适合大规模的数据恢复
  2. 对数据的完整性要求不高
  3. RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。
• 缺点：
  1. 需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。
  2. fork进程的时候，会占用一定的内存空间。

2. 持久化-AOF

2.1 概念

---

AOF：Append Only File，以日志的形式来记录每个写的操作，将Redis执行过的所有指定都记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将指令从签到后执行一次以完成数据的恢复工作。

快照功能（RDB）并不是非常耐久（durable）：如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、以及为保存到快照中的那些数据。从1.1版本开始，Redis增加了一种完全耐久的持久化方式：AOF持久化。

2.2 使用AOF

---

• 要使用AOF，需要修改配置文件：

  appendonly on # 默认是不开启AOF，需要更改为yes
  
  appendfilename "appendonly.aof" # 默认的文件名 
  
  appendfsync everysec # 数据同步策略 每秒执行一次sync
  

• 配置完成后，重启Redis就可以生效了！
• 如果这个aof文件有错误，这时候redis是启动不起来的，我们需要修改这个aof文件
• redis给我们提供了一个工具redis-check-aof --fix

2.3 AOF优缺点

• 优点
  1. 每一次修改都会同步，文件的完整性会更好
  2. 每秒同步一次，可能会丢失一秒的数据
  3. 从不同步的话，效率最高
• 缺点
  1. 相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！
  2. aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

3. RDB和AOF比较

---

3.1 对比RDB和AOF

	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定

3.2 如何选择使用哪种持久化方式？

• 一般来说，如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。
• 如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只是用RDB持久化。
• 有很多用户都只使用AOF持久化，但并不推荐这种方式：因为定时生成RDB快照（snapshot）非常便于进行数据库备份，并且RDB恢复数据集的速度要比AOF恢复的速度更快。