RDB (Redis database)

RBD的类型

  1. save，该方式为同步方式，会阻塞其他redis命令；
  2. bgsave, 该方式为异步方式，fork子进程来进行持久化，只有在执行fork函数的时候才会短暂阻塞，其他时间不会阻塞客户端命令。该方式为默认方式。

bgsave流程

  1. 先单独创建（fork）出一个子进程来进行持久化，将数据写入临时文件中，即临时RDB文件；
  2. 等持久化过程结束了，用临时RDB文件来替代旧的 上次的持久化文件。

image.png

优点

  • 在这个过程中，主进程不做任何IO操作，因此保证了极高的性能；
  • 如果需要对大规模的数据进行恢复，并且对数据恢复的完整性不是很敏感，RDB的方式比AOF要高效；

缺点

  • 最后一次持久化的数据会丢失。
  • fork进程的时候，会占用一定的空间。

文件名

默认保存的文件名为dump.rdb。

  1. # The filename where to dump the DB
  2. dbfilename dump.rdb

持久化的规则

  1. # 如果900秒内，至少以1个key进行了修改，进行持久化操作。
  2. save 900 1
  4. # 300秒内，至少有10个key进行了修改，进行持久化操作
  5. save 300 10
  7. # 60秒内，至少1000个key进行了修改，进行持久化操作 => 高并发情况
  8. save 60 10000
  10. # 我们也可以自己定义持久化规则
  11. save 60 5 # 60秒设置5个key就进行一次持久化
  1. 满足上面的规则的时候，触发持久化
  2. 执行flushall命令，也会触发持久化
  3. 退出redis，也会触发持久化

恢复rdb文件

  1. 只需要将rbd文件放在redis启动目录就可以了，redis会自动检查dump.rdb并恢复其中的数据；
  2. 查看redis的启动目录。

image.png

AOF（Append Only File）

即，将我们的所有命令都记录下来，history, 恢复的时候就把这个文件都执行一遍。

配置文件

默认不开启

  1. appendonly no

保存规则

  1. # appendfsync always # 每次修改都会同步，消耗性能
  2. appendfsync everysec # 每秒同步一次，但是可能会丢失这一秒的数据
  3. # appendfsync no # 不同步，相当于关闭了。

AOF重写

例如对某个值一直进行 + 1

  1. incre readcount
  2. 1
  3. incre readcount
  4. 2
  5. incre readcount
  6. 3
  7. incre readcount
  8. 4
  9. incre readcount
  10. 5
  11. incre readcount
  12. 6

重写后在AOF里变成:

  1. *3
  2. $3
  3. SET
  4. $2
  5. readcount
  6. $1
  7. 6

等价于set readcount 6

重写规则：
image.png

  1. auto-aof-rewrite-percentage: aof文件自上一次重写后，文件大小增长了100%再次触发重写，例如第一次重写后，文件大小为64M，那么下一次当文件大小为128M才重写。
  2. auto-aof-rewrite-min-size 64mb: 当aof文件为64mb的时候，就重写。

AOF默认是文件无限追加，文件会越来越大，如果文件大小大小64M，fork一个新的进程来将文件进行重写。

手动触发：
我们可以通过手动执行bgrewriteaof来手动触发重写。

破坏配置文件

如果人为了AOF文件，导致文件有错位，redis就会启动不起来，此时需要利用redis提供的redis-check-aof工具来修复AOF文件
image.png

优点

  1. 每一次修改都同步，文件完整性更好；
  2. 默认每秒同步一次，最多丢失一秒的数据；

缺点

  1. aof的文件比rdb要大；
  2. aof的运行效率比rdb慢；

Redis4.0 混合持久化

什么是混合持久化？

结合了ROB和AOF的优点

为什么需要混合持久化？

单纯使用ROB，丢数据多；
单纯使用AOF，效率低；

如何开启混合持久化？

  1. 首先要开启AOF
  2. 然后在配置文件中开启：
    1. aof-use-rdb-preamble yes

混合持久化的特点

AOF在重写时，不再是将命令写入AOF文件中，而是将重写这一刻之前的数据以RDB的格式写入aof文件中，在此之后新增的数据则以RESP命令写入AOF文件中。

新的文件一开始不叫appendonly.aof, 等到重新写完新的AOF文件才会改名，覆盖原有的AOF文件，完成新旧AOF文件的替换。

如图所示：
image.png