Redis持久化——如何选择合适的持久化方式

标签：load   文件   主线程   子进程   命令操作   最大化   宕机   持久   最大   

 1 RDB持久化

RDB持久化就是每隔一段时间把内存中的数据全量记录下来。RDB持久化并不能频繁的进行，因为RDB文件生成的过程虽然是由fork出来的子进程完成的，但是fork本身是有性能的开销的。

RDB的优点:

• 体积更小：相同的数据量RDB文件数据比AOF的小，因为RDB是紧凑型文件
• 恢复更快：因为RDB是数据的快照，基本上就是数据的复制，不用重新读取再写入内存。
• 性能更高:   父进程在保存RDB时候只需要fork一个子进程来干活，无需父进程，保证了Redis正常处理读写命令的性能。

RDB的缺点：

• 故障丢失：因为RDB是全量的，又不能频繁的执行RDB文件，因此越大的时间间隔数据丢失的也就越多
• 耐久性差：相对AOF的异步策略来说，因为RDB的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致CPU吃紧，耐久性相对较差。
• 兼容性差：由于Redis更新换代的过程中RDB文件的格式一直在变化，老的版本Redis 可能无法恢复新版本的RDB文件。

2 AOF持久化

AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。即Redis每执行一个命令的同时都会写入AOF缓冲区一份，并且可以通过设置回写策略来同步到磁盘文件，当文件过大时，会fork出一个子进程进行AOF重写操作。

AOF的优点：

• 数据保证：我们可以根据需要设置合适的回写策略，来保障数据尽可能少的丢失
• 易于解析：相对于RDB文件，AOF文件更易于理解和解析，且没有兼容性问题。

AOF的缺点:

• 性能相对较差：它的操作模式决定了它会对redis的性能有所损耗
• 体积相对更大：尽管是将aof文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。
• 恢复速度较慢：由于恢复的时候要逐条解析命令并写入，相对于RDB文件的恢复比较慢。

我们可以用一张表格来更清晰的对比一下两种持久化方式的优缺点

3 混合持久化

鱼我所欲也，熊掌亦我所欲也！如果我们既想要一个好的性能，又要尽量避免数据的丢失应该怎么办? 在Redis 4.0之后提供了混合持久化的方式，顾名思义就是把RDB持久化和AOF持久化结合起来的一种方式。混合持久化就是快照以一定的频率执行，而在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

如图所示，在第一次执行快照之后，将后续命令写入AOF文件，直到第二次执行快照。而在第二次执行快照的时候会清除AOF文件的内容，循环往复。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作，也就不会出现文件过大的情况，同时可以避免AOF重写的开销。但世界上并没有完全两全其美的事情，即使鱼和熊掌兼得，一起吃的时候也容易串了味儿。RDB混合持久化固然兼顾了性能与数据完整性，但也有其缺点。

• 兼顾了性能与数据的同时也牺牲了部分性能
• AOF 文件中添加了RDB 格式的内容，使可读性变差，并且由于混合了RDB的内容，与RDB文件相同具有兼容性的问题

那么，在真正使用的过程中，我们到底应该如何选择合适的持久化方式呢？

4 如何选择合适的持久化方式

技术决策不同于“今天中午吃什么”，可以拍脑袋或者抛硬币来决定。我们应该综合考虑很多因素，其中最重要的一点就是“平衡、取舍”的问题，因为没有最好的技术方案，只有适合的方案，在你想要得到一些东西的时候，必然要失去一些东西。下面几点可以在我们选择的时候提供一些帮助。

• 如果你的业务场景需要很高的性能，或者宕机之后能够尽快的恢复，而对数据完整性的要求不是那么高，那么可以采用RDB持久化的方式。
• 如果你的业务场景对数据完整性的要求很高，那么可以采用AOF的持久化方式，而至于采用那种回写策略，则取决于你对数据完整性的要求程度。
• 如果你的业务场景既要兼顾性能，又注重数据完整性，那么可以采用混合持久化的方式。
• 如果你对数据丢失无所谓，追求性能最大化的情况下，甚至可以禁用持久化。

Redis持久化——如何选择合适的持久化方式

标签：load   文件   主线程   子进程   命令操作   最大化   宕机   持久   最大   

原文地址：https://www.cnblogs.com/veblen/p/14703481.html