Redis持久化之RDB和AOF

Posted on In ,

[toc]
  Redis的强劲性能很大程度上是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中以某种形式同步到硬盘中，这一过程就是持久化。
  Redis支持两种方式的持久化，一种是RDB（Redis DataBase）方式，一种是AOF（Append Only File）方式。可以单独使用其中一种或将二者结合使用。RDB可以理解是基于全量模式的持久化，AOF是基于增量模式的持久化。

RDB方式

  RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。
  RDB是Redis默认采用的持久化方式。打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容：

1
2
3
4
# save <seconds> <changes>
save 900 1
save 300 10
save 60 10000

  save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
  默认的rdb文件路径是当前目录,文件名是dump.rdb,可以在配置文件中修改路径和文件名,分别是dir和dbfilename

1
2
dir ./ # rdb文件存储路径
dbfilename dump.rdb # rdb文件名

  如果没有触发自动快照,需要对Redis执行手动快照操作,SAVE和BGSAVE命令来手动快照,两个命令的区别是前者是由主进程进行快照,会阻塞其他请求,后者是通过fork子进程进行快照。
  注意:由于Redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候,必须保证有16G的内存,要不然会启用虚拟内存,性能非常的差。

快照的过程

（1）Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
（3）当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

  在执行fork的时候操作系统会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。
  通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得可以通过定时备份RDB文件来实现Redis数据库备份。
  RDB文件是经过压缩（可以配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。Redis默认是开启压缩的。
  Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。
  通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

核心思路：fork一个子进程，只有在父进程发生写操作修改内存数据时，才会真正去分配内存空间，并复制内存数据，而且也只是复制被修改的内存页中的数据，并不是全部内存数据；

  • Redis中执行BGSAVE命令生成RDB文件时，本质就是调用Linux中的fork()命令，Linux下的fork()系统调用实现了copy-on-write写时复制；
  • fork()是类Unix操作系统上创建线程的主要方法，fork用于创建子进程（等同于当前进程的副本）；
  • copy-on-write技术，在fork出子进程后，与父进程共享内存空间，两者只是虚拟空间不同，但是其对应的物理空间是同一个；
  • fork()之后，kernel把父进程中所有的内存页的权限都设为read-only，然后子进程的地址空间指向父进程。当父子进程都只读内存时，相安无事。当其中某个进程写内存时，CPU硬件检测到内存页是read-only的，于是触发页异常中断（page-fault），陷入kernel的一个中断例程。中断例程中，kernel就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份。之后主进程使用复制的内存页，子进程还是用之前的内存页。

CopyOnWrite的好处：
1、减少分配和复制资源时带来的瞬时延迟；
2、减少不必要的资源分配；
CopyOnWrite的缺点：
1、如果父子进程都需要进行大量的写操作，会产生大量的分页错误（页异常中断page-fault）;

触发方式

  RDB 持久化触发分为手动和自动两种方式，其中手动方式有两种：save 命令和 bgsave 命令。

  • save 命令：阻塞 Redis 服务，直到整个 RDB 持久化完成。RDB 是全量持久化，如果内存的数据量大，则造成长时间的阻塞，这样势必会影响业务。所以一般不推荐采用这种方式。
  • bgsave 命令：该模式下的 RDB 持久化由子进程完成.Redis 进程接收到该命令后，会 fork 操作创建一个子进程,持久化过程由子进程完成。Redis 服务阻塞只会发生在 fork 阶段，而且该阶段时间过程一般都会很短。

  自动触发的方式是：save m n。该方式在 redis.conf 中进行了说明，m 表示“间隔时间”，n 表示 “变更次数”，只有同时符合这两个条件才会触发，否则“变更次数”会被继续累加到下一个“间隔时间”上。同时，该方式也不会阻塞。

AOF方式

  AOF(append only file)持久化是以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
  默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启： 

1
appendonly yes

  开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改。
  AOF的工作流程操作有：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。

AOF流程

1） 所有的写入命令会追加到aof_buf（缓冲区）中。
2） AOF缓冲区根据对应的策略向硬盘做同步操作。
3） 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4） 当Redis服务重启时，可以加载AOF文件进行数据恢复。

命令写入

  AOF命令写入的内容直接是文本协议格式。AOF文件是纯文本文件，其内容正是Redis客户端向Redis发送的原始通信协议的内容。例如set hello world 这条命令，在AOF缓冲区会追加如下文本：
\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
  介绍关于AOF的连个疑惑：
  1） AOF为什么直接采用文本协议格式？可能的理由如下：
   • 文本协议具有很好的兼容性。
   • 开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免二次处理开销。
   • 文本协议具有可读性，方便直接修改和处理。
  2） AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

