深刻理解Redis集群（上）：RDB快照和AOF日志

RDB快照

save同步阻塞

客户端

服务端

.conf配置文件

# The filename where to dump the DB
dbfilename dump.rdb# rdb-del-sync-files是Redis配置文件中的一个选项，它的作用是在主节点上执行BGSAVE或AOF持久化操作时，删除同步锁文件，以释放磁盘空间。当这个选项设置为yes时，Redis会自动删除同步锁文件；当这个选项设置为no时，Redis不会自动删除同步锁文件。
rdb-del-sync-files no# rdb文件保存路径
dir /Users/momoubin/install/redis

.rdb快照文件

分析

执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成。当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。

bgsave

client

server

分析

执行bgsave命令也会手动触发RDB持久化，和save命令不同是：Redis服务一般不会阻塞。Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程。

RDB优缺点

RDB文件是一个紧凑的二进制压缩文件，是Redis在某个时间点的全部数据快照。

	优点	缺点
RDB	使用RDB恢复数据的速度远远比AOF的快，非常适合备份、全量复制、灾难恢复等场景。	每次进行bgsave操作都要执行fork操作创建子经常，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化。

AOF日志

AOF（Append Only File）持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。

AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式，这里分为四个步骤。

四个步骤

命令追加（append）：所有写命令都会被追加到AOF缓存区（aof_buf）中。
文件同步（sync）：根据不同策略将AOF缓存区同步到AOF文件中。
文件重写（rewrite）：定期对AOF文件进行重写，以达到压缩的目的。
数据加载（load）：当需要恢复数据时，重新执行AOF文件中的命令。

文件同步策略

AOF持久化流程中的文件同步有以下几个策略：

always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

配置文件

conf配置文件

# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb

手动触发

client

Background append only file rewriting started
127.0.0.1:6379> Set 1 1
OK
127.0.0.1:6379> set name bryant
OK
127.0.0.1:6379> hset name-list bryant mo
(integer) 1

server

AOF文件

AOF备份的优缺点

AOF持久化流程中的文件重写可以手动触发，也可以自动触发。

	优点	缺点
AOF-数据完整性	AOF文件记录了服务器接收到的所有写操作命令，并在服务器启动时，通过重新执行这些命令来重建数据集。这种方式提供了比RDB更高的数据安全性，因为它几乎不会丢失任何已提交的事务。	相比于RDB快照，AOF文件通常会占用更多的磁盘空间，因为它记录了每个写操作的详细信息。随着时间的推移，如果不进行适当的重写，AOF文件可能会变得非常庞大。
可重写性	Redis允许在不中断服务的情况下对AOF文件进行重写，以减少文件体积和提高性能。	如果配置为每次写操作都同步到磁盘，那么会对Redis的性能产生显著影响。即使是使用每秒同步一次的策略，在高并发场景下也可能导致一定的延迟。
支持不同的同步策略	可以配置AOF同步到磁盘的频率，如每秒同步一次、每次写操作都同步或完全依赖操作系统。这提供了在性能和数据安全性之间的权衡选择。	在主从复制的场景中，如果主节点频繁地写入AOF文件并需要将其同步到从节点，那么网络延迟可能会成为一个问题。

手动触发：使用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置确定自动触发的时机。
- auto-aof-rewrite-min-size：表示运行AOF重写时文件大小的最小值，默认为64MB；
- auto-aof-rewrite-percentage：表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只有前两者同时超过时才会自动触发文件重写。

总结

在真实环境中，Redis确实可以同时使用AOF（Append Only File）和RDB（Redis DataBase）两种持久化方式。这种混合使用的方式可以充分利用两者的优势，以达到更好的数据安全性和性能平衡。

AOF与RDB混用的优势

数据安全性增强：
1. AOF提供了持久化的日志记录，能够保证数据的完整性，即使在系统崩溃的情况下也能最大程度地恢复数据。
2. RDB则提供了定期的快照备份，可以在短时间内快速恢复大量数据。
性能优化：
1. RDB的快照机制可以在后台异步执行，对Redis的性能影响较小。
2. AOF的日志追加操作相对较轻量，但在高并发写入场景下可能会产生较大的磁盘I/O压力。通过RDB快照，可以减少AOF文件的大小，从而降低后续的日志重写和恢复成本。
灵活性提升：
1. 结合使用AOF和RDB可以根据实际需求调整持久化策略，如在业务低峰期执行RDB快照，在高峰期依赖AOF日志保证数据实时性。

实施步骤与注意事项

配置启用AOF和RDB：
1. 在Redis配置文件中同时开启save指令（用于触发RDB快照）和appendonly yes指令（启用AOF持久化）。
设置合理的同步策略：
1. 调整appendfsync参数以控制AOF日志同步到磁盘的频率，默认走everysec（每秒同步一次）。
监控与维护：
1. 定期检查AOF文件和RDB快照的健康状况，确保它们没有损坏且能够正常恢复。
2. 使用Redis提供的工具如redis-check-aof和redis-check-rdb来验证文件的完整性。
故障恢复流程：
1. 在发生故障时，首先尝试加载最新的RDB快照以快速恢复大部分数据。
2. 随后应用AOF日志中的增量更新，以达到数据的最终一致性。