可以配置AOF同步到磁盘的频率,如每秒同步一次、每次写操作都同步或完全依赖操作系统。
支持不同的同步策略
可重写性
AOF-数据完整性 优点缺点AOF-数据完整性
可重写性
支持不同的同步策略
# 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
执行save命令会手动触发RDB持久化,但是save命令会阻塞Redis服务,直到RDB持久化完成。当Redis服务储存大量数据时,会造成较长时间的阻塞,不建议使用。
执行bgsave
命令也会手动触发RDB持久化,和save
命令不同是:Redis服务一般不会阻塞。Redis进程会执行fork操作创建子进程,RDB持久化由子进程负责,不会阻塞Redis服务进程。
RDB文件是一个紧凑的二进制压缩文件,是Redis在某个时间点的全部数据快照。
优点 | 缺点 | |
---|---|---|
RDB | 使用RDB恢复数据的速度远远比AOF的快,非常适合备份、全量复制、灾难恢复等场景。 | 每次进行bgsave操作都要执行fork操作创建子经常,属于重量级操作,频繁执行成本过高,所以无法做到实时持久化,或者秒级持久化。 |
AOF(Append Only File)持久化是把每次写命令追加写入日志中,当需要恢复数据时重新执行AOF文件中的命令就可以了。
AOF解决了数据持久化的实时性,也是目前主流的Redis持久化方式,这里分为四个步骤。
AOF持久化流程中的文件同步有以下几个策略:
# 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
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
AOF持久化流程中的文件重写可以手动触发,也可以自动触发。
优点 | 缺点 | |
---|---|---|
AOF-数据完整性 | AOF文件记录了服务器接收到的所有写操作命令,并在服务器启动时,通过重新执行这些命令来重建数据集。 这种方式提供了比RDB更高的数据安全性,因为它几乎不会丢失任何已提交的事务。 | 相比于RDB快照,AOF文件通常会占用更多的磁盘空间,因为它记录了每个写操作的详细信息。 随着时间的推移,如果不进行适当的重写,AOF文件可能会变得非常庞大。 |
可重写性 | Redis允许在不中断服务的情况下对AOF文件进行重写,以减少文件体积和提高性能。 | 如果配置为每次写操作都同步到磁盘,那么会对Redis的性能产生显著影响。 即使是使用每秒同步一次的策略,在高并发场景下也可能导致一定的延迟。 |
支持不同的同步策略 | 可以配置AOF同步到磁盘的频率,如每秒同步一次、每次写操作都同步或完全依赖操作系统。 这提供了在性能和数据安全性之间的权衡选择。 | 在主从复制的场景中,如果主节点频繁地写入AOF文件并需要将其同步到从节点,那么网络延迟可能会成为一个问题。 |
在真实环境中,Redis确实可以同时使用AOF(Append Only File)和RDB(Redis DataBase)两种持久化方式。这种混合使用的方式可以充分利用两者的优势,以达到更好的数据安全性和性能平衡。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。