阅读量: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站：
