Redis持久化——如何选择合适的持久化方式
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文件的恢复比较慢。
我们可以用一张表格来更清晰的对比一下两种持久化方式的优缺点
| 持久化方式 | 对Redis性能的影响 | 文件大小 | 故障恢复速度 | 数据丢失 |
|---|---|---|---|---|
RDB |
小 | 小 | 快 | 多 |
AOF |
大 | 大 | 慢 | 少 |
3 混合持久化
鱼我所欲也，熊掌亦我所欲也！如果我们既想要一个好的性能，又要尽量避免数据的丢失应该怎么办? 在Redis 4.0之后提供了混合持久化的方式，顾名思义就是把RDB持久化和AOF持久化结合起来的一种方式。混合持久化就是快照以一定的频率执行，而在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。
如图所示，在第一次执行快照之后，将后续命令写入AOF文件，直到第二次执行快照。而在第二次执行快照的时候会清除AOF文件的内容，循环往复。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作，也就不会出现文件过大的情况，同时可以避免AOF重写的开销。但世界上并没有完全两全其美的事情，即使鱼和熊掌兼得，一起吃的时候也容易串了味儿。RDB混合持久化固然兼顾了性能与数据完整性，但也有其缺点。
- 兼顾了性能与数据的同时也牺牲了部分性能
AOF文件中添加了RDB格式的内容，使可读性变差，并且由于混合了RDB的内容，与RDB文件相同具有兼容性的问题
那么，在真正使用的过程中，我们到底应该如何选择合适的持久化方式呢？
4 如何选择合适的持久化方式
技术决策不同于“今天中午吃什么”，可以拍脑袋或者抛硬币来决定。我们应该综合考虑很多因素，其中最重要的一点就是“平衡、取舍”的问题，因为没有最好的技术方案，只有适合的方案，在你想要得到一些东西的时候，必然要失去一些东西。下面几点可以在我们选择的时候提供一些帮助。
- 如果你的业务场景需要很高的性能，或者宕机之后能够尽快的恢复，而对数据完整性的要求不是那么高，那么可以采用
RDB持久化的方式。 - 如果你的业务场景对数据完整性的要求很高，那么可以采用
AOF的持久化方式，而至于采用那种回写策略，则取决于你对数据完整性的要求程度。 - 如果你的业务场景既要兼顾性能，又注重数据完整性，那么可以采用混合持久化的方式。
- 如果你对数据丢失无所谓，追求性能最大化的情况下，甚至可以禁用持久化。
