江苏龙网

  1. 首页 > 人文 > >

暗淡青春|宕机后，Redis如何实现快速恢复？( 二 )


你可能会想到 ， 可以用 bgsave 避免阻塞啊 。 这里我就要说到一个常见的误区了 ， 避免阻塞和正常处理写操作并不是一回事 。 此时 ， 主线程的确没有阻塞 ， 可以正常接收请求 ， 但是 ， 为了保证快照完整性 ， 它只能处理读操作 ， 因为不能修改正在执行快照的数据 。
为了快照而暂停写操作 ， 肯定是不能接受的 。 所以这个时候 ， Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW） ， 在执行快照的同时 ， 正常处理写操作
简单来说 ， bgsave 子进程是由主线程 fork 生成的 ， 可以共享主线程的所有内存数据 。 bgsave 子进程运行后 ， 开始读取主线程的内存数据 ， 并把它们写入 RDB 文件 。
此时 ， 如果主线程对这些数据也都是读操作（例如图中的键值对 A） ， 那么 ， 主线程和 bgsave 子进程相互不影响 。 但是 ， 如果主线程要修改一块数据（例如图中的键值对 C） ， 那么 ， 这块数据就会被复制一份 ， 生成该数据的副本 。 然后 ， bgsave 子进程会把这个副本数据写入 RDB 文件 ， 而在这个过程中 ， 主线程仍然可以直接修改原来的数据 。
暗淡青春|宕机后，Redis如何实现快速恢复？这既保证了快照的完整性 ， 也允许主线程同时对数据进行修改 ， 避免了对正常业务的影响 。
到这里 ， 我们就解决了对“哪些数据做快照”以及“做快照时数据能否修改”这两大问题：Redis 会使用 bgsave 对当前内存中的所有数据做快照 ， 这个操作是子进程在后台完成的 ， 这就允许主线程同时可以修改数据 。
现在 ， 我们再来看另一个问题：多久做一次快照？我们在拍照的时候 ， 还有项技术叫“连拍” ， 可以记录人或物连续多个瞬间的状态 。 那么 ， 快照也适合“连拍”吗？
可以每秒做一次快照吗？
对于快照来说 ， 所谓“连拍”就是指连续地做快照 。 这样一来 ， 快照的间隔时间变得很短 ， 即使某一时刻发生宕机了 ， 因为上一时刻快照刚执行 ， 丢失的数据也不会太多 。 但是 ， 这其中的快照间隔时间就很关键了 。
如下图所示 ， 我们先在 T0 时刻做了一次快照 ， 然后又在 T0+t 时刻做了一次快照 ， 在这期间 ， 数据块 5 和 9 被修改了 。 如果在 t 这段时间内 ， 机器宕机了 ， 那么 ， 只能按照 T0 时刻的快照进行恢复 。 此时 ， 数据块 5 和 9 的修改值因为没有快照记录 ， 就无法恢复了 。
暗淡青春|宕机后，Redis如何实现快速恢复？所以 ， 要想尽可能恢复数据 ， t 值就要尽可能小 ， t 越小 ， 就越像“连拍” 。 那么 ， t 值可以小到什么程度呢 ， 比如说是不是可以每秒做一次快照？毕竟 ， 每次快照都是由 bgsave 子进程在后台执行 ， 也不会阻塞主线程 。
这种想法其实是错误的 。 虽然 bgsave 执行时不阻塞主线程 ， 但是 ， 如果频繁地执行全量快照 ， 也会带来两方面的开销 。
一方面 ， 频繁将全量数据写入磁盘 ， 会给磁盘带来很大压力 ， 多个快照竞争有限的磁盘带宽 ， 前一个快照还没有做完 ， 后一个又开始做了 ， 容易造成恶性循环 。
另一方面 ， bgsave 子进程需要通过 fork 操作从主线程创建出来 。 虽然 ， 子进程在创建后不会再阻塞主线程 ， 但是 ， fork 这个创建过程本身会阻塞主线程 ， 而且主线程的内存越大 ， 阻塞时间越长 。 如果频繁 fork 出 bgsave 子进程 ， 这就会频繁阻塞主线程了 。 那么 ， 有什么其他好方法吗？
如果我们对每一个键值对的修改 ， 都做个记录 ， 那么 ， 如果有 1 万个被修改的键值对 ， 我们就需要有 1 万条额外的记录 。 而且 ， 有的时候 ， 键值对非常小 ， 比如只有 32 字节 ， 而记录它被修改的元数据信息 ， 可能就需要 8 字节 ， 这样的画 ， 为了“记住”修改 ， 引入的额外空间开销比较大 。 这对于内存资源宝贵的 Redis 来说 ， 有些得不偿失 。


推荐阅读


上一篇：【】“拿命打卡”网红公路？交警部门出手了！

下一篇：【】最新版新冠肺炎诊疗方案来了！速看→