redis持久化

1.快照-将内存数据的二进制序列化

• 写时复制COW(Copy On Write)
  原理：当需要修改某个元素时，不直接修改，而是先复制一份副本，在副本上进行修改后，把原来的引用指向副本上。

• 自动触发快照配置

配置	说明
save 900 1	900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10	300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000	60 秒内如果至少有 10000 个 key 的值变化，则保存
save “”	停用快照

• 手动触发快照命令

命令	说明	缺点
save	阻塞当前redis服务，直到rdb过程完成为止。	对内存比较大的实例会造成长时间阻塞
bgsave	(redis机制默认使用该方式)redis在后台异步执行快照，不会阻塞redis，具体操作是通过fork操作子进程负责	-

• 快照优劣势

优点	缺点
文件紧凑，适合备份和恢复	无法做到实时持久化，会丢失期间数据
fork一个子进程处理保存工作，不阻塞redis	bgsave在内存中每次会克隆一份数据，影响性能

2.AOF(append only file)-只追加不允许改写文件

• 原理:将执行的写指令记录写入到appendolny.aof文件中，重启时将aof日志文件中的指令重放。

• 配置:redis.conf

  #开启aof
  appendonly yes(默认no)
  
  #aof生成文件名及路径
  appendfilename "appendonly.aof"

• 写入周期appendfsync

策略	说明
always	每次写指令就写入文件
everysec	每秒钟写入文件(默认)
no	不写入文件，让操作系统来决定何时写入

重写

• 解决的问题:防止不断追加写入到一个aof文件，数据恢复时执行慢
  新的aof文件一条记录的操作只会有一次，不会记录对同一个值多次操作。

• 重写原理:fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件

• AOF优劣势

优点	缺点
通过不同策略保证数据安全	重放AOF比快照慢

3.混合持久化

通过快照+aof日志组合方式解决，rdb(不能实时持久化导致丢失数据)和aof(重放速度慢)的缺点，重启时先加载rdb的内容，然后再重放增量aof日志替代之前aof全量文件重放

赏

谢谢你的激励

微信