分布式复习4~6章

参考：

整体（“爹！”）https://zhuanlan.zhihu.com/p/341819774

基本组播和可靠组播 https://blog.csdn.net/fragile98/article/details/113880738

有序组播 https://www.icode9.com/content-4-872325.html

两阶段锁

本文是在“整体”上，结合自己的看法和老师给的考察框架总结的，其他的同上一篇(包括跪拜)

may the flame guide thee

第四章 协调和协定

1.分布式互斥的含义

• 目的

• • 基于消息传递，实现对临界区资源的互斥访问，防止干扰并保证一致性

• 假设

• • 异步系统
  • 无故障进程
  • 可靠的消息传递

• 执行临界区的应用层协议

• • enter()：进入临界区，必要情况下可以阻塞进入
  • resourceAccesses()：在临界区访问共享资源
  • exit()：离开临界区，其他进程可以访问临界区

• 基本要求

• • 安全性（ME1）

  • • 在临界区内一次只有一个进程执行

  • 活性（ME2）

  • • 进入和离开临界区的请求最终成功执行
    • 既无死锁也无饥饿

  • 顺序（ME3）

  • • 如果一个进入临界区的请求发生在先，则进入临界区时仍按此顺序。
    • 而因为没有全局时钟，有时使用的一个有用的公平性条件，利用了请求进入临界区的消息之间的发生在先顺序

• 性能

• • 带宽消耗，在每个enter和exit操作中发送的消息数

  • 客户延迟，进程进入、退出临界区的等待时间

  • • 由 enter 和 exit 操作引起的延迟

  • 同步延迟，进程切换所消耗的时间

  • • 一个进程离开临界区和下一个进程进入临界区之间的延迟。同步延迟较短时，吞吐量较大

2.解决分布式互斥的方法(4种)：中央服务器、环、组播+逻辑时钟、Maekawa投票算法

1)中央服务器算法

架构

• 满足安全性和活性，但不满足顺序要求（请求过程有延迟）

• 性能分析：

• • 带宽消耗

  • • enter()：2 个消息，请求消息和授权消息
    • exit()：1 个消息，即释放消息

  • 客户延迟，消息往返时间导致请求进程的延迟

  • 同步延迟，一个消息的往返时间

  • 中央服务器是瓶颈

2）环

• 架构，进程安排在一个逻辑环中，每个进程 Pi 与环中的下一个进程 P(i+1) mod N 有一个通信信道

• 满足安全性和活性，但不满足顺序性

• 性能分析

• • 带宽消耗，由于令牌的传递会持续消耗带宽

  • 客户延迟

  • • Min：0 个消息，正好收到令牌的情况
    • Max：N 个消息，刚刚传递了令牌的情况

  • 同步延迟

  • • Min：1 个消息，进程依次进入临界区
    • Max：N 个消息，在一个进程离开和下一个进程进入临界区之间的同步延迟

3）组播 + 逻辑时钟的算法

• 基本思想

• • 进程进入临界区需要所有其它进程的同意

  • • 组播+应答，要进入临界区的进程组播一个请求消息，并且只有在其他进程都回答了这个消息时才能进入

  • 并发控制

  • • 采用 Lamport 时间戳避免死锁，请求进入的消息形如
    • T 是发送者的时间戳， pi 是发送者的标识符。
    • 如果请求具有相等的时间戳，那么请求将根据进程的标识符排序。

• 伪码算法

• • RELEASED 表示在临界区外， HELD 表示在临界区内，WANTED 表示希望进入。

• 性能分析

• • 带宽消耗

  • • enter()，需要 2(N-1)，即 N-1 个请求和 N-1 个应答

  • 客户延迟，一个消息往返时间

  • 同步延迟，一个消息传递时间

4）Maekawa 投票算法

• 基本思想

• • 进程进入临界区需要部分其它进程的同意，不必要所有的对等进程都同意。
  • 只要任意两进程使用的子集有重叠，只需要从其对等进程的子集获得进入许可即可

• Maekawa 将每一个进程都关联到一个选举集 Vi 中

• • Vi 属于 {p1, p2, …, pn}
  • pi 属于 Vi
  • Vi 与 Vj 的交集不为空–任意两个选举集至少有一个公共成员
  • Vi |= K，公平起见, 每个进程有同样大小的选举集
  • 每个进程 pj 包括在选举集 Vi 中的 M 个集合中，M = K

• 算法伪码

• 该算法容易死锁

• 可以修改算法避免死锁，则修改后算法满足安全性、活性、顺序性

• 性能分析

