RDB
RDB启动方式
save指令
手动执行一次保存操作
save
redis是单线程执行任务的
不同客户端发送来四个指令 set set save get
save指令的执行会阻塞当前Redis服务器,直到RDB过程完成为止,
有可能长时间阻塞,所以线上环境不建议使用
bgsave
数据量过大的时候,单线程执行方式造成效率过低。如何处理?
后台执行(不是立即执行)
bgsave
执行过程:
直接生成一个子进程来完成这部分操作
bgsave命令是针对save阻塞问题做的优化,Redis内部所有涉及RDB操作都采用bgsave方式
自动执行
配置:save second changes
满足限定时间范围内key的变化数达到changes数量的时候进行持久化
后台还是使用的bgsave
AOF
RDB的弊端:
存储数据量大的时候效率较低(基于快照的思想,数据量大的时候效率低)
大数据量下的IO性能较低
基于fork创建子进程,内存产生额外消耗
宕机带来数据丢失的风险(因为不是实时的)
解决思路:
对所有的操作过程进行记录
AOF的主要作用是解决了数据持久化的实时性
AOF
将命令写入到aof文件中
什么时候写入?
always(每次)
每次写入操作都写入,性能较低,不建议使用
eversec(每秒)
每秒将缓冲区中的数据同步到AOF中,准确度较高,性能高,建议使用
系统宕机时丢失1s数据
no(系统控制)
操作系统控制,整体不可控
AOF功能开启
配置文件中:
appendonly yes:是否开启AOF,默认不开启
appendfsnc always|everysec|no :AOF写数据策略
重写
重写规则:
进程内已经超时的数据不再写了
对同一条数据的多个写命令合并成一条命令
手动重写指令
bgrewriteaof
自动重写
AOF与RDB区别
RDB与AOF的选择
对数据非常敏感,建议使用默认的AOF持久化方案
持久化策略使用everysecond,保持很好的性能,出现问题的时候,丢失0-1s的数据
如果接受数分钟的数据丢失并且要大数据的快速恢复,用RDB