关于Redis持久化的解释

Redis持久化——RDB

在指定的时间间隔内将内存中的数据集快照（Snapshot快照）写入磁盘，恢复时将快照文件直接读到内存。
如何执行备份
Redis会独立创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束后用临时文件替换上次持久化好的文件。主进程不进行任何IO操作，确保极高的性能如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加高效，RDB缺点是最后一次持久化后的数据可能丢失。（最后一次持久化可能不满足RDB保存策略，导致没有持久化）

优点：

• 节省磁盘空间与AOF相比（RDB存储的是数据，AOF存储的是指令）
• 恢复速度快

缺点：

• 虽然Redis在fork时使用写时拷贝技术（正在需要持久化的时候才占用父进程的内存），但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所有如果Redis意外关闭的话，会丢失最后一次快照后的所有修改

RDB的配置
在redis.conf中配置文件名称，默认为dump.rdb

rdb持久化文件保存的位置

可以更改为myredis目录下

rdb保存策略

save <seconds> <changes> :多少内执行多少次改变操作

正常关闭也会进行持久化

手动保存快照

save vs bgsave 只管保存，其他不管，全部阻塞

当Redis无法写入磁盘的话，直接关掉Redis的写操作

进行rdb保存时，将文件压缩

Redis持久化——AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下（读指令不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF文件故障备份

• AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统既加载
• AOF和RDB同时开启，系统默认取AOF的数据

AOF文件故障恢复

• AOF文件的保存路径，同RDB的路径一致。
• 如遇到AOF文件损坏，可通过输入命令进行修复（不是所有的损坏都可以修复）

redis-check-aof --fix appendonly.aof 进行修复

Rewrite
AOF采用文件追加方式，新增重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据集的最小指令集。可以使用命令bgrewriteaof。
例如：

set a a;
set a b;
set a 123;
只保留set a 123

实现：AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是先写临时文件，再替换原文件），遍历新进程内存中的数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。（看Redis中记录什么数据，然后这些数据能用什么指令存储）

AOF的配置
AOF默认不开启

AOF的存储路径与RDB相同，共用路径，文件名不同

AOF同步效率设置

• always：始终同步，每次redis的写入都会立刻记入日志
• everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
• no：不主动进行同步，把同步时机交给操作系统