• • 带宽消耗，3 倍根号 N
  • 客户延迟，1 个消息往返时间
  • 同步延迟，1个往返时间

3. 分布式选举的含义

• 基本概念

• • 选举算法，选举一个唯一的进程扮演特定的角色
  • 召集选举，一个进程启动了选举算法的一次运行，原则上 N 个进程可以并发召集 N 次选举
  • 参加者，进程参加了选举算法的某次运行
  • 非参加者，进程当前没有参加任何选举算法
  • 进程标识符，唯一可按全序排序的任何数值

• 基本要求

• • 安全性

  • • 每一个进程都有一个变量 elected
    • 参与的进程 pi 有 electedi= “空”(进程第一次成为一次选举的参与者时，该值还没有定义) 或 electedi = P（P是在运行结束时具有最大标识符的非崩溃进程）

  • 活性

  • • 所有进程 pi 都参加并且最终置 electedi≠“空”或进程 pi 崩溃
    • 可能有还不是参与者的进程 pj， electedi 记录着上次当选进程的标识符

• 性能分析

• • 带宽消耗，与发送消息的总数成正比
  • 回转时间，从启动算法到终止算法之间串行消息传输的次数

4 解决分布式选举的方法(2种)：环、霸道

1)基于环的选举算法

每一个进程有到下一个进程的通信通道，按顺时针发送消息给邻居

• 目的

• • 在异步系统中选举具有最大表示符的进程作为协调者

• 基本思想

• • 最初，每个进程被标记为选举中的一个非参与者。
  • 任何进程可以开始一次选举，它把自己标记为一个参与者，然后把自己的标识符放到一个选举消息里，并把消息顺时针发送给它的邻居

• 伪码算法

• 性能分析

• • 最坏情况

  • • 启动选举算法的逆时针邻居刚好具有最大标识符
    • 带宽消耗，一共需要 3N-1 个消息(为什么？？)
    • 回转时间，3N-1

  • 最好情况，2N

  • 且不具备容错能力

2）霸道算法

• 假设

• • 同步系统，使用超时检测故障
  • 通道可信，但允许进程崩溃
  • 每个进程知道哪些进程具有更大的标识符
  • 每个进程可以和所有更大标识符的进程通信

• 三种消息类型

• • 选举消息，用于宣布选举
  • 应答消息，用户回复选举消息
  • 协调者消息，宣布当选协调者消息

• 如果它具有最大的进程标识符，它会决定自己是协调者，并向其他进程宣布。该算法为“霸道算法”

• 算法伪码

• 性能分析

• • 最好，N-2，标识符次大的进程发起选举，回转时间为 1 个消息
  • 最坏，O(N*N)，标识符最小的进程发起选举

5.基本组播可靠组播的区别

• 区分一下组播和广播

• • 组播，发送一个消息给进程组的每一个进程
  • 广播，发送一个消息给系统中所有进程

• 组播通信系统模型

• • multicast(g,m)，进程发送消息给进程组 g 的所有成员

  • deliver(m)，传递由组播发送的消息到调用进程

  • • 组播消息被进程节点收到后，并不总是被提交到进程内部的应用层

1）基本组播

​ 如果

• 组播进程不出错

• Unicast 是可靠的

• 发送方不崩溃
  我们认为信息可以最终传送到组内

• • 两个原语

    • Deliver(m):传递由组播发送的消息到调用进程 到应用层
    • Receive(m):只是接收到消息
  • • B-multicast(g,m)：对每个进程 p 属于 g，send(p, m)
    • 进程 p receive(m)时，p 执行 B-deliver(m)

2）可靠组播

• • 性质（建议结合下一张图理解，别卡着）

  • • 完整性：一个正确的进程 p 传递一个消息 m 至多一次，消息总可以通过一个与发送者相关的序号区别
    • 有效性：如果一个正确的进程组播消息 m，那么它终将传递 m，并接受他到应用层（Liveness for sender）
    • 协定：如果一个正确的进程传递消息 m，那么在 group(m) 中其他正确的进程终将传递 m（要么所有都能传递到，要么所有都传不了）

  • 有效性和协定保障了整体的活性（overall liveness):如果一些正确的进程组播了信息m，那所有正确进程都会传递信息m。

  • 例子
    如果一个进程B-multicast到一半崩溃了，其他一半进程deliver了m,另一半没有。就破坏了协定（Agreement）

6.实现可靠组播的方法（大爹说要好好看）

可以用于投票，但不一定用于投票，思路上要分开

1）B-multicast 实现可靠组播

（以发动者为开始）初始化为空（其他参与者收到消息后也初始化参与信息为空）

