目录
一、Redis的持久化机制
1.1 RDB
1.2 AOF
1.3 比较
1.4 混合持久化
二、RDB 和 AOF 的写回策略分别是什么?
2.1 RDB的写回策略
定期触发
手动触发
2.2 AOF 的写回策略
三、Redis能完全保证数据不丢失吗?
一、Redis的持久化机制
Redis提供了两种持久化的机制,分别是RDB和AOF。
1.1 RDB
RDB是将Redis的内存中的数据定期保存到磁盘上,以防止数据在Redis进程异常退出或服务器断电等情况下丢失。
RDB的优点是:快照文件小、恢复速度快,适合做备份和灾难恢复。
RDB的缺点是:定期更新可能会丢数据
1.2 AOF
AOF是将Redis的所有写操作追加到AOF文件(Append Only File)的末尾,从而记录了Redis服务器运行期间所有修改操作的详细记录。当Redis重新启动时,可以通过执行AOF文件中保存的写操作来恢复数据。
但是如果Redis刚刚执行完一个写命令,还没来得及写AOF文件就宕机了,那么这个命令和相应的数据就会丢失了。但是他也比RDB要更加靠谱一些。
AOF的优点是:可以实现更高的数据可靠性、支持更细粒度的数据恢复,适合做数据存档和数据备份。
AOF的缺点是:文件大占用空间更多,每次写操作都需要写磁盘导致负载较高。
1.3 比较
RDB 和 AOF 在数据可靠性、性能、存储空间占用等方面都有不同的优缺点,具体可以根据实际业务需求和硬件条件来选择合适的持久化机制,或者同时使用两种持久化机制来实现更高的数据可靠性。
特性 | RDB | AOF |
---|---|---|
数据可靠性 | 可能会丢失最后一次快照之后的数据 | 保证最后一次写操作之前的数据不会丢失 |
性能 | 读写性能较高,适合做数据恢复 | 写性能较高,适合做数据存档 |
存储空间占用 | 快照文件较小,占用空间较少 | AOF 文件较大,占用空间较多 |
恢复时间 | 从快照文件中恢复数据较快 | 从 AOF 文件中恢复数据较慢 |
1.4 混合持久化
AOF 和 RDB 各自有优缺点,为了让用户能够同时拥有上述两种持久化的优点,Redis 4.0 推出了 RDB-AOF 混合持久化。
在开启混合持久化的情况下,AOF 重写时会把 Redis 的持久化数据,以 RDB 的格式写入到 AOF 文件的开头,之后的数据再以 AOF 的格式追加到文件的末尾。
aof-use-rdb-preamble
是开启混合模式的参数。
混合持久化结合了 RDB 和 AOF 持久化的优点,开头为 RDB 的格式,使得 Redis 可以更快地启动,同时结合 AOF 的优点,又减低了大量数据丢失的风险。
但是,在 AOF 文件中添加了 RDB 格式的内容,使得 AOF 文件的可读性变得很差;如果开启混合持久化,那么此混合持久化 AOF 文件,是不能用在旧版本中的,不向下兼容的。
二、RDB 和 AOF 的写回策略分别是什么?
写回策略是指将数据从内存写入到持久化存储(如磁盘)的方式和时机。在 Redis 中,不同的持久化机制有着不同的写回策略。
2.1 RDB的写回策略
在 Redis 中,RDB 的写回策略主要包括以下几个方面:
定期触发
Redis 通过配置文件中的 save
参数定义了 RDB 的自动保存条件。以下是默认配置的示例:
save 900 1 # 如果 900 秒内至少有 1 个键发生变化,则保存快照
save 300 10 # 如果 300 秒内至少有 10 个键发生变化,则保存快照
save 60 10000 # 如果 60 秒内至少有 10000 个键发生变化,则保存快照
策略
- Redis 会定期检查这些条件,如果满足,触发 RDB 的保存操作。
- 条件可以通过修改
redis.conf
文件自定义,也可以通过命令动态设置,例如:
CONFIG SET save "300 10 60 10000"
手动触发
在 Redis 中,我们可以通过以下命令手动生成 RDB 文件:
- SAVE:会阻塞 Redis 服务器,直到快照完成。
- BGSAVE:在后台异步生成 RDB 文件,不会阻塞 Redis。
SAVE 操作直接在主线程完成,不适合生产环境。BGSAVE 会 fork 一个子进程生成快照,更高效,但需要一定的系统资源(如内存和 CPU)。
2.2 AOF 的写回策略
AOF 有三种数据写回策略,分别是 Always、Everysec 和 No。
- Always:同步写回。每个写命令执行完,立马同步地将日志写回磁盘。
- Everysec:每秒写回。每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘。
- No:操作系统控制的写回。每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。
“同步写回”可靠性肯定是最高的,但是它在每一个写命令后都有一个落盘操作,而且还是同步的,这和直接写磁盘类型的数据库有啥区别?
“操作系统控制的写回”这种是最不靠谱的,谁知道操作系统啥时候帮你做持久化,万一没来及持久化就宕机了,不就 gg 了。
“每秒写回”是在二者之间折中了一下,异步的每秒把数据写会到磁盘上,最大程度的提升效率和降低风险。
三、Redis能完全保证数据不丢失吗?
Redis提供了两种持久化的机制,分别是RDB和AOF。AOF和RDB各自有优缺点,为了让用户能够同时拥有上述两种持久化的优点,Redis 4.0推出了RDB-AOF混合持久化。
在开启混合持久化的情况下,AOF重写时会把Redis的持久化数据,以RDB的格式写入到AOF文件的开头,之后的数据再以AOF的格式追加到文件的末尾。
那么,有了这个机制之后,能保证Redis的数据一定不丢吗?
不能!
首先Redis是基于内存存储的,虽然有了RDB和AOF的持久化机制,当Redis进程异常退出或服务器断电等情况发生时,内存中的数据可能会丢失。
有一种极端情况,那就是AOF这个持久化方案中,有一种Always的写回策略,即同步写回。也就是说每个写命令执行完,立马同步地将日志写回磁盘。
但是即使是在 always 策略下,也不能保证 100% 不丢失数据的,主要出于以下原因:
-
磁盘和系统故障:如果在写入操作和同步到磁盘之间发生硬件故障或系统崩溃,可能会丢失最近的写操作。
-
操作系统缓冲区:即使 Redis 请求立即将数据同步到磁盘,操作系统的 I/O 缓冲区可能会导致实际写入磁盘的操作延迟发生。如果在写入缓冲区之后,没写磁盘前,机器挂了,那么数据就丢了。
操作系统缓冲区,通常指的是操作系统用于管理数据输入输出(I/O)的一种内存区域。当程序进行文件写入操作时,数据通常首先被写入到这个缓冲区,而不是直接写入到硬盘。
-
磁盘写入延迟:磁盘的写入并非实时完成,特别是在涉及到机械硬盘时,写入延迟主要由磁盘旋转速度(RPM)和寻道时间决定。如果在这个延迟过程中,机器挂了,那么数据也就丢了。