文件同步

  虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地 写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用都无法容忍这样的损失，这就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。
  Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制。 

1
2
3
# appendfsync always 每次都同步(最安全但是最慢)
appendfsync everysec 每秒同步(默认的同步策略)
# appendfsync no 不主动同步,由操作系统来决定(最快但是不安全)

  配置为always时，每次写入都要同步AOF文件，在一般的STAT硬盘上，Redis只能支持大约几百TPS写入，这是最安全也是最慢的方式，显然跟Redis高性能特性背道而驰，不建议配置。
  配置为no,由于操作系统每次同步AOF文件的周期，（即每30秒一次），而且会极大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
  配置为everysec,是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性，理论上只有在系统突然宕机的情况下丢失1s的数据。（严格来说最多丢失1s数据是不准确）

重写机制

  随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
  重写后的AOF文件为什么可以变小？有如下原因：
  1）进程内已经超时的数据不再写文件。
  2）旧的AOF文件含有无效命令，如del key1、set a 111、set a 222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
  3) 多条写命令可以合并为一个，如lpush list a、lpush list b、 lpush list c 可以转化为：lpush list a b c。为了防止合并的数据过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型，以64个元素为界拆分为多条。
  
  AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。
  AOF重写过程可以手动触发和自动触发：

手动触发：直接调用 bgrewriteaof 命令
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size: 限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的。
auto-aof-rewrite-percentage: 当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。

  注意，执行AOF重写请求时，父进程依然响应命令，Redis使用”AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

  文件重写流程如下（参考 《Redis 开发与运维》）：

  1. Redis 服务接收到 bgrewriteaof 命令的时候，会做两步检查。

如果当前进程正在执行 AOF 重写，则直接返回。
如果有进程正在执行 bgsave，那么需要等待 bgsave 执行完毕后再执行 AOF 重写。

  2. Redis 进程会 fork 一个子进程执行 AOF 重写，成功后，Redis 服务继续响应命令，不会影响 Redis 原有的 AOF 流程（即命令写入 aof_buf 缓冲区和缓冲区的数据刷进硬盘）。
  3. 在子进程重写过程中，Redis 主进程会将收到的命令也会写入 AOF 重写缓冲区（即命令写入 aof_buf 缓冲区 和 AOF 重写缓冲区），这个缓冲区和 aof_buf 缓冲区不一样，需要区分，这样做的目的是为了防止重写过程中数据的丢失。
  4. 由于使用写时复制技术（copy-on-write），子进程只能拿到父进程在 fork 子进程时刻的文件进行重写。子进程根据内存快照，按照命令重写规则将命令重写到新的文件中。这里需要注意的是每次写入硬盘的数据量不能太大，否则容易导致硬盘阻塞，该值由 aof-rewrite-incremental-fsync 控制，默认为 32M。
  5. 子进程完成 AOF 重写后会给发消息给 Redis 主进程，主进程则会将 AOF 重写缓冲区的数据追加写进新的文件，然后用新的 AOF 文件 替换老的文件。当然，在高并发的情况下，AOF重写缓冲区积累可能会很大，这样就会造成阻塞，Redis后来通过Linux管道技术让aof重写期间就能同时进行回放，这样aof重写结束后只需回放少量剩余的数据即可。
  6. 完成 AOF 重写。

  • 为什么AOF重写不复用原AOF日志？

两方面原因：

  1. 父子进程写同一个文件会产生竞争问题，影响父进程的性能。
  2. 如果AOF重写过程中失败了，相当于污染了原本的AOF文件，无法做恢复数据使用。
重启加载

  AOF和RDB文件都可以用于服务器重启时的数据恢复。AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件城后，Redis启动成功；AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

二者优缺点

RDB 的优缺点

优点：
  1 适合大规模的数据恢复。
  2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
  3 RDB 文件是一个非常紧凑的二进制文件，所以加载的速度回快于 AOF 方式
  4 RDB 文件代表着 Redis 服务器的某一个时刻的全量数据，所以它非常适合做冷备份和全量复制的场景

缺点：
  1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
  2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件。
  3 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

AOF 的优缺点

优点：数据的完整性和一致性更高
缺点：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

总结

  RDB与AOF二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。
  Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。

转载自：
https://blog.csdn.net/cool_summer_moon/article/details/80525302
https://blog.csdn.net/rickiyeat/article/details/53610535
https://blog.csdn.net/a1007720052/article/details/79126253