参考资料:
redis 4.x cookbook 中文版;
redis官方文档
注: 本文redis的版本为: 5.0.3
RDB快照:
快照机制是redis的一种持久化策略;
简单描述下就是:每隔一段时间(redis.conf中可以配置),将当前数据库的内容备份到磁盘上;下次启动服务时,将会自动从.RDB文件中恢复数据;
#下面三个设置意思是:
#每900秒,且至少进行了一次键值对修改;将触发一次rdb快照;
#每300秒,且至少进行了10次键值对修改;将触发一次rdb快照;
#每60秒,且至少进行了10000次键值对修改;将触发一次rdb快照;
#注释掉save,将不会触发rdb快照;
#save "" 也会禁止rdb快照;
save 900 1
save 300 10
save 60 10000
#如果启用RDB快照(至少配置一个保存点[save xxx xxx])并且最新的后台保存失败,则Redis将停止接受写入.
#假如设定了持久化监控,那么建议关闭此配置,这样可以让redis在系统和磁盘出问题的时候,依然可以接收数据;
stop-writes-on-bgsave-error yes
#是否在保存rdb快照文件时使用压缩字符串对象;
#如果选择'yes'将会提高cpu消耗,选择'no'会占用更多空间,通常'yes'更占优;
rdbcompression yes
#持久化之前是否进行校验;
#yes开启校验,有更高的抗损坏性,但是保存或读取rdb快照文件损失10%性能;
#no关闭校验,意味着checksum的值永久为0,读取rdb快照文件时将不再进行校验;
rdbchecksum yes
#rdb快照文件名称;
dbfilename dump.rdb
#rdb快照工作目录,注意,此处仅能设置文件夹,生成的文件以dbfilename为准;
dir /var/lib/redis
在客户端在中,我们可以使用如下命令来触发RDB持久化:
127.0.0.1:6379> set key1 value1 nx
OK
127.0.0.1:6379> keys *
1) "key1"
127.0.0.1:6379> get key1
"value1"
#手动触发快照;注意了,save命令是阻塞的,意味着除非此命令执行完成,否则不接收其他命令;生产环境禁用;
127.0.0.1:6379> save
OK
#手动触发快照;此处是由redis分出一个子子进程,进行快照;redis的主进程依然可以接收命令;
#子进程在快照的时候,生成一个临时快照文件;
#在持久化完成之后,历史快照文件将会被删除,临时文件将以dbfilename 配置的值重命名;
127.0.0.1:6379> bgsave
Background saving started
AOF持久化
AOF持久化是指,通过追加文件的方式进行持久化;
在配置文件中,可以决定是相隔多久向AOF文件中追加一次数据,或者是每写入一次数据库就追加一次;(这里的追加,是指将数据刷新到磁盘上,也即是配置文件中的appendfsync)
#AOF是对持久化文件(AOF文件)进行追加的一种持久化方式;
#前面的RDB持久化,由于每次都需要对数据库进行快照,所以注定是要间隔一段时间才能进行一次;
#出现断电情况时,将会丢失几分钟的数据;
#AOF是每次写入都会追加,哪怕断电也顶多丢失一秒钟写入的数据;
#AOF,RDB可以同时开启;AOF文件是非二进制压缩文件,占用空间大;
#RDB优点是二进制压缩文件可以快速还原;AOF优点是,数据丢失量更少;
#默认关闭AOF
appendonly no
#aof文件名称;
appendfilename "appendonly.aof"
#fsync,是指通知系统将从内存中输出的数据刷新到磁盘上(某些系统根据调用立即刷新,某些系统是尽快刷新)
#下面的配置有三个值:
#no,由操作系统决定什么时候刷新;(速度最快,但是丢失的数据较多)
#always,每个写操作都刷新;(速度最慢,但是安全)
#everysec,每秒同步刷新一次;(妥协值)
appendfsync everysec
#当aof设置为每秒或者是每次操作都fsync()时,后台如果进行BGSAVE/触发AOF追加(会有大量的磁盘IO);
#如果主线程也进行追加,也会调用fsync(),这种情况下,会触发阻塞;linux中最长阻塞可达30s;
#如果配置为no,则进行追加,即主线程阻塞;如果设置为yes,则不追加,
#并将数据写入到缓冲区aof_rewrite_buf_blocks,等到子进程的fsync()执行完成后,通知主线程进行fsync();
#因为存在缓冲区的数据没有持久化到数据库,这样就有可能会丢失阻塞时间内的数据;
#因此,如果不允许主线程出现延时,则选择yes;通常建议no;
no-appendfsync-on-rewrite no
#触发重写aof文件的条件:aof文件已经达到指定值(64M),且与上次AOF文件相比,已经增加了指定百分比(100%)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#redis启动时,发现aof文件因系统原因出现不完整现象的处理设置;
#no,中断redis进程;(用户可以在redis未启动时对aof执行:redis-check-aof修复文件)
#yes,提示用户,继续运行;
#注意,如果aof文件中间因为不明原因出现问题,依然会退出;
#此配置是指在aof文件末尾没有找到足够的字符组成数据;
aof-load-truncated yes
#以RDB文件名称为前缀;同时,在进行持久化时,产生AOF文件,将会以RDB结构为开头,后续部分内容为AOF结构;
#在恢复的时候,redis会优先读取AOF文件(因为默认AOF文件数据会更完整)进行恢复;
#这种设置,可以更快的持久化,更快的恢复,更小的AOF文件;默认为yes;
#如果不开启aof,此处开启了也毫无意义;
aof-use-rdb-preamble yes
#lua脚本执行的最大时间,设置0,不做限制;单位s;
lua-time-limit 5000
在客户端,可以通过命令来主动触发AOF文件的重写;
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
查看上次持久化时间
127.0.0.1:6379> LASTSAVE
(integer) 1324043588
RDB与AOF混用
由于这两者都有自己的缺点:
RDB可能会丢失较长时间的数据;
AOF会导致持久化文件臃肿以及启动数据库变慢;
所以最好的方式是混合使用它们;
#混用的关键配置:
#以RDB文件名称为前缀;同时,在进行持久化时,产生AOF文件,将会以RDB结构为开头,后续部分内容为AOF结构;
#在恢复的时候,redis会优先读取AOF文件(因为默认AOF文件数据会更完整)进行恢复;
#这种设置,可以更快的持久化,更快的恢复,更小的AOF文件;默认为yes;
#如果不开启aof,此处开启了也毫无意义;
aof-use-rdb-preamble yes
扩充资料: