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更多做备份