《Redis 核心技术与实战》课程学习笔记(四)

news/2024/10/30 15:29:01/

Redis 持久化机制

AOF日志:宕机了,Redis 如何避免数据丢失?

  • 一旦服务器宕机,内存中的数据将全部丢失。目前,Redis 的持久化主要有两大机制,即 AOF 日志和 RDB 快照。

AOF 日志是如何实现的?

  • 我们比较熟悉的是数据库的写前日志(Write Ahead Log, WAL),也就是说,在实际写数据前,先把修改的数据记到日志文件中,以便故障时进行恢复。不过,AOF 日志是写后日志,“写后”的意思是 Redis 是先执行命令,把数据写入内存,然后才记录日志。
    • 传统数据库的日志,例如 redo log(重做日志),记录的是修改后的数据,而 AOF 里记录的是 Redis 收到的每一条命令,这些命令是以文本形式保存的。
    • 为了避免额外的检查开销,Redis 在向 AOF 里面记录日志的时候,并不会先去对这些命令进行语法检查。所以,如果先记日志再执行命令的话,日志中就有可能记录了错误的命令,Redis 在使用日志恢复数据时,就可能会出错。
    • 写后日志这种方式,就是先让系统执行命令,只有命令能执行成功,才会被记录到日志中,否则,系统就会直接向客户端报错。所以,Redis 使用写后日志这一方式的一大好处是,可以避免出现记录错误命令的情况
    • 除此之外,AOF 还有一个好处:它是在命令执行后才记录日志,所以不会阻塞当前的写操作。
  • AOF 也有两个潜在的风险。
    • 首先,如果刚执行完一个命令,还没有来得及记日志就宕机了,那么这个命令和相应的数据就有丢失的风险。
    • 其次,AOF 虽然避免了对当前命令的阻塞,但可能会给下一个操作带来阻塞风险。因为 AOF 日志也是在主线程中执行的,如果在把日志文件写入磁盘时,磁盘写压力大,就会导致写盘很慢,进而导致后续的操作也无法执行了。

三种写回策略

  • AOF 配置项 appendfsync 的三个可选值。
    • Always,同步写回:每个写命令执行完,立马同步地将日志写回磁盘;
      • “同步写回”可以做到基本不丢数据,但是它在每一个写命令后都有一个慢速的落盘操作,不可避免地会影响主线程性能;
    • Everysec,每秒写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘;
      • “每秒写回”采用一秒写回一次的频率,避免了“同步写回”的性能开销,虽然减少了对系统性能的影响,但是如果发生宕机,上一秒内未落盘的命令操作仍然会丢失。
      • 所以,这只能算是,在避免影响主线程性能和避免数据丢失两者间取了个折中。
    • No,操作系统控制的写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。
      • 虽然“操作系统控制的写回”在写完缓冲区后,就可以继续执行后续的命令,但是落盘的时机已经不在 Redis 手中了,只要 AOF 记录没有写回磁盘,一旦宕机对应的数据就丢失了;
  • 总结一下就是:想要获得高性能,就选择 No 策略;如果想要得到高可靠性保证,就选择 Always 策略;如果允许数据有一点丢失,又希望性能别受太大影响的话,那么就选择 Everysec 策略。
    在这里插入图片描述

日志文件太大了怎么办?

  • AOF 重写机制就是在重写时,Redis 根据数据库的现状创建一个新的 AOF 文件,也就是说,读取数据库中的所有键值对,然后对每一个键值对用一条命令记录它的写入。

AOF 重写会阻塞吗?

  • 和 AOF 日志由主线程写回不同,重写过程是由后台线程 bgrewriteaof 来完成的,这也是为了避免阻塞主线程,导致数据库性能下降。
  • 重写的过程可总结为“一个拷贝,两处日志”。
    • 一个拷贝
      • 每次执行重写时,主线程 fork 出后台的 bgrewriteaof 子进程。
      • 此时,fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程,这里面就包含了数据库的最新数据。
      • 然后,bgrewriteaof 子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。
    • 两处日志
      • 因为主线程未阻塞,仍然可以处理新来的操作。
      • 此时,如果有写操作,第一处日志就是指正在使用的 AOF 日志,Redis 会把这个操作写到它的缓冲区。
      • 这样一来,即使宕机了,这个 AOF 日志的操作仍然是齐全的,可以用于恢复。
      • 第二处日志,就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。
      • 这样,重写日志也不会丢失最新的操作。
      • 等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的 AOF 文件,以保证数据库最新状态的记录。
      • 此时,我们就可以用新的 AOF 文件替代旧文件了。
  • 每次 AOF 重写时,Redis 会先执行一个内存拷贝,用于重写;然后,使用两个日志保证在重写过程中,新写入的数据不会丢失。而且,因为 Redis 采用额外的线程进行数据重写,所以,这个过程并不会阻塞主线程。
    在这里插入图片描述

内存快照:宕机后,Redis 如何实现快速恢复?

  • 所谓内存快照,就是指内存中的数据在某一个时刻的状态记录。
    • Redis 把某一时刻的状态以文件的形式写到磁盘上,也就是快照。这样一来,即使宕机,快照文件也不会丢失,数据的可靠性也就得到了保证。这个快照文件就称为 RDB 文件,其中,RDB 就是 Redis DataBase 的缩写。
    • 和 AOF 相比,RDB 记录的是某一时刻的数据,并不是操作,所以,在做数据恢复时,我们可以直接把 RDB 文件读入内存,很快地完成恢复。

