持久化
RDB
1.(snapshoting 快照) 创建快照存储内存中某时间点上的副本。
2.失败时的情况
例如:redis里目前有10GB数据,上一次快照在下午2:35 开始创建,并且创建成功。下午3:06再次创建快照,并且在下午3:08创建完毕前,有35个键更新了。
a)如果3:06到3:08之间系统发生崩溃,导致快照创建失败,那么2:35之后全部数据丢失。
b)如果在3:08创建快照成功后,系统本快,则3:06后更新的35个键丢失
注意:快照是以开始创建快照时内存中数据为基础创建的
3.什么时候会创建快照
a)BGSAVE命令 ,redis会fork子进程负责将快照写入硬盘,父进程继续处理请求。
b)SAVE命令 ,会阻塞redis服务器直到快照完成。此命令不常用,在内存不足时或者阻塞redis服务也没关系时可以使用。
c) 配置save配置项时,如save 60 1000 (60秒内有1000次写入)自动触发BGSAVE
d)SHOTDOWN 命令 关闭服务器时,或者接收到标准TREM信号时(?)执行SAVE命令,阻塞所有客户端,不再执行客户端发来的命令,SAVE结束后关闭服务器
d)当一个服务器连接另一个服务器,并向对方发送SYNC命令时开始一次复制操作时,如果主服务器没有执行BGSAVE,或并非刚执行过BGSAVE就会执行BGSAVE。
4. 快照时发生系统奔溃会丢失数据如果不能接受这些丢失则应使用AOF持久化方式
当redis数据量只有几个GB时候,使用快照保存数据没有问题。redis创建子进程将数据保存在硬盘里,生成快照需要的时间比读这句话所需要时间还要短。但是如果数据量达到几十个GB,并且剩余内存不多,或redis运行在虚拟机中,那么BGSAVE可能导致系统长时间停顿,也可能引发系统大量会用虚拟内存,导致redis性能降低。
快照消耗时间要根据redis服务运行环境进行评估
AOF 只追加文件 append-only file
1.AOF持久化会将被执行的写命令写到AOF文件的末尾
配置 appendfsync
always 每个命令都写入,影响性能。收到磁盘性能限制:转盘式每秒大概处理200个写命令。固态硬盘:每秒大概几万个写命令 此命令使得redis每次写入一个命令,而不和其他选项一样一次写入多个命令,导致固态硬盘寿命从几年降低到几个月
everysec 每秒执行同步 和不适用任何持久化特性的性能相差无几 丢失最多一秒内的数据
no 系统决定AOF文件同步时间。一般不会对性能产生影响;不推荐使用,原因1系统奔溃导致不定量数据丢失。2.如果应判处李写入操作不够快,缓冲区被等待写入硬盘的数据填满时,redis写入被阻塞,导致处理请求变慢。
2.AOF 文件重写/压缩
1)为什么要重写压缩?1.防止AOF文件过大,占用磁盘空间。2.AOF文件过大,还原操作执行时间会更长。
2)BGREWRITEAOF命令
作用:移除AOF文件中的冗余命令来重写AOF文件。
工作原理:和BGSAVE类似,创建子进程,由子进程负责AOF文件重写。所以快照持久化因为创建子进程导致的性能问题和内存占用问题,在AOF中也会存在。跟糟糕的时AOF文件更可能会比快照文件大几倍,所以AOF重写并删除旧AOF文件时,删除几十G的AOF文件可能导致系统挂起(hang)数秒
配置:auo-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项自动执行BGREWRITEAOF命令
auo-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64m 并启用AOF持久化,当AOF文件体积大于64M并且文件体积比上次重写后增大至少一倍执行BGREWRITEAOF命令 通过auo-aof-rewrite-percentage 配置大于100 控制AOF更大时在进行重写压缩
配置
RDB:
save 60 1000
stop-write-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb
AOF:
appendonly on
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64m