收到信息后检查信息m是否已经在收到的参与信息，不在则添加其中（（全局消息）完整性）。如果发起者不是收到信息者，组播信息（协定）上传最新信息到应用层（有效性）

• 算法评价

  • 满足有效性、完整性、协定
  • 效率低，每个消息被发送到每个进程 |g| 次

2）用 IP 组播实现可靠组播

“java中组播的例子好像是先建立一个虚拟ip，然后组中的都从这个ip接受。
这样服务器只用往虚拟ip发，所有人都可以收到。”

• 特点

  • 即使用户数量成倍增长，主干带宽不需要随之增加
  • 将 IP 组播、捎带确认法和否定确认相结合
• • 基于 IP 组播，IP 组播通信通常是成功的
  • 稍待确认，在发送给组中的消息中捎带确认
  • 否认确认，进程检测到他们漏过一个消息时，发送一个单独的应答消息

• 实现

  • 设存在组g，每个进程p，维护两个信息：
    • 1.Sg.p:意为下一个要发送的信息序号（个人理解，s以为send，g意为group，p代表发送的进程，这里指代任意g组中进程）
    • 2.Rg.q:意为来自进程q的最新消息的序号（个人理解，R指代Received(过去式)，q指代g组中上一个发消息的进程）
  • p要R-multicast一个消息到组g
    • 1.捎带Sg,p和确认（即）（设想发送json格式，多一个元素“序号”，内容是全组人公认的下一个消息好，怎么公认是共识机制的事情，这里假设都打成了共识）
    • 2.本地计数器更新：Sg,p = Sg,p +1
  • 收到一个来自p的广播消息m，准备R-deliver:
    • 收到消息的进程q比对收到消息的序号sg,p=Rg.p+1（1.考虑只有组播消息，否则不满足 +1 限定）
    • 若m.S <= Rg,p, 则该消息已投递，直接丢弃
    • 若m.S > Rg,p +1或对任意捎带过来的确认有Rq > Rg,q, 则漏掉了一个或多个消息。将消息暂存在保留队列中，并发送否认确认NACK，要求重新发送丢失消息。
  • 保留队列 hold-back queue
    • 保留队列并不是可靠性必须的，但它简化了协议，使我们能使用序号来代表已投递的消息集。也提供了投递顺序保证。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fRczfNiv-1638620904415)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211202171527672.png)]

•算法评价

​ •完整性

​ •通过检测重复消息和IP组播性质实现

​ •有效性

​ •仅在IP组播具有有效性时成立

​ •协定

​ •需要：进程无限组播消息（保证有机会探测消息丢失，因为是被动NACK）+无限保留消息副本时成立（一旦收到NACK，重发）à 不现实

​ •某些派生协议实现了协定

3）有序组播

• FIFO排序

​ •如果一个正确的进程发出multcast(g, m)，然后发出multicast(g, m’)，那么每个投递m’的正确的进程将在m’前投递m。

