2月15日分布式学习笔记|青训营笔记

117 阅读3分钟

这是我参与【第五届青训营】伴学笔记创作活动的第十四天

书接上文:

本地验证:客户对一个逻辑对象的读请求可由任何可用的副本管理器执行,而写请求必须由具有该对象的所有可用副本管理器执行。==读要一个同意即可,写要所有的同意==只要可用的副本管理器集没有变化,本地的并发控制和读一个/写所有复制一样可获得单拷贝串行化。 本地验证用来确保任何故障或恢复事件不会在事务的执行过程中发生。

网络分区: 复制方案假设:网络分区终将修复,单个分区中的副本管理器必须保证在分区期间它们执行的任何请求在分区修复后不会造成不一致。

  • 乐观方法:允许在所有的分区中进行操作,造成的不一致在分区修复后解决。如对更新进行验证,丢弃任何违背单拷贝串行化准则的更新。
  • 悲观方法:阻止分区中可能导致不一致的操作。如操作仅在一个分区进行,分区修复后更新其余分区。

5. 高可用服务的实例研究:gossip体系结构、Bayou和Coda体系结构及复制策略


5.1 闲聊体系结构


  • gossip算法又被称为反熵(Anti-Entropy),熵是物理学上的一个概念,代表杂乱无章,而反熵就是在杂乱无章中寻求一致。
  • gossip的特点:在一个有界网络中,每个节点都随机地与其他节点通信,经过一番杂乱无章的通信,最终所有节点的状态都会达成一致。每个节点最初可能知道所有其他节点,也可能仅知道几个邻居节点,只要这些节点可以通过网络连通,最终他们的状态都是一致的。
  • 前端可以选择任意副本管理器
  • 提供两种基本操作:查询+更新
  • 副本管理器定期通过gossip消息来传递客户的更新 系统的两个保证:
    • 随着时间的推移,每个用户总能获得一致服务
    • 副本之间松弛的一致性
      • 所有副本管理器最终将收到所有更新
      • 两个客户可能会观察到不同的副本
      • 客户可能观察到过时数据

查询和更新操作流程:

  1. 请求:前端将请求发送至副本管理器。
  2. 更新响应:副本管理器立即应答收到的更新请求。
  3. 协调:收到请求的副本管理器并不处理操作,直到它能根据所要求的次序约束处理请求为止。
  4. 执行: 副本管理器执行请求
  5. 查询响应:副本管理器对查询请求立即作出应答
  6. 协定:副本管理器通过交换gossip消息进行相互更新
  7. gossip消息的交换是偶尔的
  8. 发现消息丢失后,才和特定的副本管理器交换消息