Redis AOF和RDB

本文深入探讨了Redis的两种持久化方式:RDB和AOF。RDB通过快照保存数据,适合快速恢复,但可能丢失最新数据。AOF则记录每次写操作,确保数据完整,但文件较大,恢复较慢。文章还分析了各自的优缺点及应用场景。

Redis AOF和RDB

    Redis是内存型数据库,为了保证数据在断电后不会丢失,需要将内存中的数据持久化到硬盘上。

RDB持久化

将某个时间点的所有数据都存放到硬盘上

可以将快照复制到其他服务器从而创建具有相同数据的服务器副本

如果系统发生故障,将会丢失最后一次创建快照之后的数据

如果数据量很大,保存快照的时间会很长

AOF持久化

将写命令添加到AOF文件(Append Only File)的末尾

使用AOF持久化需要设置同步选项,从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行吸入并不会马上将内容同步到磁盘上,而是先存储到缓冲区,然后操作系统决定什么时候同步到磁盘。有以下同步选项:

选项

同步频率

always

每个写命令都同步

everysec

每秒同步一次

no

让操作系统来决定何时同步

always选项会严重减低服务器的性能

everysec选项比较合适,可以保证系统崩溃时只丢失一秒左右的数据,并且Redis每秒执行一次同步对服务器几乎没有任何影响;

no选项并不能给服务器带来多大的提升,而且也会增加系统崩溃时数据丢失的数量。

随着服务器写请求的增多,AOF文件会越来越大。Redis提供了一种将AOF重写的特性,能够去除AOF文件中的冗余写命令。

 

 

 

RDB:

Redis主进程fork一个子进程,让子进程执行磁盘IO操作来进行持久化。

RDB将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,这些数据文件代表了某一个时刻中redis的数据。

但是,RDB是间隔一段时间进行持久化的,如果持久化之间redis发生故障,这一段时间内的数据就会丢失(RDB最大的缺点,导致不适合做第一优先的恢复方案,如果你依赖RDB做第一优先恢复方案,会导致丢失比较多的数据)。

为什么是子进程?

(主要是出于Redis性能的考虑,(1)Redis RDB持久化机制会阻塞主进程,这样主进程就无法响应客户端请求。(2)Redis对客户端响应请求的工作模型是单进程和单线程的,如果在主进程内启动一个线程,这样会造成对数据的竞争条件,为了避免使用锁降低性能。基于以上两点这就是为什么Redis通过启动一个进程来执行RDB了)

   

AOF:

可以简单的认为AOF就是日志文件,此文件只会记录"变更操作"(例如:set/del等),将"操作 + 数据"以格式化指令的方式append(追加,顺序写磁盘,没有任何磁盘寻址的开销,因此效率非常高)到操作日志文件的尾部(一般设置每秒一次),在append操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更。"日志文件"保存了历史所有的操作过程;当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程。
但是AOF文件比RDB文件大,且恢复速度慢。

若AOF文件过大,可以使用BGREWRITEAOF命令(BGrewriteAOF),优化aof文件

 

 

 

 

 

 

### 介绍 - **RDBRedis Database)**:RDBRedis 默认的持久化方式,它是将 Redis 在某个时间点上的数据快照保存到磁盘的二进制文件中。这种方式可以在需要时通过加载这个快照文件,快速地恢复 Redis 的数据状态。例如,在服务器重启后,可以利用 RDB 文件迅速将数据恢复到之前保存的状态。 - **AOF(Append Only File)**:AOF 持久化是将 Redis 执行的所有写操作命令,以日志的形式追加到磁盘文件中。当 Redis 重启时,会重新执行这些命令来恢复数据。例如,当执行了 `SET key value` 命令,AOF 文件会记录下这个操作,重启时就会再次执行该命令来恢复数据。 ### 区别 - **存储内容**:RDB 存储的是某个时间点的数据集快照,是二进制格式;AOF 存储的是一条条写操作命令,是文本格式。 - **恢复速度**:RDB 的恢复速度相对较快,因为它直接加载二进制的快照文件;AOF 需要重新执行所有的写操作命令,恢复速度相对较慢。 - **文件大小**:一般情况下,AOF 文件会比 RDB 文件大,因为 AOF 记录的是所有写操作命令。 ### 优缺点 #### RDB - **优点**: - 适合全量快照快速恢复,恢复速度快,因为加载二进制文件比执行大量命令要快得多。 - RDB 文件紧凑,占用空间小,便于传输备份。 - **缺点**: - 数据完整性较差,如果在两次快照之间 Redis 发生故障,会丢失这段时间内的数据。例如,即使每 5 分钟持久化一次,当 Redis 故障时,仍然会有近 5 分钟的数据丢失[^2]。 - 快照生成时会消耗一定的系统资源,可能会影响 Redis 的性能。 #### AOF - **优点**: - 数据完整性高,因为它记录了所有写操作命令,即使 Redis 故障,也只会丢失最后一条未写入的命令。 - AOF 文件是文本格式,易于理解修改。 - **缺点**: - AOF 文件通常比 RDB 文件大,占用更多的磁盘空间。 - 恢复速度相对较慢,因为需要重新执行所有的写操作命令。 - 由于不断追加写操作命令,AOF 文件可能会变得非常大,影响 Redis 的性能。 ### 使用场景 - **RDB 使用场景**: - 对数据完整性要求不是特别高,但需要快速恢复数据的场景,如缓存系统。 - 进行数据备份灾难恢复,因为 RDB 文件紧凑,便于存储传输。 - **AOF 使用场景**: - 对数据完整性要求较高的场景,如数据库。 - 需要实时记录 Redis 操作的场景。 ### 代码示例 以下是在 Redis 配置文件中启用 RDB AOF 持久化的示例: ```plaintext # 启用 RDB 持久化,每 900 秒(15 分钟)如果至少有 1 个 key 发生变化,则进行快照 save 900 1 save 300 10 save 60 10000 # 启用 AOF 持久化 appendonly yes # AOF 文件的名称 appendfilename "appendonly.aof" ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值