​ •保证每个进程发送的消息在其它进程中的接收顺序一致

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3fMyk6bG-1638620904416)(https://www.icode9.com/i/ll/?i=20210220132606355.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyYWdpbGU5OA==,size_16,color_FFFFFF,t_70)]

• 因果排序、
  • Causal Ordering => FIFO Ordering
    如果一个组播协议实施因果排序，那他肯定也是FIFO ordering
    相反FIFO不能证明有因果排序

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-88ynWzze-1638620904417)(https://www.icode9.com/i/ll/?i=20210220133037431.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyYWdpbGU5OA==,size_16,color_FFFFFF,t_70)]

• 全排序
  • 保证所有进程以同样的顺序传递所有的组播。
    全排序并不关心组播发送的顺序。
    如果一个正确的进程在传递M之前传递M’,那么其他的进程也在传递M之前传递M’。
  • 在所有进程中，传递顺序都是M1:1,M2:1,M3:1，M3:2

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w3IRRUzJ-1638620904418)(https://www.icode9.com/i/ll/?i=20210225162800342.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyYWdpbGU5OA==,size_16,color_FFFFFF,t_70)]

​ 全排序不能保证因果
​ 因果也不能保证全排序

以下是满足因果排序的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m0TkkOO5-1638620904419)(https://www.icode9.com/i/ll/?i=20210225163609830.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyYWdpbGU5OA==,size_16,color_FFFFFF,t_70)]

但是下图不满足全排序，在圈出来的两个地方的两个信息传递的顺序不一样。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D4K3XP5x-1638620904419)(https://www.icode9.com/i/ll/?i=20210225163657610.png?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyYWdpbGU5OA==,size_16,color_FFFFFF,t_70)]

简单的说，FIFO就是本地看到谁先来就是谁，因果要求有因果的事件可以看出排序，无因果顺序先后都行，全排序要求所有节点对事件排序一致

7.共识、拜占庭将军问题、交互一致性 含义

1）共识

• 共识问题：一个或多个进程提议一个值后，应达成一致意见

  •pi: 进程i

  •vi: 进程pi的提议值（proposed value）

  •di: 进程pi的决定变量（decision value）

• 基本要求

• • 终止性，每个正确的进程最终设置它的决定变量di
  • 协定性，如果 Pi 和 Pj 是正确的且已进入决定状态，那么 di=dj
  • 完整性，如果正确的进程都提议了同一个值，那么处于决定状态的任何正确进程都已选择该值

2）拜占庭问题

• 问题描述

• • 3 个或更多的将军协商是进攻还是撤退
  • 1 个或多个将军可能会叛变
  • 所有未叛变的将军执行相同的命令

• 与共识问题区别

• • 拜占庭是一个独立的进程提供一个值，其他进程决定是否采取该值
  • 共识是每个进程都会提议一个值

3）交互一致性

• 每一个进程提供一个值，最终就一个值向量达成一致

• • 决定向量：向量中每个分量与一个进程的值对应
  • 可以应用在分布式机器获取其他所有机器的状态信息

• 算法要求

• • 终止性，每个正确进程最终设置它的决定变量
  • 协定性，所有正确进程的决定向量都相同g
  • 完整性，如果进程 Pi 是正确的，那么所有正确的进程都把 Vi 作为他们决定向量中第 i 个分量

8.3 个、4 个拜占庭将军问题分析

1)三个拜占庭将军

• 两个条件

• • 每两个忠诚的将军必须收到相同的值 V(i)（第 i 个将军的命令）
  • 如果第 i 个将军是忠诚的，那么他发送的命令和每个忠诚将军收到的 V(i) 相同

• 简化模型

• • 使用一个将军发送多个中尉的形式来证明，发送命令的将军称为司令，接受命令的将军称为中尉：

  • • 所有忠诚的中尉遵守相同的命令
    • 如果发出命令的将军是忠诚的，那么所有忠诚的中尉遵守司令的命令

• 对 N <= 3f 的不可能性 （作恶的人超过1/3即忠臣不可打成共识）

• • n1、n2、n3

  • • 将 N 个将军分成三组（不是3个），n1+n2+n3=N 且 n1、n2、n3<=N/3

  • P1、P2、P3，分别模拟 n1、n2、n3个将军（组和个原理类似）

2)四个拜占庭将军

• 解决方案

• • 正确的将军通过两轮消息取得一致

  • • 第一轮，司令给每个中尉发送一个值
    • 第二轮，每个中尉将自己的值发给自己的同级
    • 每个中尉执行 majority() 函数

• 性能讨论

• • 进行 f+1 轮消息传递
  • 发送了 O(N 的 f+1 次方)
  • 上图，错误节点小于33%，必然得到共识如果将军对的，忠臣可以得到消息；将军错的，忠臣得到共识（皇帝是傻逼）

第五章：事务和并发控制

1.串行等价的概念、充要条件、应用（背错了没分）

• 串行等价

• • 如果并发事务交错执行操作的效果等同于按某种次序一次执行一个事务的效果，那么这种交错执行是一种串行等价的交错执行
  • 相同效果： 读操作 返回值相同，且对象变量相同

• 两个事务串行等价充要条件

• • 两个事务中所有的冲突操作都按相同的次序在它们访问的对象上执行（先T后U *2）

• 应用

• • 串行等价可作为一个标准用于生产并发控制协议

  • • 并发控制协议用于将访问的并发事务串行化

2.事务的三种基本控制方法（锁、乐观方法：向前、向后、时间戳）的原理、实现、比较

1）锁

• 互斥锁是一种简单的事务串行化机制

• • 事务访问对象前请求加锁
  • 若对象已被其他事务锁住，则请求被挂起，直至对象被解锁

• 两阶段加锁，事务释放任何一个锁后，都不允许再申请新的锁

• • 为了保证两个事务的所有冲突操作必须以相同的次序执行:
  • 每个事务的第一阶段是一个“增长”阶段，事务不断地获取新锁；
  • 在第二个阶段，事务释放它的锁（“收缩阶段”）
  • （个人简单的理解为要申请锁直接申请完，别执行一半申请新的，不允许。尤其不允许申请两个释放一个再申请一个这种反复横跳操作）
  • 若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。

