Redis第二弹,服务器宕机,数据丢了怎么办?

本文深入探讨了Redis的两种持久化机制:AOF(Append Only File)和RDB(Redis Database)。AOF通过记录操作命令实现数据持久化,有同步写回、每秒写回和操作系统控制的写回三种策略,同时提供了重写机制避免日志文件过大。而RDB则是内存快照,通过fork子线程避免主线程阻塞,利用Copy-On-Write技术保证快照完整性。文章还讨论了AOF和RDB的混合使用,以平衡数据恢复速度和日志文件大小。
摘要由CSDN通过智能技术生成

前言

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

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

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

今天这篇文章就来介绍一下Redis持久化的两种机制AOF日志、RDB快照。

什么是 AOF 日志?

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

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

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

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

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

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

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

三种写回策略

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

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

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

    • 0
      点赞
    • 0
      收藏
      觉得还不错? 一键收藏
    • 0
      评论
    评论
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

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

    抵扣说明:

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

    余额充值