Redis持久化方式

  1. 1、RDB    Redis DB
  2. 2、AOF    AppendOnlyFile 默认关闭

RDB方式

默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。
在RDB方式下，有两种保存方式：

（1）、手动执行持久化数据命令来让redis进行一次数据快照。
  • save：在客户端手动执行save命令，它会阻塞Redis服务，无法响应客户端请求，创建新的dump.rdb替代旧文件
  • bgsave：它是一个异步命令，非阻塞，Redis服务正常接收处理客户请求，这种方式，Redis会fork（）一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕，然后父进程会用新的dump.rdb文件来替代旧文件

注意：Fork发生时，父进程内存共享，所以为了不影响子进程做数据快照，在这期间修改数据，将会被复制一份，而不进共享内存，所以说：RDB所持久化的数据，是Fork发生时的数据，在这样的条件下进程持久化数据，如果因为某些情况宕机，则会丢失一部分数据，如果在实际生产中对数据丢失没那么敏感，丢失的也可以从传统数据库中获取或者丢失部分也无所谓，那么就可以选择RDB持久化方式。

save和bgsave的比较：

  • save不用创建新的进程，速度略快，bgsave需要创建子进程，消费额外的内存
  • save适合停机维护，服务低谷时段，bgsave适合线上执行

（2）、另一种则是根据你所配置的配置文件中的策略，达到策略的某些条件时自动持久化数据，和bgsave执行原理相同
  1. save 900 1
  2. save 300 10
  3. save 60 10000

这是配置文件默认的策略，它们之间是或的关系，每个900秒，在这期间变化至少一个键值，做快照。或者每300秒，变化10个键值做快照。或者每60秒，变化10000个键值，做快照。

AOF方式

append only file，采用追加的方式保存，默认文件是：appendonly.aof

它记录所有的写操作命令，在服务启动的时候使用这些命令可以还原数据库，调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也能丢失一秒数据，相对于RDB来说损失小的多。

（1）、AOF写入机制

事实上，AOF机制并不会立即将命令写入到硬盘文件中，而是写入到磁盘缓存，在接下来的策略中，配置多长时间来将硬盘缓存写入到硬盘文件，所以在一定条件下，还是会丢失数据，不过丢失很少一部分。所以AOF方式不能保证绝对不能丢失数据。

（2）、写入磁盘策略

Redis默认使用ervrysec，就是说每秒持久化一次，而always则是每次操作都会立即写入aof文件中，而no则是不主动进行同步操作，是默认30s一次。

  • Always：服务器每写入一个命令，就调用一个fdatasync，将缓冲区里面的命令写入到硬盘。这中模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据。
  • Everysec：服务器每一秒调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行命令数据。
  • No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外故障时，丢失命令的数量是不确定的。

运行速度：always的速度慢，everysec和no都很快。

（3）AOF重写机制：

AOF有序的记录了redis的命令操作，意外情况下丢失数据很少，它不断地对APF文件添加操作日志记录，redis有专门的优化策略来优化日志记录文件过大的问题。

  1. auto-aof-rewrite-percentage 100
  2. auto-aof-rewrite-min-size 64mb

前者是指超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写，则以启动时为主，后者是限制了允许重写的最小aof文件大小，bgrewritesof命令是手动重写命令，会fock子进程，在临时文件中重写数据库状态对原apf无任何影响，当重建旧的状态后，也会把fock发生后的一段时间内的数据一并追加到临时文件，最后替换原有的aof文件，新的命令继续向新的aof文件中追加。

重写的过程：
（1）fock一个子进程负载重写AOF文件
（2）子进程会创建一个临时文件写入AOF信息
（3）父进程会开辟一个内存缓冲区接收新的写入命令
（4）子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写入操作由子进程写入到临时文件中
（5）新文件替换旧文件

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

AOF重写触发：
手动：客户端向服务器发送BGREWRITEAOF命令
自动：配置文件中配置自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>
触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size，才会考虑是否需要进行重写AOF，这个选项用于避免对体积过小的AOF文件重写
auto-aof-rewrite-percentage <percent>
指定触发所需的AOF文件体积的百分比：当AOF文件的体积大于指定的体积，并且超过上一次重写之后的AOF文件体积的percent%时，就会触发AOF重写。这个值设置为0表示关闭自动AOF重写。

举例：

  1. auto-aof-rewrite-percentage 100
  2. auto-aof-rewrite-min-size 64mb
  3. appendonly no / yes

当AOF大于64M的时候，可以考虑AOF文件重写
只有当AOF文件的增量大于起始值size的100%时，启动重写， 默认是关闭

RDB和AOF比较：

1、RDB

优点：

  • 完全备份，不同时间的数据集备份可以做到多版本恢复
  • 紧凑的单一文件，方便网络传输，适合容灾恢复
  • 恢复大数据集速度比AOF快

缺点：

  • 会丢失最近写入，修改的未能持久化的数据

  • fock过程非常耗时，会造成毫秒级不能响应客户端请求

    2、AOF

    优点：

  • 写入机制，默认是ervrysec每秒执行，性能好不阻塞服务，最多丢失一秒数据

  • 重写机制，优化AOF文件
  • 如果误操作，比如fulshall等，只要AOF未被重写，停止服务，移除AOF文件尾部FUSHALL命令，重启redis，可以将数据集恢复到flushall执行前的状态

缺点：

  • 相同数据集，AOF文件体积比RDB大很多
  • 恢复数据库速度比RDB慢