Redis的持久化

Redis的持久化

Redis的持久化有两种方式：Rdb和Aof

Rdb（Redis的默认持久化策略）

主进程fork（复制）出一个子进程来进行持久化，子进程会把内存中的数据复制一份写进一个临时文件中，当持久化完成的时候，会用临时文件来替换掉原来的dump,rdb（rdb文件的文件名可以通过conf文件中的dbfilename指定，原来dump的存放位置可以通过Redis的conf文件中的dir去查看，或通过config get dir 命令来查看）文件，此时持久化完成。
在fork过程中，主进程不进行任何I/O操作，这保证了极高的性能。

优缺点

优点：

• 适合大规模数据的恢复。
• 对数据完整性和一致性要求不高。
  缺点：
• 最后一次持久化的数据可能丢失（当你进行持久化时Redis挂了，就会丢失）。
• fork子进程，会复制主进程中的所有数据，如果主进程中数据非常大时，会造成极大的压力。

持久化策略

save 900 1 900秒内Key改变1次，就会自动触发BGSAVE命令创建快照
save 300 100 300秒内Key改变100次，就会自动触发BGSAVE命令创建快照
save 60 10000 60秒内Key改变10000次，就会自动触发BGSAVE命令创建快照

创建快照的办法

• BGSAVE命令：客户端向Redis发送BGSAVE命令，主进程会fork出一个子进程进行持久化。
• SAVE命令：客户端向Redis发送SAVE命令创建一个快照，接到SAVE命令后Redis服务器在快照创建完毕前不会响应其他指令，SAVE命令不常用，通常只在没有足够内存或等待持久化操作完毕也无所谓的情况下才会使用。
• SHUTDOWN命令：当Redis服务器接收到SHUTDOWN命令关闭时，会进行SAVE，并在SAVE执行完毕后关闭服务器。
• 一个Redis服服务务器器连连接接到到另另一一个个Redis服务器：当一个Redis服务器连接到另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令

Aof（Redis默认关闭）

以日志的形式来记录每个写操作，将Redis执行过的写指令全都记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动时会读取该文件重新构建数据，Redis重启的话就是根据日志文件的内容将写指令从前往后执行一次来完成数据的恢复工作。（Aof保存的appendonly.aof文件）

持久化策略

Appendfsync：

• always：同步持久化，每次发生数据改变立即记录到磁盘，性能差完整性好。
• everysec：出厂默认推荐，一步操作，每秒记录，如果宕机只会丢失疫苗数据
• no：从不记录

Aof的文件修复命令

redis-check-aof --fix

rewite重写

Aof采用文件追加方式，文件会越来越大为了避免这种情况，新增重写机制，当Aof文件的大小超过所设定的阈值，Redis会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可使用命令bgwriteaof

原理

aof文件过大时，会fork出一条新进程将文件重写（先写入临时文件），遍历新进程中的内存数据，每条记录有一条对应的set语句。并没有读取原来aof文件中的数据，而是将内存中的数据库内容用命令重写了一遍。

触发机制

auto-aof-rewite-percentage 100
auto-aof-rewite-min-size 64mb
默认配置是当aof文件大小是上次rewite后大小的一倍且文件大于64Mb是触发。

优点

• 每秒同步：appendfsync always 同步持久，数据完整性高性能较差。
• 每修改同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失。

劣势

• 相同数据集数据而言aof文件要远大于rdb文件，恢复速度慢与rdb。
• aof运行效率慢于rdb，每秒同步策略效率较高。