Redis的持久化有两种策略,RDB(定期备份)和AOF(实时备份).
1.1 RDB(Redis Database): 分为两种,手动触发(使用save/bgsave命令)和自动触发(规定时间内修改次数到达指定数量).
1.2 先说说手动触发
sava指令会让redis放下手头工作全力以赴的去备份,而redis又是一个单线程的数据库,这就会导致阻塞问题,当数据量过大的时候阻塞的后果非常严重.
而bgsave则会fork出一个子进程,这个子进程与父进程几乎一样,拥有父进程的数据和文件描述符表等等.
1.3再说说自动触发
在配置文件/etc/redis/redis.conf里有这么几行
格式为save m n其中m是时间,n是修改的次数,意思是当m时间结束后如果修改了n次那么就触发自动备份.save “”是不进行自动备份.
1.4 bgsave的执行过程
当bgsave到达服务器后会先判断是否正在备份,是的话就直接返回,否则就fork一个几乎一模一样的子进程,通过子进程来生成一个快照,
1.5 RDB文件
这个快照就是RDB文件(二进制文件),在redis服务器重新启动的时候会从rdb文件里读取数据到内存中,默认是dump.rdb,值得一提的是虽然生成快照有很多种方法但是,快照始终只有一个
.
那么问题随之而来,如果rdb文件被修改了会发生什么呢?有的修改会导致redis启动失败有的则不会,在启动redis的时候可以提前检查rdb的完整性
2.1 AOF(Append only file)
2.2 AOF也是Redis备份的一种机制,主要是记录redis的操作比如set key 111等等.相比于RDB,他的优势在于实时性更强,但是资源消耗更多.
默认是no不开启改为yes为开启
在redis的配置文件中可以找到这么一行来打开这个设置,当同时启用RDB和AOF时以AOF为准
2.3 AOF的工作流程
当redis运行时写入的每一个命令都会先存入到缓冲区,然后到了预设要求写入AOF文件中,由于命令过多且有很大的冗余,会触发重写操作,对命令进行一个整理.当服务器重启时就会重AOF中读取数据
2.4文件同步
那么如果在缓冲区的数据还没写入文件时,服务异常中断了会不会丢失这部分数据,答案是是的,虽然AOF重在实时数据备份但写入硬盘的次数越多消耗资源越多,为了取舍只能这样.为此Redis给了我们三个解决方案
always : 每执行一次就写入文件一次
everysec : 每秒写入一次
no : 全看操作系统控制,一般来说就是缓冲区满了
2.5重写机制
当记录的命令过多的时候一方面会让文件过大拖累服务启动速度,一方面有很多命令都是相互抵消的,比如 set key 111 set key 222 相当于 set key 222,Redis针对这种情况采用了一种重写机制,分为手动触发和自动触发
手动触发 : bgrewriteaof
自动触发 : 在配置文件里设置
2.6 AOF重写流程
当服务器收到备份的指令,首先会判断是否有其他备份指令,如果是AOF则直接返回,是RDB则会等待RDB备份完毕,然后fork出一个一模一样的子进程用于备份,同时原缓冲区继续往旧的AOF文件里写入,还会给新的缓冲区也发送相同的命令用于写入新的AOF文件,当子进程完成重写以后会通知父进程替换AOF文件.
看起来和RDB类似,只是AOF的备份比RDB更加准确.
2.7 混合持久化
对于计算机二进制文件比文本文件更容易读懂,资源消耗更少所以Redis提供了混合持久化机制在重写时把数据写为RDB的形式,后续追加以AOF的形式.