• 

• 严格的两阶段加锁

• • 所有在事务执行过程中获取的新锁必须在事务提交或放弃后才能释放
  • 目的是防止事务放弃导致的脏数据读取、过早写入等问题

• 读写锁

• • 目的：提高并发度
  • 支持多个事务同时读取某个对象
  • 允许一个事务写对象

• 事务冲突规则

• • 已读不可写
  • 已写不可读和写

• 死锁：死锁是一种状态，在该状态下一组事务中的每一个事务都在等待其它事务释放某个锁

• 预防死锁

• • 每个事务在开始运行时锁住它要访问的所有对象（两阶段锁？）

  • • 一个简单的原子操作
    • 不必要的资源访问限制
    • 无法预计将要访问的对象

  • 次序加锁

  • • 过早加锁
    • 减少并发度

• 死锁检测

• • 维护等待图
  • 检测等待图中是否存在环路
  • 若存在环路，则选择放弃一个事务

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UKLruCuu-1638620904422)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211202213322564.png)]

• 锁超时，解除死锁最常用的方式

• • 每个锁都有一个时间期限
  • 超过时间期限的锁成为可剥夺锁
  • 若存在等待可剥夺锁保护的对象，则对象解锁

2）乐观并发控制

• 乐观策略

• • 基于事实，大多数应用中，两个客户事务访问同一个对象的概率很低

  • 方法

  • • 访问对象时不做检查操作
    • 事务提交时检测冲突
    • 若存在冲突，则放弃一些事务

• 事务三阶段

• • 工作阶段（给副本拿着用（指读写），分配个事务号）

  • • 每个事务拥有所修改事务的临时版本
    • 放弃时没有副作用
    • 临时值（写操作）对其他事务不可见
    • 每个事务维护访问对象的两个集合：读集合和写集合

  • 验证阶段（用户表示结束，系统看冲突没）

  • • 在收到closeTransaction请求时，判断是否与其他事务存在冲突
    • 成功允许提交
    • 失败放弃当前事务或者放弃冲突的事务

  • 更新阶段（不冲突就更新）

    • 只读事务通过验证立即提交
    • 写事务在对象的临时版本记录到持久存储器后提交

• 事务的验证

  • n通过读-写冲突规则确保某个事务的执行对其他重叠事务而言是串行等价的
  • 重叠事务是指该事务启动时还没有提交的任何事务

• • 事务号

  • • 每个事务在进入验证阶段前被赋予一个事务号
    • 事务号是整数，并按升序排序
    • 事务按事务号顺序进入验证阶段
    • 事务按事务号提交

  • 冲突规则

  • • 事务 Tv 的验证测试
    • Ti 和 Tv 之间存在冲突
    • 事务 Tv 对事务 Ti 而言是可串行化的
    • 每次只允许一个事务处于验证和更新阶段

• 事务验证必须保证事务的对象之间的重叠遵循规则 1 和规则 2。有两种验证方式

• • 向后验证，检查当前事务和较早重叠事务之间的冲突
  • 向前验证，检查当前事务和其他较晚事务之间的冲突

向后验证

• 向后：较早的重叠事务

• 检查Tv的读集是否和其它较早重叠（Tv进入提交开始之前开始的新事务（可能已经先结束））事务的写集是否重叠

• • 算法

  • • startTn: Tv 进入工作阶段时已分配的最大事务号码
    • finishTn: Tv 进入验证阶段时已分配的最大事务号码
    • 这期间新申请的事务一个个比对，如果Tv的读集合与Ti写集合重叠，冲突，验证失败

• • • 若验证失败，放弃当前验证的事务

​ startTn+1=T2，finishTn=T3（俺寻思这里的Tv应该是指图上T1）

向前验证

• 向前：重叠的活动事务（工作阶段的事务）

• • 算法

  • • avtive1~activeN，活动中的事务

• n验证失败后，冲突解决方法

  • 放弃当前进行验证事务
  • 推迟验证
  • 放弃所有冲突的活动事务，提交已验证事务。

• 向前验证和向后验证的比较

• • 向前验证在处理冲突时比较灵活
  • 向后验证将较大的读集合和较早事务的写集合进行比较
  • 向前验证将较小的写集合和活动事务的读集合进行比较
  • 向后验证需要存储已提交事务的写集合
  • 向前验证不允许在验证过程中开始新事务

年少无知，人颂我写；年老言休，人写我读

饥饿

​ 一个事务放弃后会被重启，但不能保证事务最终能通过验证检查

