redis数据持久化

一.RDB

优势：

• RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

• 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势：

• RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)

• RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

丢失原因：
Redis实现快照的过程Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

RDB恢复数据：

需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。我实际操作，在redis.conf 配置文件中指定了dump.rdb文件的存放目录，没有将dump.rdb文件移动到 redis 安装目录，关闭redis服务，过一段时间重启后redis数据恢复了。恢复数据中有设定有效期的数据，如果还有效则会减少相应的有效期时间，即数据的有效期即使在宕机那段时间也是正常减少的。

默认安装完成就会自动开启的RDB持久化模式。当网站数据量变大，该文件也会随之增大，操作效率很低。
存盘机制（redis.conf 配置文件中关于save的配置）：
save 900 1 代表的含义：如果在900s或者900s以上有1次对key的操作则把内存数据持久化到磁盘上
save 300 10 代表的含义：如果在300s或者300s以上有10次对key的操作则把内存数据持久化到磁盘上
save 60 10000 代表的含义：如果在60s或者60s以上有10000次对key的操作则把内存数据持久化到磁盘上

二.AOF

类似mysql的binlog日志【读写分离的时候】，该文件把用户的操作记录包括查询的过程全部记录，当服务器出现问题的时候，那么redis会将数据从内存中保存到aof文件当中，当服务器重新运行时那么aof就会根据操作的记录把数据重新还原到Redis的内存当中过去，以却保数据的完整性。即aof的持久化模式是记录用户的操作而非实时数据记录。

如果aof的模式一旦启动，那么快照就会失效，redis就会把所有的数据缓存到内存当中，如果你发生重启，停止，关闭服务器等行为，那么aof文件就会把内存中数据同步到硬盘中。

• 打开AOF模式：
  在redis.conf 配置文件将appendonly on 改为yes。

• 存盘机制（redis.conf 配置文件中关于appendfsync的配置）：
  appendfsync值：

1. no：
   Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
2. everysec：
   Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
3. always：
   每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

建议采用 appendfsync everysec（缺省方式

• AOF恢复数据：
  与RDB一样，只是读的文件变成了appendonly.aof了。恢复数据中有设定有效期的数据，如果还有效则会减少相应的有效期时间，即数据的有效期即使在宕机那段时间也是正常减少的。

AOF重写目的：
为了减小aof文件的体量，可以手动发送“bgrewriteaof”指令，通过子进程生成更小体积的aof，然后替换掉旧的、大体量的aof文件。

• AOF重写原理：
  redis主进程创建子进程，将内存中数据转为写指令写入新的AOF文件，同时在存在子进程后将写的操作在写入缓存叠加进AOF文件，在替换掉旧AOF文件。在这里子进程把数据转为写指令存入新的AOF文件时，记录的只是每个数据的最后一次写指令，也就是最新的数据，不会记录之前冗余的操作，所以这样会很大程度的缩小AOF的体量，同时，该操作是产生新的AOF文件进行写入，而不是在原有文件上的修改。而缓存中叠加到新的aof的操作仍是新增的全部操作，但是这些数据已经很有限，相比之前的一股脑添加，这种机制很好的解决的AOF文件不断增大的问题。

• 重写的redis.conf相关配置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

含义：在aof文件体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写。

三.RDB与AOF同时开启

快照模式可以和AOF模式同时开启，互不影响。
默认无脑加载AOF的配置文件
相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB
AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同