Redis持久化

1.RDB

1.1RDB简介

RDB全称Redis Database Backup file （Redis数据备份文件），也被叫做Redis数据快照。把内存中的数据都记录到磁盘中，当Redis实例故障重启后，从磁盘中读取快照文件，恢复数据。

快照文件称为RDB文件，默认保存在当前运行目录下

• save 由Redis主进程执行RDB，会阻塞所有命令（Redis 单线程）
• bgsave 开启子进程执行RDB，避免主进程受到影响

Redis停机会自动执行一次RDB （Redis正常关闭）

redis.conf 配置文件

1.2RDB底层实现原理

bgsave 开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件

linux系统中所有进程都不能直接操作物理内存，操作系统会给进程分配一块虚拟内存，进程通过页表进行物理内存和虚拟内存数据的映射，fork时直接复制一份页表通过映射关系读取物理内存数据，然后写入磁盘

fork采用的时copy-on-write技术：

• 当主进程执行读操作时，访问共享内存
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

1.3总结

1.RDB方式bgsave的基本流程

• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并写入新的RDB文件
• 用新的RDB文件替换旧的RDB文件

2.RDB在什么时候执行？ save 60 1000 代表什么含义？

在Redis正常关闭时会默认执行一次，可以通过配置文件配置执行时机。save 60 1000 表示每60s内如果由1000个key发生修改就执行一次RDB

3.RDB的缺点？

• RDB 通过自定义时间段内key的修改来判断是否进行数据持久化，但是如果设置时间过长，可能在还没持久化Redis突然宕机，造成数据丢失。如果设置时间过短，会频繁的进行持久化操作，影响性能
• fork子进程、压缩、写出RDB文件都比较耗时

2.AOF

2.1AOF简介

AOF全称Append Only File （追加文件）。Redis处理每一个写命令都会记录在AOF文件，命令日志文件

AOF是默认关闭的，需要修改redis.conf配置文件来开启AOF

AOF的命令记录频率：

always 每执行一次写命令，立即记录到AOF文件

everysec 写命令执行完先放入AOF缓冲区，每隔1秒将缓冲区数据写到AOF文件，默认方案

no 写命令执行完先放入AOF缓冲区，由os决定何时将缓冲区内容写入磁盘

AOF由于是记录命令，因此文件会比RDB大。对于同一个key的多次修改，其实只有最后一次是有意义的，但是AOF全部记录一个个执行，浪费资源

2.2AOF的重写

通过bgrewriteaof命令执行AOF文件的重写

auto-aof-rewrite-percentage 100 AOF文件比上次文件 增长超过多少百分比则触发重写

auto-aof-rewrite-min-size 64mb AOF文件体积最小多大以上才触发重写

AOF的重写原理：

通过对Redis的指令进行压缩，(比如同一个key修改了上千次，只需要记录最后一次。相同数据类型的key的修改可以压缩成一条批处理指令)

AOF的重写过程：

1.根据当前Redis内存里面的数据重新构建一个新的AOF文件

2.读取当前Redis里面的数据，写入新的AOF文件里面

3.重写完成后新文件覆盖旧文件

AOF重写时需要读取Redis中所有键值对数据生成新的指令，此过程耗时较多，可能对业务有影响，Redis如何解决的？

Redis把重写的过程放在后台的一个子进程去完成，子进程在重写时主进程仍然可以处理客户端的请求。

子进程在重写的过程中，主进程对数据进行了修改，导致Redis内存中的数据和AOF文件不一致，如果保证数据的一致性？

Redis针对此问题进行了优化，子进程在重写过程中，主进程的数据变更会追加到AOF的重写缓冲区里面，等到AOF文件重写完成之后再把AOF缓冲区里面的数据追加到新的AOF文件里面

总结：

如果两者文件都有，redis会优先选择AOF持久化方式，AOF方式的数据完整性更好

RDB更多做备份