​ 利用信号量，实现资源的互斥访问，避免事务饥饿

3） 时间戳排序

• 时间戳

• • 每个事务在启动时被赋予一个唯一的时间戳
  • 时间戳定义了该事务在事务时间序列中的位置
  • 不会引起死锁

• 基本思想

  • 事务中每个操作再执行前进行验证

• 冲突规则

• • 写请求有效

  • • 对象的最后一次读访问或写访问由一个较早的事务执行的情况下

  • 读请求有效

  • • 对象的最后一次写访问由一个较早事务执行的情况下

• 基于时间戳的并发控制

• • 临时版本

  • • 写操作记录在对象的临时版本中（简单地说，所有临时版本都是最新写版本的复制）
    • 临时版本中的写操作对其他事务不可见

  • 读和写时间戳

  • • 已提交对象的写时间戳比所有临时版本都要早
    • 读时间戳集用集合中最大值来表示
    • 事务的读操作作用于时间戳小于该事务时间戳的最大写时间戳的对象版本上

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O7p7H36D-1638620904425)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211203153300522.png)]

时间戳排序的写规则

• • 结合上述规则1，2，决定是否接受事务 Tc 对对象 D 执行写操作

if (Tc ≥ D的最大读时间戳 && Tc > D的提交版本上的写时间戳) 
	在D的临时版本上执行写操作，写时间戳置为 Tc
else /* 写操作太晚了 */
	放弃事务 Tc

• • 举例

  • • 事务 T3 的写操作执行情况

• 

abc中T3大于提交版本T1的时间戳，所以图上有T3，表示事务被接受。不管上一个是否是紧密相连的（b），后面有没有其他更新的事务（先接受3再接收4，注意这里4是临时版本！）

d中4从临时变为提交版本，就没必要收3了，T3放弃，不在记录（图中出现）

时间戳排序的读规则

规则3，决定是否接收事务Tc对对象D执行的读操作

if (Tc > D提交版本的写时间戳) 
    设Dselected是D的具有最大写时间戳的版本≤Tc;
        if (Dselected已提交）
            在Dselected版本上完成读操作
         else
            等待直到形成Dselected版本的事务提交或放弃，然后重新应用读规则；
｝else 
	放弃事务 Tc

举例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cjZvecAL-1638620904426)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211203155919962.png)]

我方以时间戳T3请求，服务器方a中有个提交板T2，b中虽然有T4，但因为是临时版本不影响，C中针对临时版本想读（被选中），那就只能等临时版本写完，d中T4>T3，类似给报社说要读10.1的报纸但摊位只有10.2的报纸，读取失败

时间戳应用举例

开始时假设ABC三个账户（对象）刚被（编辑用户S）初始化写入

随后T要B中账户转账给A，先请求读对象，B维护的读序列序列加上T，然后写对象B，写对象A，期间U编辑者想编辑B，但发现B上一个时间戳事件还是临时状态，于是系统拒绝U对B的读并等待T转为提交版B，提交后UgetB的读取版，B的读取序列也加上U

3.该说不说的啊

这章比较烦（也可能是那段时间病了全靠自己理解），几个控制方法的应用对比，ppt后面很多题很有代表性，建议看一下

第六章：复制

1.复制的概念、动机、基本要求

• 概念

• • 在多个计算机中进行数据副本的维护

• 复制的动机：增强服务

• • 增强性能

  • • 浏览器对 WEB 资源的缓存
    • 数据在多个服务器之间的透明复制

  • 提高可用性

    • 1－p的n方，n为服务器个数，p为爆炸概率
  • • 应对服务器故障
    • 网络分区和断链操作：预先复制（n乘火车的用户，无线网络可能会中断（断链工作或者断链操作））

  • 增强容错能力（正确性）

  • • 允许一定数量和类型的故障
      • （软件、硬件、网络）
      • f+1放崩溃，2f+1防拜占庭（51%？？？）
    • 更新统一

• 基本要求

• • 复制透明性

  • • 对客户屏蔽多个物理拷贝的存在
    • 客户仅对一个逻辑对象进行操作

  • 一致性

  • • 在不同应用中有不同强度的一致性需求
    • 复制对象集合的操作必须满足应用需求

2 复制的系统模型：主动复制、被动复制

1）系统模型

• 无论主动或被动复制，都基于该模型，问题在于客户和复数个副本管理器交互方式

• 组件

• • 前端

  • • 接收客户的请求
    • 通过消息传递与多个副本管理器通信
    • 为什么不让客户直接进行通信？（保证复制的透明性）

  • 副本管理器

    • 一个拥有数据拷贝的节点称为副本管理器
  • • 接受前端请求
    • 对副本执行原子性操作

