1. Redis持久化策略

Redis的两种主要持久化方式

RDB (Redis Database Snapshot)

定义：RDB是一种定期将Redis内存中的数据生成快照（snapshot）并写入磁盘的过程。

触发方式：

手动触发：通过执行SAVE或BGSAVE命令。

自动触发：根据配置文件中设置的save规则（如save m n，表示m秒内数据发生n次修改时自动触发）。

优点：

生成的RDB文件是经过压缩的二进制文件，体积小，便于备份和迁移。

恢复速度快，加载RDB文件直接重建数据集。

缺点：

数据安全性相对较低，因为RDB文件是在某一时刻生成的，期间发生的更新可能丢失（取决于save规则间隔）。

RDB生成过程需要进行fork操作创建子进程，占用一定的系统资源，尤其是数据集较大时。

AOF (Append-only File)

定义：AOF持久化是将Redis执行的每一次写操作（即修改数据集的命令）以文本形式追加到AOF文件中。

工作模式：

always：每条写命令都同步写入硬盘。

everysec（默认）：每秒将缓冲区内容写入硬盘，并且在后台异步刷盘。

no：由操作系统决定何时同步，风险较高，容易丢失数据。

优点：

数据安全性高，通过AOF文件可以精确还原写操作序列，丢失数据少。

可以通过redis-check-aof工具修复部分损坏的AOF文件。

缺点：

AOF文件大小通常大于RDB文件，且随写操作增多而增长。

重启恢复时，需要重新执行AOF文件中的所有命令，恢复速度相比RDB慢。

过度的写操作可能导致AOF文件过大，需要定期进行bgrewriteaof命令进行重写优化，将多条连续的写操作合并为更少的命令。

混合持久化

Redis 4.0及以后版本支持混合持久化，即在执行BGSAVE时，既生成RDB文件，又将自上次RDB保存以来的增量AOF日志写入到RDB文件末尾。

这样做的好处是：

利用RDB的快速加载特性快速恢复大部分数据。

再通过加载增量AOF日志补全RDB之后的部分数据，确保数据完整性。

一定程度上结合了RDB和AOF的优点，兼顾数据安全性和恢复速度。

持久化实现细节

RDB实现细节：

使用fork创建子进程，子进程负责将内存数据写入临时RDB文件，完成后替换旧的RDB文件，避免数据一致性问题。

子进程只做I/O操作，不处理客户端请求，避免阻塞主线程。

RDB文件格式包括元数据（如数据库数量、键值对数量等）、键值对数据（序列化后的数据）等。

AOF实现细节：

Redis使用一个缓冲区来累积写命令，根据配置的同步策略（always、everysec、no）决定何时将缓冲区内容刷到硬盘。

AOF文件由一系列Redis命令组成，格式清晰，易于理解和解析。

AOF重写过程：

创建一个子进程，读取当前数据库状态，生成一个新的最小化命令流。

在重写期间，新写入的命令会被追加到一个临时AOF文件，并同时记录到一个重写缓冲区。

重写完成后，用新的AOF文件替换旧文件，同时将重写缓冲区中的命令追加到新文件中，确保不丢失重写期间的写操作。

结论与优化建议

结合业务需求选择合适的持久化策略：如果对数据丢失容忍度低，优先考虑AOF；如果追求快速恢复且有足够的备份机制，可选择RDB。

考虑定期备份：无论是RDB还是AOF，都应配合定期备份策略，进一步增强数据保护。

调整持久化配置：如AOF的同步策略、RDB的save规则等，以平衡数据安全性与Redis性能。

 如果大家需要视频版本的讲解，欢迎关注我的B站：