宕机了,Redis数据丢了怎么办?

本文详细探讨了Redis的数据持久化方法,包括AOF(Append Only File)日志和RDB(Redis DataBase)内存快照。AOF通过记录执行成功的命令实现数据持久化,提供三种写回策略以平衡数据安全与性能。AOF日志过大时,Redis通过重写机制减少文件大小,重写过程由子线程完成,避免阻塞主线程。RDB则是记录特定时刻的内存数据快照,使用bgsave命令在子线程中执行,利用写时复制技术确保快照完整性。Redis 4.0开始推荐使用AOF和RDB混合持久化,以兼顾快速恢复和避免大量日志。
摘要由CSDN通过智能技术生成

前言

Redis作为内存型的数据库,虽然很快,依然有着很大的隐患,一旦「服务器宕机」重启,内存中数据还会存在吗?

很容易想到的一个方案是从后台数据恢复这些数据,如果数据量很小,这倒是一个可行的方案。但是如果数据量过大,频繁的从后台数据库访问数据,压力很大;另外一方面恢复数据的时间极慢。

对于Redis来说,实现数据的持久化和快速恢复是至关重要。

什么是 AOF 日志?

AOF(Append Only File)日志称之为「写后日志」,即是命令先执行完成,把数据写入内存,然后才会记录日志。

AOF日志(文本形式)会将收到每一条的命令且执行成功的命令以一定的格式写入到文本中(追加的方式)。

「写后日志有什么好处呢?」 如下:

  1. 对于写前日志无论命令是否执行成功都会被记录,但是Redis的写后日志则只有命令执行成功才会被写入日志,避免了日志中存在错误命令;
  2. 同时由于是命令执行成功之后才会写入日志,因此不会阻塞当前命令的执行。

但是AOF日志也有「潜在的风险」,分析如下:

  1. 由于是写后日志,如果在命令执行成功之后,在日志未写入磁盘之前服务器突然宕机,那重启恢复数据的时候,这部分的数据肯定在日志文件中不存在了,那么将会丢失。(无法通过后台数据库恢复的情况下)
  2. 虽然不会阻塞当前命令的执行,由于记录日志也是在主线程中(Redis是单线程),如果日志写入磁盘的时候突然阻塞了,肯定会影响下一个命令的执行。

为了解决上面的风险,AOF日志提供了三种回写策略。

三种写回策略

AOF机制提供了三种回写策略,这些都在appendfsync配置,如下:

  1. Always(同步写回):命令执行完成,立马同步的将日志写入磁盘
  2. Everysec(每秒写回):命令执行完成后,先将日志写入 AOF 文件的内存缓冲区,每隔一秒把缓冲区中内容写入磁盘。
  3. No(操作系统控制的写回):每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。

其实这三中写回策略都无法解决主线程的阻塞和数据丢失的问题,分析如下:

  1. 同步写回:基本不丢失数据,但是每步操作都会有一个慢速的落盘操作,不可避免的影响主线程性能。
  2. 每秒写回:采用一秒写一次到 AOF 日志文件中,但是一旦宕机还是会丢失一秒的数据。
  3. 操作
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值