redis（三）redis的持久化机制

redis的持久化机制（默认RDB）

Redis是内存数据库，数据全部在内存里，如果在未做持久化措施的情况下突然宕机，数据就会全部丢失。
如果把Redis当做Memcached来看待，那么也可以不用做持久化。
然而我们有时候希望Redis不仅仅作为缓存来使用，也希望Redis重启后不必做预热，那么就需要用到Redis 的持久化机制。

三种持久化的模式

1.AOF：

以追加的方式记录Redis的写操作，并在Redis重启时进行重放（与MySQL的binlog日志的原理是一样的）。
当AOF日志过大时，redis支持日志重写。

【这里提供一个小知识点，在Redis中是先执行命令再记录日志到AOF，这也是Redis事务不支持回滚的原因：即使发生异常，没有可以用来执行回滚操作的日志。而传统的数据库例如MySQL都是先做日志然后再做操作，所以能够支持回滚】

AOF的原理：

操作系统将写操作首先记录到内存缓冲区中，然后使用fsync函数将数据刷新到磁盘中。

AOF优点：

如果不考虑性能，AOF可以最大限度保证数据完整性，可以设置每发生一次写操作就调用一次fsync函数；更加灵活，可以使用不同的fsync策略，完全不使用fsync，每秒使用fsync（默认），以及每次查询时使用fsync；
fsync函数同步内存中所有已修改的文件数据到储存设备。

缺点：

与下面的RDB方式相比，相同数据集大小AOF占用空间更大；若调用fsync的频率过快，性能会变差；

AOF文件损坏？

AOF文件中可能有一条命令是不完整的，比如发生正在写入的时候断电的这种情况，redis支持重放这样的AOF文件，他会在启动日志中记录错误命令的行数，并在重放时对该行进行忽略。

2.RDB：

也称快照方式，配置每隔一段时间执行一次全量备份，Redis将数据集快照保存在磁盘上，保存在一个名为dump.rdb的二进制文件中，也可以手动调用SAVE或BGSAVE命令。

RDB的原理：

主进程调用fork函数生成一个子进程，子进程进行磁盘I/O操作，操作完成后替换旧的RDB文件。

fork函数将运行着的程序分成2个（几乎）完全一样的进程，每个进程都启动一个从代码的同一位置开始执行的线程。这两个进程中的线程继续执行，就像是两个用户同时启动了该应用程序的两个副本。

RDB优点：

非常适合做备份与回滚到指定的时间点，例如我们可以每天晚上2点执行定时计划全量备份一次Redis中的数据，以后我们进行恢复的时候可以将Redis恢复到指定的时间点的版本；
与AOF相比使用RDB方式性能较高；与AOF相比Redis重启的速度较快；当AOF文件变的过大时可以自动进行重写（2.4版本以上，2.4以下版本需要手动调用）

RDB的缺点：

相比AOF丢失的数据可能会更多，比如设置5分钟备份一次快照，那么最多会损失5分钟的数据。

3.混合方式：

RDB与AOF混合使用。
将 RDB文件的内容和增量的 AOF 日志文件存在一起。
这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志。

Redis官方建议使用混合方式进行Redis的持久化。
并且我们需要确保避免在RDB快照操作已经在进行时触发AOF重写，或者在AOF重写过程中允许BGSAVE，防止两个Redis后台进程同时执行磁盘I/O。

该篇文章是在简书上看到的，时间有些久了，具体链接忘记了。抱歉