给哪些内存数据做快照?

  • Redis 的数据都在内存中,为了提供所有数据的可靠性保证,它执行的是全量快照,也就是说,把内存中的所有数据都记录到磁盘中。
  • Redis 提供了两个命令来生成 RDB 文件,分别是 save 和 bgsave。
    • save:在主线程中执行,会导致阻塞;
    • bgsave:创建一个子进程,专门用于写入 RDB 文件,避免了主线程的阻塞,这也是 Redis RDB 文件生成的默认配置。

快照时数据能修改吗?

  • 为了快照而暂停写操作,肯定是不能接受的。所以这个时候,Redis就会借助操作系统提供的写时复制技术(Copy-On-Write, COW),在执行快照的同时,正常处理写操作。
    • bgsave 子进程是由主线程 fork 生成的,可以共享主线程的所有内存数据。
    • bgsave 子进程运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。
    • 此时,如果主线程对这些数据也都是读操作,那么,主线程和 bgsave 子进程相互不影响。
    • 但是,如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。
    • 然后,bgsave 子进程会把这个副本数据写入 RDB 文件,而在这个过程中,主线程仍然可以直接修改原来的数据。
      在这里插入图片描述
  • 所谓增量快照,就是指,做了一次全量快照后,后续的快照只对修改的数据进行快照记录,这样可以避免每次全量快照的开销。
  • Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。
    • 简单来说,内存快照以一定的频率执行,在两次快照之间,使用 AOF 日志记录这期间的所有命令操作。
    • 这样一来,快照不用很频繁地执行,这就避免了频繁 fork 对主线程的影响。
    • 而且,AOF 日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出现文件过大的情况了,也可以避免重写开销。
      在这里插入图片描述
  • 关于 AOF 和 RDB 的选择问题:
    • 数据不能丢失时,内存快照和 AOF 的混合使用是一个很好的选择;
    • 如果允许分钟级别的数据丢失,可以只使用 RDB;
    • 如果只用 AOF,优先使用 everysec 的配置选项,因为它在可靠性和性能之间取了一个平衡。

http://www.ppmy.cn/news/747559.html

相关文章

新后缀supporthelpgood勒索病毒出现 解密sql文件 恢复成功mdf

新后缀supporthelpgood勒索病毒出现,这种病毒类似于常见的病毒后缀AOL/auchentoshan/VC/ciphered/scaletto危害广请大家注意防范上海某公司中了后缀是supporthelpgood的勒索病毒,how_to_open_files.html,中病毒后,公司财务系统崩溃…

如何恢复supporthelpgood勒索病毒how_to_back_files.html成功处理

后缀.supporthelpgood,.Scaletto,.COLORIT勒索病毒出现,该恶意软件使用AES和RSA算法的组合来加密数据并添加文件扩展名。但是,几乎每个月都会出现新版本,此时病毒会附加以下扩展名:.COLORIT,.sc…

中了敲诈者病毒,文件恢复有可能吗?你长着一张被勒索木马敲诈的脸?

导语:勒索木马在天朝已经屡见不鲜,为了让更多无辜读者完美躲避勒索木马的袭击,360反病毒小组负责人、拥有长达9年恶意软件查杀经验的王亮来解密勒索木马。

最新变体后缀YOUR_LAST_CHANCE勒索病毒分析处理数据恢复,扩展名firex3m系列

什么是.YOUR_LAST_CHANCE勒索病毒?什么是YOUR_LAST_CHANCE勒索病毒?是否可以恢复.YOUR_LAST_CHANCE加密的文件? 后缀.YOUR_LAST_CHANCE是最新勒索病毒。它通过将.YOUR_LAST_CHANCE扩展名附加到文件来加密文件,使其无法访问。所有加…

.Lucky勒索病毒删除+.Lucky后缀文件恢复工具

本文解释了.lucky勒索感染病毒时会出现什么问题。它还提供了有关如何删除此勒索软件并可能还原.lucky文件的说明。 最近发现了一种新的勒索病毒。这次威胁附加扩展名.lucky后缀,这就是为什么它被称为.lucky勒索病毒。作为典型的数据锁定器勒索软件,Dharm…

GandCrab V5.1勒索病毒解密删除+尝试和恢复数据,随机字母文件后缀

文章解释了什么是GANDCRAB 5.1勒索软件病毒以及受害者如何在不损坏加密文件的情况下将其从计算机中删除。 GANDCRAB 5.1勒索软件与该病毒的其他版本类似,该恶意软件旨在加密文件,然后将其作为人质,以换取赎金支付。该病毒的主要目的是让受害者…

中国抓到了勒索病毒作者,上市公司停工3天

这事真的,原因江苏警方来北京找华盟总部找到我了,原因我们中过这个病毒给他交过比特币赎金,找我记录一下,准备退款。 随着国外勒索病毒犯罪的兴起,国内此类案件也发生的越来越多,一些企业、金融机构甚至政…

SQLServer数据库mdf文件中了勒索病毒firex3m,扩展名变为mdf.firex3m

** SQL Server数据库mdf文件中了勒索病毒firex3m,扩展名变为mdf.firex3m,导致公司金蝶,用友财务ERP软件不能使用。OA软件也不能使用。 ** 常见的扩展名如下: .firex3m .firex3m .firex3m .firex3m ***.ldf.firex3m ***.mdf.fi…