深刻理解Redis集群(上):RDB快照和AOF日志
- 在主从复制的场景中,如果主节点频繁地写入AOF文件并需要将其同步到从节点,那么网络延迟可能会成为一个问题。
可以配置AOF同步到磁盘的频率,如每秒同步一次、每次写操作都同步或完全依赖操作系统。
- 这提供了在性能和数据安全性之间的权衡选择。优点
- 如果配置为每次写操作都同步到磁盘,那么会对Redis的性能产生显著影响。
- 即使是使用每秒同步一次的策略,在高并发场景下也可能导致一定的延迟。
支持不同的同步策略
可重写性
AOF-数据完整性 优点缺点AOF-数据完整性
- AOF文件记录了服务器接收到的所有写操作命令,并在服务器启动时,通过重新执行这些命令来重建数据集。
- 这种方式提供了比RDB更高的数据安全性,因为它几乎不会丢失任何已提交的事务。
- 相比于RDB快照,AOF文件通常会占用更多的磁盘空间,因为它记录了每个写操作的详细信息。
- 随着时间的推移,如果不进行适当的重写,AOF文件可能会变得非常庞大。
可重写性
- Redis允许在不中断服务的情况下对AOF文件进行重写,以减少文件体积和提高性能。
- 如果配置为每次写操作都同步到磁盘,那么会对Redis的性能产生显著影响。
- 即使是使用每秒同步一次的策略,在高并发场景下也可能导致一定的延迟。
支持不同的同步策略
- 可以配置AOF同步到磁盘的频率,如每秒同步一次、每次写操作都同步或完全依赖操作系统。
- 这提供了在性能和数据安全性之间的权衡选择。
- 在主从复制的场景中,如果主节点频繁地写入AOF文件并需要将其同步到从节点,那么网络延迟可能会成为一个问题。
RDB快照
save同步阻塞
- 客户端
- 服务端
- .conf配置文件
# The filename where to dump the DBdbfilename 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混用的优势
- 数据安全性增强:
- AOF提供了持久化的日志记录,能够保证数据的完整性,即使在系统崩溃的情况下也能最大程度地恢复数据。
- RDB则提供了定期的快照备份,可以在短时间内快速恢复大量数据。
- 性能优化:
- RDB的快照机制可以在后台异步执行,对Redis的性能影响较小。
- AOF的日志追加操作相对较轻量,但在高并发写入场景下可能会产生较大的磁盘I/O压力。通过RDB快照,可以减少AOF文件的大小,从而降低后续的日志重写和恢复成本。
- 灵活性提升:
- 结合使用AOF和RDB可以根据实际需求调整持久化策略,如在业务低峰期执行RDB快照,在高峰期依赖AOF日志保证数据实时性。
实施步骤与注意事项
- 配置启用AOF和RDB:
- 在Redis配置文件中同时开启save指令(用于触发RDB快照)和appendonly yes指令(启用AOF持久化)。
- 设置合理的同步策略:
- 调整appendfsync参数以控制AOF日志同步到磁盘的频率,默认走everysec(每秒同步一次)。
- 监控与维护:
- 定期检查AOF文件和RDB快照的健康状况,确保它们没有损坏且能够正常恢复。
- 使用Redis提供的工具如redis-check-aof和redis-check-rdb来验证文件的完整性。
- 故障恢复流程:
- 在发生故障时,首先尝试加载最新的RDB快照以快速恢复大部分数据。
- 随后应用AOF日志中的增量更新,以达到数据的最终一致性。
其他文章
Kafka消息堆积问题排查
基于SpringMVC的API灰度方案
理解到位:灾备和只读数据库
SQL治理经验谈:索引覆盖
Mybatis链路分析:JDK动态代理和责任链模式的应用
大模型安装部署、测试、接入SpringCloud应用体系
Mybatis插件-租户ID的注入&拦截应用
发布者:admin,转转请注明出处:http://www.yc00.com/web/1755061857a5234490.html
评论列表(0条)