2）被动复制

• 模型

• • 一个副本管理器 + 多个次副本管理器

  • • 若主副本管理器出现故障，则某个备份副本管理器将提升为主副本管理器
    • Raft？

• 操作事件次序

1. 请求：前端将请求发送给主副本管理器

2. 协调（排序）：主副本管理器按接收次序对请求排序（FIFO,因果，全排序）

3. 执行：主副本管理器执行请求并存储响应

   1. 包括试探性执行，即执行效果可以去除

4. 协定（共识）

5. 1. 若请求为更新操作，则主副本管理器向每个备份副本管理器发送更新后的状态、响应和唯一标识符（中心认证类共识）
   2. 备份副本管理器返回确认

6. 响应

7. 1. 主副本管理器将响应发送给前端（也可以多个，总之返回第一个到达的应答）
   2. 前端将响应发送给客户

• 可线性化一致性

  • 操作的次序由时间决定

    链式复制可以提供可线性化

    被动复制（主备份）可以提供可线性化

3）主动复制

• 模型

• • 副本管理器地位相等，前端组播消息给副本管理器组

• 事件次序

1. 请求：前端使用全序、可靠的组播原语将请求组播到副本管理器组

2. 协调：组通信系统以同样的次序(全序)将请求传递到每个副本管理器

3. 执行：每个副本管理器以相同的方式执行请求

4. 协定：鉴于组播的传递语义，不需要该阶段(因为组播，已经服务器对数据状态已经有了共识)

5. 响应

6. 1. 每个副本管理器将响应发给前端
   2. 前端将响应发给客户

• 一致性：顺序一致
  • 每个客户保留程序的次序

4）复制的一致性

1. 可线性化和顺序一致性
2. 更弱的一致性（甚至不关心单个副本的错觉）
3. 因果一致性（正确排序因果相关的写操作）
   1. 因果关系：A读了B写的数据；然后B又写了数据
   2. 所有进程必须以相同的次序看到因果相关的写操作
   3. 不同进程可能会以不同的次序看到并发的写操作
4. 最终一致性 （只要所有的副本最终都收敛到同一个副本）
   1. 网络分区将一个副本管理器组分为两个或更多的子组
   2. 一个子组的成员可相互通信，不同子组的成员不能通信
   3. 如果没有发生分区，相互冲突的两个事务之一将放弃
   4. 当分区存在时，冲突事务已经被允许在不同分区中提交

3.单拷贝串行化的概念 + 读一个写所有方案原理、适用条件（节点不失效上锁）、本地验证方法

目的：复制数据上的事务

• 单拷贝串行化

• • 客户在复制对象上执行的事务的效果应该与它们在一组对象上逐一执行相同（即每个对象 1 个副本）
  • 相当于结合串行等价+复制透明性/一致性
  • 单拷贝串行化可以通过“读一个/写所有”实现复制方案。

• 读一个写所有

• • 每一个写操作必须在任何一个副本管理器上执行，且副本管理器对每一个操作对象加一个写锁
  • 每个读操作由单个副本管理器执行，该副本管理器在操作对象上加一个读锁
  • 适用条件：不发生死锁（需要额外的并发控制实现串行等价）

• 本地验证（不懂）

• • 本地验证用来确保任何故障或恢复事件不会在事务的执行过程中发生

  • 个人理解：通过用户的事件过程可以推断故障顺序，如果抵触，则一方为假，不适用拷贝算法并回滚复原

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wd3r3ON8-1638620904428)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211204183045198.png)]

  • N 出故障 ->T 在 X 上读对象 A；T 在 M 和 P 上写对象 B ->T 提交 ->X 出故障

  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mka9D8uV-1638620904429)(C:\Users\14182\AppData\Roaming\Typora\typora-user-images\image-20211204183104404.png)]

  • X 出故障 ->U 在 N 上读对象 B；U 在 Y 上写对象 A ->U 提交 ->N 出故障

  • X出故障在T验证之后，U验证之前-> U验证在T验证之后 ->两个序列不相容

  • 如果 T 检查 N 不可用，而 X、M、P 可用，T 提交

  • • 这意味着 T 验证之后，U 验证之前 X 出现故障，而 U 验证在 T 验证之后，U 验证失败因为 N 已出故障

• 当正常工作的副本管理器不能和另外的副本管理器通信时，可用拷贝算法不能使用

4.gossip 体系结构、基本操作

