引言
如果您是初学Redis,建议先阅读上两篇文章"初识Redis"、"springBoot使用Lettuce整合Redis",如果你想了解作者的话可以阅读"关于我,一位00后程序员";
上两篇文章聊到了初步认识Redis以及springBoot对Redis的整合,我们知道Redis存储之所以速度快,是因为数据存在内存中,那么如果Redis进程退出或者发送宕机的情况下,数据将全部被丢失,因此需要持久化机制来保护数据不会因为故障而丢失数据,提高Redis的灾备能力;
持久化
在之前ActiveMQ的知识中讲解过关于中间件消息的持久化,顾名思义持久化就是将Redis存储在内存当中的数据进行备份到硬盘当中,以备宕机之后存储在重启Redis能够加载宕机之前保存的数据,防止数据的丢失。
Redis中默认有两种持久化方式,一种是RDB模式,另外一种为AOF模式；
RDB:
rdb模式是Redis默认配置的一种持久化的方式,也有人叫作快照模式,它会在Redis配置中指定的规则在某个时间点进行数据快照,也就是将当前的所有数据,使用二进制的格式写入到一个rdb文件保留在硬盘中,(rdb文件是一种紧凑型的数据文件,适用于保存某个时间点的数据、方便传输),在宕机重启后会自动读取该文件中的快照数据从而避免数据丢失；
优点:该模式在触发持久化规则后,会调用fork出一个单独子线程,子线程负责将数据写入,从而使在做持久化操作过程中不会影响到主线程,保持Redis的性能;
缺陷:该模式是根据配置规则进行间隔的持久化操作,没法做到时实备份,在宕机情况下如果触发到该备份规则,就有可能导致数据丢失,并且在进行持久化操作时,如果数据量比较大会发生阻塞Redis服务器,直到持久化过程结束;
Redis默认启动了RDB持久化模式,所以在我们用使用Redis中关闭Redis服务再启动会保留关闭之前备份的数据,如果你需要修改该规则配置,可以修改redis.conf中以下几个属性;
默认:
//指定文件存储名称dbfilename dump.rdb//执行备份规则save 900 1save 300 10save 60 10000//是否压缩rdb文件rdbcompression yes以上就是Redis默认持久化的一些关键配置,这里的save属性有2个参数,第一个代表时间(秒为单位),第二个代表Redis中的值被修改的数量,这里配置了三个规则,第一个save 900 1的解释也就是在900秒之内操作了一个值即触发持久化机制,第二个为300秒之内操作10个值触发,第三个为60秒内操作10000个值触发；
rdbcompression yes 该参数是用来设置是否对rdb文件压缩,压缩意味着会占用额外的cpu资源但是也意味着会生成较小的rdb文件以及较短的网络传输过程;
注意:以上触发持久化机制规则还有一种主动触发方式,就是手动执行shutdown关闭Redis服务时也会触发持久化机制生成RDB文件,但是！如果你以kill -9的方式杀死进程,则不会触发,这也是我们宕机时可能发生的一种情况;
AOF:
AOF模式是以一种以日志形式将Redis每一次变更命令(set)追加到aof日志文件中，从而达到实时备份的效果,重启只需要执行日志中所有命令即可恢复数据；
优点:基于Redis变更命令操作,通过设置实时、秒级写入日志文件实现实时备份或者秒级备份,AOF文件写入以字符串的格式,便于阅读、解析;
缺陷:,因为AOF会对每次的变更操作都进行写入日志(其实只需要保存当前值,一条数据经过多次变更,历史操作是可以被抛弃的),所以AOF文件相对RDB文件要大,并且在恢复数据速度较慢;
Redis中AOF默认是关闭的,如果你需要用到AOF持久化,可以通过在redis.conf文件中配置进行开启;
//yes:表示开启 默认no:表示关闭appendonly yes //指定日志名称appendfilename appendonly.aof //指定同步文件操作的类型:alway/everysec/no,默认为everysecappendfsync everysec //重写时是否可以运用appendfsync，默认no,用来保证数据安全性no-appendfsync-on-rewrite no //设置重写基准值,默认为64mauto-aof-rewrite-min-size:64mb//设置重写基准值,默认为100%auto-aof-rewrite-percentage 100以上就是AOF中关键的一些配置属性,这来解释一下个别属性的原理,关于appendfsync的几种策略类型代表的是对aof文件的写入设置;
首先解释三个关键词:
write :Linux在内核提供页缓冲区用来提高硬盘IO性能,write操作在写入系统缓冲区后直接返回,同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
fsync :将指定文件的内容强制从内核缓存刷到磁盘。
bgrewriteaof机制:在一个子进程中进行aof的重写,从而不阻塞主进程对其余命令的处理,同时解决了aof文件过大问题。
三种策略:
always:代表时刻写入,只要你做出变更操作，首先即会立马写入到aof缓冲区,由fsync操作同步到aof文件中,这种策略是最安全的,但效率并很高取决于磁盘速度;
everysec:代表做出变更操作后每秒进行写入到aof缓冲区后调用write操作,fsync同步文件会由bgrewriteaof机制每秒调用一次,该策略是Redis中默认选择的,性能一般,有可能会丢失数据,但最多丢失最后一秒的数据,也是使用的最多的;
no:代表做出变更操作后直接写入到缓冲区中,调用write操作不会对aof文件做fsync同步而由操作系统负责,该策略性能是最快的,但是容易丢失数据;
Redis重写机制:随着AOF文件不断的写入,它的大小会随着不断增大,而它的大小就影响着恢复效率,而对于AOF的历史命令是可以抛弃的,所以Redis自带的重写机制基于copy-onwrite对内存中的数据进行全部遍历,将其写入到另一个aof文件中,而新变更的操作还会存入到原aof文件当中,同时这些新变更的操作也会被存入缓存区当中,当内存数据全部被写入到新aof文件中后,新的变更命令也会一致存入到新的aof文件夹中并重命名为appendonly.aof;
总结:
两者各有各的优缺点,选择是由业务所定;
1.如果业务对数据安全从而牺牲效率,那优先选择AOF模式进行持久化备份;
2.如果业务需要对大规模的数据备份,并且对数据的完整性要求不高,RDB也是种不错的选择;
