金三银四跳槽redis复习篇（二）：redis持久化机制AOF与RDB

大家好，我是小义，今天来讲一讲redis的持久化机制。当我们在数字世界里寻找可靠性的保障，Redis的数据持久化便是守护的盾牌。Redis，这一高性能的内存键值存储数据库，以其独特的AOF和RDB持久化方案保证了即使在面临断电、系统崩溃等极端情况下数据也不会消失无踪，并且可以快速恢复。

一、Redis的双重保险：AOF与RDB

在Redis的世界里，AOF（Append Only File）和RDB（Redis DataBase）是两种互补的持久化手策。AOF负责记录每一条指令的修改，就如同一名勤勉的记录员，缜密地将每一个变动都记入册页。而RDB则靠生成数据的快照来备份，它将内存中的数据定期冻结并快速保存，就像是给数据库拍下一张张瞬间快照。

二、AOF日志：一笔一划，确保数据不漏

想象一下，你正在写一篇报告，每写几个字就会自动保存一次，这就是AOF的工作原理。AOF日志通过记录redis的每个写命令，确保即便在系统出现问题后，也可以重新执行这些命令来恢复数据。

为了避免额外的检查开销，Redis 是在命令执行后才向 AOF 里面记录日志的，也就是写后日志，这样也不会阻塞当前的写操作。

在AOF持久化中，针对避免主线程阻塞和减少数据丢失问题，刷盘写入策略的配置就至关重要。用户可以选择always（每个写命令都同步到磁盘），everysec（每秒同步一次到磁盘）或者no（由操作系统决定何时同步到磁盘）。通常，everysec提供了数据安全与性能之间较好的平衡，因此是多数生产环境的首选。

AOF的优势在于可以彻底地重现数据变化的过程，而它的挑战则是随着时间增长，日志文件可能会逐渐庞大。因此，Redis会定期对AOF文件进行重写，旧日志文件中的多条命令，在重写后的新日志可能会变成了一条命令，比如对某个key的反复修改，这样就优化了存储结构，节省了空间。

三、RDB快照：速写数据的瞬间，实现快速恢复

与AOF的持续记录不同，RDB通过在特定时刻创建数据的完整副本来保护数据。在灾难性故障发生时，RDB允许你迅速重载快照，恢复到最后一次保存的状态。AOF因为需要重新执行所有命令来恢复数据，其速度会受到命令数量的影响。而RDB作为一个完整的数据集快照，可以直接被Redis读取加载，所以恢复速度快。

快照的时候因为是fork子线程来执行的，尽管不会阻塞主线程，但是在这期间主线程如果要修改数据，redis会借助操作系统提供的写时复制技术（Copy-On-Write, COW）生成要修改数据的副本，然后主线程在这个数据副本上进行修改。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

那么快照应该多久执行一次呢？1秒1次可以吗？显然不行，这样会频繁将全量数据写入磁盘，多个快照竞争有限的磁盘带宽，会给磁盘带来很大压力而且主线程频繁fork子线程也会造成阻塞。但是执行频率太低又不能保证数据的完整性。这也是它的不足之处。

四、混合持久化：平衡艺术

尽管快照频率可能成为数据完整性的弱点，但是将快照与AOF结合使用，就能大幅降低数据丢失的风险。Redis 4.0之后更是引入了混合持久化策略，兼具了AOF的细粒度记录和RDB的快速恢复。关于 AOF 和 RDB 的选择问题，可以考虑以下几点：

• 1.数据不能丢失时，AOF和RDB混用。
• 2.允许分钟级别的数据丢失，可以只使用RDB。
• 3.如果只用AOF，优先使用everysec的配置选项。

结语：数据的守护者

Redis的AOF与RDB，是数字世界中数据安全性与效率平衡的体现。掌握Redis的持久化一如掌握艺术，配置文件便是画家的调色板。正确地设置appendfsync参数能平衡AOF的持久性与性能；合理的快照频率又是利用RDB时不可或缺的考量因素。因此我们需要深入了解redis每个配置选项对性能的影响，确保系统既健壮又高效。