这是我参与11月更文挑战的第1天,活动详情查看:2021最后一次更文挑战
基本概念
- 日志技术是宕机恢复的主要技术之一
- 日志技术最初使用在数据库系统中
- 在分布式系统的实践中,广泛使用了日志技术做宕机恢复
- 例如BigTable等系统将日志保存到一个分布式系统中进一步增强了系统容错能力
问题背景
- 设计一个高速的单机查询系统:
- 将数据全部存放在内存中以实现高速的数据查询,每次更新操作只更新一小部分数据. 比如只更新key-value中的key
- 现在要求利用日志技术实现该内存查询系统的宕机恢复:
- 与数据库的事务不同的是,这个问题模型中的每个成功的更新操作都会生效
- 等效于数据库中: 每个事务只有一个更新操作,且每次更新操作都可以也必须立即提交auto commit
Redo Log
- Redo Log处置流程:
- 将更新操作的结果以追加写append的方式写入磁盘的日志文件
- 按更新操作修改内存中的数据
- 返回更新成功
- 从Redo Log的流程可以看出:
- Redo写入日志的是更新操作完成后的结果
- 顺序追加写日志文件,在磁盘等对顺序写有力的存储设备上效率很高
- 使用Redo Log进行宕机恢复非常简单,只需要 “回放” 日志即可
Redo Log的宕机恢复
- 从头读取日志文件的每次更新操作的结果,用这些结果修改内存中的数据
- 从Redo Log的宕机恢复流程可以看出:
- 只有写入日志文件的更新结果才能在宕机后恢复
- 这也就是在Redo Log流程中需要先更新日志文件再更新内存中的数据的原因
- 如果先更新内存中的数据,那么用户立刻就能读到更新后的数据,如果在完成内存修改与写入日志之间发生宕机,那么最后一次更新操作无法恢复,但是之前用户已经读取到了更新后的数据,从而引起不一致的问题
Check Point
- Check Point的技术过程:
- 将内存中的数据以某种易于重新加载的数据组织方式完整的dump到磁盘,从而减少宕机恢复时需要回放的日志数据
- Check Point流程:
- 向日志文件中记录 “Begin Check Point”
- 将内存中的数据以某种易于加载的数据组织方式dump到磁盘上
- 向日志文件中记录 “End Check Point” 在check point流程中,数据可以从日志文件中的 “Begin Check Point” 读取记录的结果,用这些结果修改内存中的数据
- 在这段过程中新更新的数据可以dump到磁盘也可以不dump到磁盘,取决于具体实现:
Check Point的宕机恢复
- 将dump到磁盘的数据加载到内存
- 从后向前扫描日志文件,寻找最后一个 “End Check Point” 日志
- 从最后一个 “End Check Point” 日志向前找到最近一个 “Begin Check Point” 日志,并回放该日志之后的所有更新操作日志
0/1目录技术
- 如果数据维护在磁盘中,某批更新由若干个更新操作组成,这些更新操作需要原子生效.也就是说要么同时生效,要么都不生效
- 0/1目录技术中有两个目录结构:
- Directory 0: 目录0
- Directory 1: 目录1
- 另外有一个结构称为主记录 : Master Record,
- 活动目录: 记录当前正在使用的目录
- 主记录Master Record要么记录使用目录0, 要么记录使用目录1
- 目录0和目录1中记录了各个数据在日志文件中的位置
- 0/1目录的数据更新过程始终在非活动目录上进行,只是在数据生效前,将主记录中的0,1值反转,从而切换主记录Master Record
0/1目录数据更新流程
- 0/1目录数据更新流程:
- 将活动目录完整拷贝到非活动目录
- 对于每个更新操作,新建一个日志项记录操作后的值,并在非活动目录中将相应数据的位置修改为新建的日志项的位置
- 原子性修改主记录Master Record: 反转记录中的值,使得非活动目录生效
- 0/1目录的更新通过0,1目录的主记录Master Record切换使得一批修改的生效是原子的
- 0/1目录将批量事务操作的原子性通过目录手段归结到主记录Master Record的原子切换
- 由于多条记录的原子修改一般较难实现而单条记录的原子修改往往可以实现,从而降低了问题的实现难度
- 工程实践中 ,0/1目录的思想运用非常广泛,形式不仅仅是在数据更新流程中,也可以是内存中的两个数据结构来回切换,也可以是磁盘上的两个文件目录的来回生效切换
近期评论