redis的RDB持久化机制

RDB和AOF持久化机制介绍

RDB

• RDB机制就是，每隔几分钟，几小时，几天，生成redis内存中数据的一份完整的快照，新快照会替换老快照
  
  

AOF

• AOF机制对每一条写入命令作为日志，以append-only的模式写入一个日志文件中，redis重启的时候可以根据这个AOF日志文件中的写入命令重新构建数据。
• rewrite机制，AOF会不断的写入数据，导致文件不断膨胀，达到一定程度大小redis会进行rewrite操作，AOF rewrite操作会基于当时redis内存中的数据，重新构建一个AOF文件，然后将旧文件删除。
• AOF不是直接将命令日志写入磁盘，因为现代操作系统写文件不是直接写入磁盘，而是先写入操作系统的os cache中，然后到一定时间再从os cache中写入磁盘，而redis会每隔一定时间（如1秒）调用操作系统fsync操作，强制将os cache中的数据写入磁盘。
  
  

如果同时使用RDB和AOF两种持久化机制，那么redis重启是会适合于AOF来构建数据，因为AOF的数据更加完整

RDB和AOF持久化机制优缺点

RDB持久化机制的优缺点

优点

• RDB会生成多个数据文件，每个数据文件都代表了某一时刻中redis的数据，这种多个文件的方式非常适合做冷备，可以将这种文件上传到云服务器，以预定好的策略来定期备份redis 中的数据。
• RDB对Redis对外提供的读写服务，影响非常小，可以让Redis保持高性能，Redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化。
• RDB就是一份数据文件，恢复时直接加载到内存中即可速度非常快，而AOF存放指令日志，进行数据恢复时，其实是要回放和执行所有的指令来恢复数据，速度慢。
  
  

缺点

• RDB都是每隔5分钟或者更长时间生产一次，如果出现故障，就会丢失最近这5分钟的数据
• fork子进程执行RDB持久化时，如果数据文件特别大，可能会导致客户端服务暂停数毫秒，甚至数秒，一般不要让RDB的间隔太长，否则每次生产的文件太大，对Redis本身性能有影响。
  
  

AOF持久化机制的优缺点

优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔一秒，通过后台线程执行一次Fsync操作，将os cache中的数据强制刷入磁盘，这样最多丢失1秒钟的数据。
• AOF日志文件以append-only模式写入，没有磁盘寻址开销，性能非常高，文件不容易破损，即使破损，redis提供修复工具。
• rewrite操作保证AOF文件不会无限膨胀。
• AOF非常适合做灾难性误删的恢复，比如某个员工不小心用了flushall命令清空数据，只要这个时候后台rewrite操作没有执行，那么就可以立即拷贝AOF文件，删除最后一条flushall命令，然后通过恢复机制进行自动恢复。
  
  

缺点

• 对于同一份数据文件来说，AOF日志文件毕RDB数据快照更大。
• AOF开启后，支持写的QPS会比RDB支持写的QPS低，因为AOF一般会配置成每秒Fsync一次日志文件
• 唯一比较大的缺点，其实就是做数据恢复的时候，会比较慢
• 不太合适做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适
  
  

RDB和AOF持久化机制选择

综合使用RDB和AOF两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF文件都丢失和损坏不可用的时候，还可以用RDB来进行快速的数据恢复。

RDB和AOF持久化配置
1. RDB持久化机制配置

在redis.conf文件中进行RDB持久化方案配置

  save 60 1000
  # 60秒之内，有超过1000个key发生变化，生成一个新的dump.rdb文件，删除旧文件，这个操作也被称为snapshotting 快照, 也可以手动调用save或者bgsave命令，同步或者异步执行rdb快照生成
  # save可以设置多个，save也被称为检查点，每个检查点时间到期，就去check一下，是否有对应数量的key发生变更，如果有生成一个新的dump.rdb

1.1 RDB持久化机制工作流程

• redis根据配置自己尝试去生成rdb快照文件。
• fork一个子进程出来。
• 子进程尝试将数据dump到临时的rdb快照文件中。
• 完成rdb快照文件生成之后，就替换之前旧快照文件。
  
  

2. AOF持久化机制配置

AOF持久化，默认是关闭的，默认打开的是RDB，修改redis.conf配置文件中的 appendonly yes 开启AOF持久化在生产环境AOF都需要开启

AOF持久化打开之后，redis每次接受到一条命令，就会写入日志文件中，当然是先写入os cache中，然后每隔一段时间fsync一下。

2.1 AOF的fsync策略

• always： 每次写入一条数据立即将这个数据fsync到磁盘上，性能非常差，吞吐量小，可以保证数据不丢失。
• everysec：每秒将os cache中数据fsync到磁盘, 这个最常用，生产环境一般使用这个，性能很高，QPS上万。
• no：redis只负责将日志写入到os cache就不管了，然后os cache根据自己的策略将数据刷入磁盘，不可控。
  
  

2.2 AOF的rewrite策略配置

在redis.conf 文件中修改配置实现

  auto-aof-rewrite-percentage 100 #增长百分比
  auto-aof-rewrite-min-size 64mb #增长超过多少大小
  ​
  举一个例子：
  比如上次AOF rewrite之后的文件大小是128md，redis继续写入日志，单发现增长比例超过之前的100% （也就是256md），并且增长大小超过64md，那么就会触发rewrite

2.3 rewrite执行流程

• redis fork一个子进程
• 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
• 这时候redis主进程，还会接收客户端命令，redis会将这些新日志写入旧的aof文件中。
• 子进程完成操作后，redis主进程会将新的日志写入新的aof文件中（新日志指子进程rewrite过程中产生的日志）
• 用新日志替换旧的日志。
  
  

                                                     redis的RDB持久化机制

