RDB与AOF

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