1,持久化
Redis的持久化是必须的,当Redis服务宕机后,如果没有持久化,重启服务后redis中的数据都将丢失,所有的数据操作都将直连数据库,系统性能会大幅降低,所以在使用Redis做缓存服务时必须持久化Redis数据。Redis持久化有三种方式:RDB(默认,不推荐)、AOF(可用但不推荐)、混合持久化方式(推荐)。
1.1,RDB(snapshot-快照模式)
RDB的快照模式是指:达到redis服务设定的某个条件(如60s内有1000次数据增/删/该操作)或redis服务器内存使用率达到指定阈值时,将当前内存中所有redis数据写入名为dump.rdb的文件中,做为当前时刻数据快照。
1.1.1,开启方式
redis的RDB持久化方式不需要显试开启,默认就使用该持久化方式,如果想关闭RDB持久化方式,只需注释所有的save触发条件(见1.1.2的触发条件)即可。
1.1.2,触发条件和文件存储位置
触发条件的配置如下,达到任意一个即触发生成dump.rdb。可添加自定义条件。
save 900 1 // 900秒内至少有 1 次数据变化
save 300 10 // 300秒内至少有 10 次数据变化
save 60 10000 // 60秒内至少 10000 次数据变化
dbfilename dump.rdb // 持久化文件名,可手动修改
dir /var/lib/redis // 持久化数据文件存放位置,可修改
1.1.3,生成快照方式及原理
**同步:**等同于调用【save】命令。使用redis数据操作(存取)线程将当前时刻内存数据写入dump.rdb文件中,会阻塞数据操作;
**异步:**等同于调用【bgsave】命令。创建一个子进程,将当前时刻内存数据写入dump.rdb文件,不影响父进程执行数据存取。如果已经有一个后台保存正在运行,或者有另一个非后台保存进程正在运行,特别是正在进行的 AOF 重写,则会返回错误。
注意:在子进程生成快照的同时,父进程有增删改的操作数据,将会采用写时复制机制(Copy-On-Write, COW)保证这段时间的数据同步至RDB文件。原理是bgsave期间父进程的数据修改,将会被复制一份数据副本,bgsvae在写完rdb后再同步数据副本。
1.1.4,RDB模式问题
RDB的生成必须满足触发阈值,生产中不可能设置过于频繁的触发阈值,因为每次生成的RDB都是触发时刻内存中的所有数据。所以当未达到触发阈值时,如果redis服务宕机,则这段时间内的所有操作数据都将丢失。
1.2,AOF(append-only file)
AOF是优于RDB的持久化方式,将redis数据变化的每一条指令记录到文件appendonly.aof中。实际并非直接写入aof文件,先写入服务器缓存,每隔一段时间调用fsync()将数据同步到磁盘文件。
1.2.1,开启方式
redis.conf中有AOF的开启参数,默认为no,开启直接改为yes即可。如果AOF和RDB同时打开,则两种文件(RDB、AOF)都会存在。
appendonly yes
appendfilename "appendonly.aof" // 生成的文件名,可手动修改名称
1.2.2,触发条件
同RDB方式一样,AOF也有自己的触发条件
appendfsync no // 不主动发起同步,由操作系统决定何时同步。快,但不安全
appendfsync always // 每个修改数据的命令都同步至AOF文件中。慢,但安全
appendfsync everysec // 默认。每秒发起一次同步。若同步前redis宕机则丢失1秒数据
1.2.3,AOF文件解析
RDB文件是数据二进制文件,打开时内容如同乱码,如图:
AOF是将修改数据指令存入文件,如图:
1.2.4,AOF优化策略:AOF重写
通过上面的文件解析可知,AOF恢复数据的方式是依次执行AOF文件中的命令。但实际情况下,AOF中有很多冗余的命令,如下方场景:
为某篇文章累加阅读量。假如阅读量累加到5时,redis宕机,此时恢复数据不需依次累加,实则只需执行 set readcount-article1 5即可。基于类似数据场景,AOF提供了内置的优化机制:
AOF重写:达到重写的触发条件后,redis将根据当前内存数据,重新生成AOF文件。
触发条件配置:
auto-aof-rewrite-percentage 100// aof文件自上次重写后,文件大小增长100%则触发再次重写
auto-aof-rewrite-min-size 64mb// aof文件达到64M时重写
使用命令【BGREWRITEAOF】手动触发一次重写,查看上述累加重写前后文件内容:
注意:重写时,AOF模式采用类似RDB的【bgsave】方式,新建一个子进程重写AOF文件,故重写是不会影响主进程的redis数据操作。
1.2.4,AOF模式问题
如果redis运行时间很长,AOF文件将会巨大无比,即便使用了AOF重写,恢复数据时仍旧可能会非常缓慢。
1.3,混合持久化方式
RDB持久化方式,数据文件小(二进制数据),恢复数据快,缺点是容易丢失数据。AOF持久化方式,虽然安全但数据文件较大,恢复数据慢。混合持久化整合了两种方式的优点,混合持久化的AOF数据文件由两部分组成:[RDB file] 和 [AOF tail]。
具体原理:当数据量未达到AOF重写阈值时,数据已redis命令方式写入AOF文件,当触发AOF重写时,当前时刻的数据将以RDB数据格式写入新的aof文件(RDB file),重写过程中的redis数据操作仍旧已命令方式追加写入该文件(AOF tail)。当重写完成后,新AOF文件替换旧的AOF文件。混合持久化文件内容如下:
1.3.1,开启方式
redis.conf中有混合持久化的开启参数,默认为no,开启混合持久化方式,需先开启AOF方式,再将下述参数改为yes即可。
aof-use-rdb-preamble yes
开启后,重写AOF,重写前的AOF参考1.2.3,重写后AOF如下,
1.3.2,触发条件
使用AOF方式的触发机制。tip:当使用混合持久化方式时,可关闭RDB持久化方式。
2,数据恢复
恢复redis数据非常容易,只需将对应的数据文件放入redis.conf中配置的数据文件目录里即可。如上述案例中,数据文件的存储位置为:
只需将待恢复数据的文件:dump.rdb或appendonly.aof文件放入该目录,重启reids时会自动恢复文件中数据。
注意:虽然本章实现了数据的持久化,但当Redis宕机,如果数据操作量巨大,相当于出现【缓存穿透】现象,将极大降低系统性能。故生产中使用Redis一般都会使用主从架构,将在下章讲解。