RDB和AOF持久化机制介绍

RDB

• RDB机制就是，每隔几分钟，几小时，几天，生成redis内存中数据的一份完整的快照，新快照会替换老快照
  
  

AOF

• AOF机制对每一条写入命令作为日志，以append-only的模式写入一个日志文件中，redis重启的时候可以根据这个AOF日志文件中的写入命令重新构建数据。
• rewrite机制，AOF会不断的写入数据，导致文件不断膨胀，达到一定程度大小redis会进行rewrite操作，AOF rewrite操作会基于当时redis内存中的数据，重新构建一个AOF文件，然后将旧文件删除。
• AOF不是直接将命令日志写入磁盘，因为现代操作系统写文件不是直接写入磁盘，而是先写入操作系统的os cache中，然后到一定时间再从os cache中写入磁盘，而redis会每隔一定时间（如1秒）调用操作系统fsync操作，强制将os cache中的数据写入磁盘。
  
  

如果同时使用RDB和AOF两种持久化机制，那么redis重启是会适合于AOF来构建数据，因为AOF的数据更加完整

RDB和AOF持久化机制优缺点

RDB持久化机制的优缺点

优点

• RDB会生成多个数据文件，每个数据文件都代表了某一时刻中redis的数据，这种多个文件的方式非常适合做冷备，可以将这种文件上传到云服务器，以预定好的策略来定期备份redis 中的数据。
• RDB对Redis对外提供的读写服务，影响非常小，可以让Redis保持高性能，Redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化。
• RDB就是一份数据文件，恢复时直接加载到内存中即可速度非常快，而AOF存放指令日志，进行数据恢复时，其实是要回放和执行所有的指令来恢复数据，速度慢。
  
  

缺点

• RDB都是每隔5分钟或者更长时间生产一次，如果出现故障，就会丢失最近这5分钟的数据
• fork子进程执行RDB持久化时，如果数据文件特别大，可能会导致客户端服务暂停数毫秒，甚至数秒，一般不要让RDB的间隔太长，否则每次生产的文件太大，对Redis本身性能有影响。
  
  

AOF持久化机制的优缺点

优点

• AOF可以更好的保护数据不丢失，一般AOF会每隔一秒，通过后台线程执行一次Fsync操作，将os cache中的数据强制刷入磁盘，这样最多丢失1秒钟的数据。
• AOF日志文件以append-only模式写入，没有磁盘寻址开销，性能非常高，文件不容易破损，即使破损，redis提供修复工具。
• rewrite操作保证AOF文件不会无限膨胀。
• AOF非常适合做灾难性误删的恢复，比如某个员工不小心用了flushall命令清空数据，只要这个时候后台rewrite操作没有执行，那么就可以立即拷贝AOF文件，删除最后一条flushall命令，然后通过恢复机制进行自动恢复。
  
  

缺点

• 对于同一份数据文件来说，AOF日志文件毕RDB数据快照更大。
• AOF开启后，支持写的QPS会比RDB支持写的QPS低，因为AOF一般会配置成每秒Fsync一次日志文件
• 唯一比较大的缺点，其实就是做数据恢复的时候，会比较慢
• 不太合适做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适
  
  

RDB和AOF持久化机制选择

综合使用RDB和AOF两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF文件都丢失和损坏不可用的时候，还可以用RDB来进行快速的数据恢复。

RDB和AOF持久化配置
1. RDB持久化机制配置

在redis.conf文件中进行RDB持久化方案配置

  save 60 1000
  # 60秒之内，有超过1000个key发生变化，生成一个新的dump.rdb文件，删除旧文件，这个操作也被称为snapshotting 快照, 也可以手动调用save或者bgsave命令，同步或者异步执行rdb快照生成
  # save可以设置多个，save也被称为检查点，每个检查点时间到期，就去check一下，是否有对应数量的key发生变更，如果有生成一个新的dump.rdb

1.1 RDB持久化机制工作流程

• redis根据配置自己尝试去生成rdb快照文件。
• fork一个子进程出来。
• 子进程尝试将数据dump到临时的rdb快照文件中。
• 完成rdb快照文件生成之后，就替换之前旧快照文件。
  
  

2. AOF持久化机制配置

AOF持久化，默认是关闭的，默认打开的是RDB，修改redis.conf配置文件中的 appendonly yes 开启AOF持久化在生产环境AOF都需要开启

AOF持久化打开之后，redis每次接受到一条命令，就会写入日志文件中，当然是先写入os cache中，然后每隔一段时间fsync一下。

2.1 AOF的fsync策略

• always： 每次写入一条数据立即将这个数据fsync到磁盘上，性能非常差，吞吐量小，可以保证数据不丢失。
• everysec：每秒将os cache中数据fsync到磁盘, 这个最常用，生产环境一般使用这个，性能很高，QPS上万。
• no：redis只负责将日志写入到os cache就不管了，然后os cache根据自己的策略将数据刷入磁盘，不可控。
  
  

2.2 AOF的rewrite策略配置

在redis.conf 文件中修改配置实现

  auto-aof-rewrite-percentage 100 #增长百分比
  auto-aof-rewrite-min-size 64mb #增长超过多少大小
  ​
  举一个例子：
  比如上次AOF rewrite之后的文件大小是128md，redis继续写入日志，单发现增长比例超过之前的100% （也就是256md），并且增长大小超过64md，那么就会触发rewrite

2.3 rewrite执行流程

• redis fork一个子进程
• 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
• 这时候redis主进程，还会接收客户端命令，redis会将这些新日志写入旧的aof文件中。
• 子进程完成操作后，redis主进程会将新的日志写入新的aof文件中（新日志指子进程rewrite过程中产生的日志）
• 用新日志替换旧的日志。