redis持久化策略

redis的持久化

Redis是一个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务或者断电会丢失。

Redis的数据也支持写到硬盘中，这个过程就叫做持久化。

Redis提供了2种不同形式的持久化方式。

• RDB（Redis DataBase）
• AOP（Append Of File）

1、RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

**备份执行原理：**Redis会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化过程都 结束后，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这 就是确保了极高的性能，如果需要进行大规模的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

RDB持久化流程：

如果需要修改备份文件的名称以及文件存放目录，可以在redis.conf文件中进行修改。

#rdb默认备份文件
dbfilename dump.rdb

#备份文件目录默认值，表示执行redis-server启动时所在的目录
dir ./

1.1、Fork

• Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器 等）数值都和原进程一致，它是一个全新的进程，并作为原进程的子进程。
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调 用，处于效率考虑，linux中引入了“写时复制技术”
• 一般情况父进程和子进程会共用一段物理内存，只有进程空间的各段的内容要发生变化时，才会将 父进程的内容复制一份给子进程。

1.2、触发备份的方式

1.2.1、方式一：自动备份

可在redis.conf中配置自动备份的规则

#默认备份规则，1分钟内修改了一万次，或者5分钟内修改了10次，或者30分钟内修改了1次，都会报错
save 900 1
save 300 10
save 60 10000

save的配置格式：save 秒 操作次数

1.2.2、方式二：手动执行命令备份

有2个命令可以触发备份。

**save：**save时只管保存，其他不管，全部阻塞，手动保存，不建议使用。

**bgsave：**redis会在后台异步进行快照操作，快照同时还可以响应客户端情况。 可以通过lastsave 命令获取最后一次成功生成快照的时间。

1.2.3、flushall命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

1.3、redis.cof一些关于RDB的配置

1. stop-writes-on-bgsave-error：当磁盘满时，是否关闭redis的写操作
2. rdbcompression：rdb备份是否开启压缩
3. rdbchecksum：是否检查rdb备份文件的完整性

1.4、rdb的备份和恢复

1. 先通过config get dir 查询rdb文件的目录

   127.0.0.1:6379> config get dir
   1) "dir"
   2) "/usr/local/software/redis/bin"
   127.0.0.1:6379> 
   

2. 将rdb的备份文件 *.rdb 文件拷贝到别的地方

   cp /usr/local/software/redis/bin/dump.rdb /usr/local/software/redis/bin/dump2.rdb
   

3. rdb的恢复

   • 关闭redis
   • 把备份的文件拷贝到工作目录 cp dump2.rdb dump.rdb
   • 启动redis，备份数据直接加载，数据被恢复

1.5、RDB的优劣势

1.5.1、优势

1. 适合大规模数据恢复
2. 对数据完整性和一致性要求不高更适合使用
3. 节省磁盘空间
4. 恢复速度快

1.5.2、劣势

1. Fork的时候，内存中的数据会被克隆一份，大致2倍的膨胀，需要考虑
2. 虽然Redis在fork的时候使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能
3. 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down的话，就会丢失最后一次快照后 所有修改

1.6、停止RDB

动态停止RDB：redis-cli config set save "" #save后给空值，表示禁用保存策略。

2、AOF（Append Only File）

aof是以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记 录），只允追加文件但不可改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启 的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

aof的持久化流程：

• 客户端的请求写命令会被append追加到AOF缓冲区内
• AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
• AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
• redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

aof默认是不开启的，可以配置redis.conf来开启aof配置。

appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
appendfilename "appendonly.aof" # aof文件名称，默认为appendonly.aof
dir ./ # aof文件所在目录，默认./，表示执行启动命令时所在的目录，比如我们在/opt目录中，去执行redis-server /etc/redis.conf 来启动redis，那么dir此时就是/opt目录

如果AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）。

2.1、AOF同步频率设置

在redis.config中配置AOF同步的频率，通过配置appendfsync的值来进行配置

• appendfsync always：每次写入立即同步

  始终同步，每次redis的写入都会立刻记入日志；性能较差但数据完整性比较好。

• appendfsync everysec：每秒同步

  每秒同步，每秒记录日志一次，如果宕机，本秒数据可能丢失；更新的命令会放在内存中AOF缓冲区， 每秒将缓冲区的命令追加到AOF文件

• appendfsync no：不主动同步

  redis不主动进行同步，把同步交给操作系统。

2.2、AOF的优劣势

2.2.1、优势

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文本，通过操作AOF文件，可以处理误操作

2.2.2、劣势

• 比RDB占用更多的磁盘空间
• 恢复备份速度要慢
• 每次读写都同步的话，有一定的性能压力
• 存在个别bug，造成不能恢复