• Gossip 定义：又称反熵，表示在杂乱无章中寻求一致

• 特点：

• • 在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。
  • 每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节点可以通过网络连通，最终他们的状态都是一致的

• 体系结构

• • 前端可以选择任意副本管理器
  • 提供两种给基本操作：查询 + 更新
  • 副本管理器定期通过 gossip 消息来传递客户的更新

• 

• 系统的两个保证

• • 随着时间的推移，每个用户总能获得一致服务

  • • 副本管理器提供的数据能反映迄今为止客户已经观测到的更新

  • 副本之间松弛的一致性

  • • 所有副本管理器最终将收到所有更新(最终一致性)
    • 两个客户可能会观察到不同的副本
    • 客户可能观察到过时数据

• 查询和更新流程

• • 请求（爹帮个忙）：前端将请求发送至副本管理器

  • • 查询：客户可能阻塞；
    • 更新：默认立即返回，为提高可靠性，客户可以被阻塞到已经传给f+1个副本管理器后继续执行

  • 更新响应（嗯收到了）：副本管理器立即应答收到的更新请求

  • 协调（刚刚谁先说话？）：收到请求的副本管理器并不处理操作，直到它能根据所要求的次序约束处理请求为止

  • 执行（我记个账）：副本管理器执行请求

  • 查询响应：副本管理器对查询请求立即作出应答

  • 协定：副本管理器通过交换 gossip 消息进行相互更新

  • • gossip 消息的交换是偶尔的
    • 发现消息丢失后，才和特定的副本管理器交换消息

• 前端的版本时间戳

• • 为了控制操作处理次序，每个前端维持了一个向量时间戳，用来反映前端访问的最新数据值的版本
  • 客户通过访问相同的 gossip 服务和相互直接通信来交互数据

• 每个前端维护一个向量时间戳

• • 每个副本管理器有一条对应的记录
  • 更新或查询信息中包含时间戳
  • 合并操作返回的时间戳与前端时间戳

• 向量时间戳的作用

• • 反映前端访问的最新数据值

副本管理器状态

1. 值：副本管理器维护的应用状态的值
2. 值的时间戳：更新的向量时间戳
3. 更新日志：记录更新操作
4. 副本的时间戳：已经被副本服务器接收到的更新
5. 已执行操作表：记录已经执行的更新的唯一标识符，防止重复执行
6. 时间戳表：确定何时一个更新已经应用于所有的副本管理器

5.Coda 体系结构、复制策略（略过Bayou和AFS）

• Coda 目标：

  • 提供一个共享的文件系统
  • 在存储全部或部分不可访问时刻完全依赖本地资源继续操作计算机

• 扩展（相对AFS亮点）：

  • 采用文件卷复制技术——提高吞吐率和容错性
  • 在客户计算机上缓存文件副本——断链处理

• 体系结构

• • Venus/Vice 进程

  • • Venus：前端和副本管理器的混合体
    • Vice：副本管理器

  • 卷存储组（VSG）

  • • 持有一个文件卷副本的服务器集合

  • 可用的卷存储组（AVSG）

  • • 打开一个文件的客户能访问 VSG 的某个子集

  • 文件访问过程

  • • 当前 AVSG 任何一个服务器提供文件服务，并缓存在客户计算机上
    • 对每个副本管理器进行更新分布

  • 关闭文件

  • • 修改过的拷贝 并行 广播到 AVSG 中的所有服务器上

• 复制策略

• • 乐观策略

  • • 在网络分区和断链操作期间，仍然可以进行文件操作

  • Coda 版本向量（CVV，Code Version Vector ）

  • • 作为时间戳附加在每个版本的文件上

    • CVV 中每个元素是一个估计值，表示服务器上文件修改次数的估计

    • 目的：提供足够的关于每个文件副本的更新历史，以检测出潜在的冲突，进行手工干预和自动更新

    • 例如 CVV = (2，2，1)

    • • 文件在服务器 1 上，收到 2 个更新
      • 文件在服务器 2 上，收到 2 个更新
      • 文件在服务器 3 上，收到 1 个更新

  • 冲突检测

  • • 若一个站点的 CVV 大于或等于所有其他站点的 CVV，则不存在冲突。自动更新
    • 若对于两个 CVV 而言，V1 >= V2 和 V2 >= V1 均不成立，则存在冲突。手工干预

  • 文件关闭

  • • Venus 进程发出更新消息（包括 CVV 和文件新内容）到 AVSG
    • AVSG 中每个服务器更新文件，并返回确认
    • Venus 计算新的 CVV，增加相应服务器修改次数，并分发新的 C