How’d we get here?
- 失败和单一系统; 容错技术增加了冗余（ECC内存，RAID等）
- 从概念上讲，ECC和RAID都在冗余的前面放置了一个“master”，以便将其从客户端屏蔽掉 - ECC由内存控制器处理，RAID看起来像是一个非常可靠的硬盘驱动器（特殊）
一些简单的例子
- 复制的网站
- e.g., Yahoo! or Amazon:
- 基于DNS的负载均衡（DNS为每个名称返回多个IP地址）
- 硬件负载均衡器在每个IP地址后放置多台机器
只读内容
- 易于复制 - 只需制作多个副本即可。
- 性能提升：获取使用多个服务器来处理负载;
- 性能提升2：局部性。 我们稍后会在讨论CDN时看到这一点，通常可以将客户指向它附近的副本
- 可用性提升：可以进行故障切换（在DNS级别完成 - 速度较慢，因为客户端缓存DNS应答 -- 以及前端硬件级别）
但对于读写数据...
必须实现写复制，通常具有一定程度的一致性
顺序一致性（Sequential Consistency）
（1）
在相同的数据项上操作。 横轴是时间。
想法是P1写入变量X，将其更新为值a。 该更新传播到所有其他本地副本。
在某个点P2读取x，得到一个值Nil（每个数据项初始值NIL），然后为变量x得到一个“a”的值。
（2）
- 数据存储在以下情况下顺序一致：
- 任何执行的结果与数据存储上所有进程的（读取和写入）操作相同...
- 按顺序执行并...
- 每个单独过程的操作都会出现...
- 在这个序列中
- 按其程序指定的顺序。
（3）
顺序一致的数据存储
非顺序一致性
（a）顺序一致，因为尽管P3和P4首先读取'x'的值作为a然后b，但它们都具有相同的视图。
（b）由于最后，P3和P4在最后将具有不同的x（a或b）值，因此不是连续一致的。
因果一致性（Causal Consistency ）
（1）
对于数据存储被认为是因果一致的，必须遵守以下条件：
- 写入可能与因果关系...
- 必须被所有流程看到
- 以相同的顺序。
- 并发写入...
- 可能会以不同的顺序被看到
- 在不同的机器上。
这里有什么因果关系？
进程P1写入一个数据项x。 然后P2读取数据项x，并写入y。 在这个例子中，因为y可能取决于x，所以P1和P2可能是因果相关的。
或者，如果P1和P2正在写入两个同时并且彼此不相关的不同数据项，则它们被认为是并发的。
（2）
image.png
注意：P1：W（x）c和P2：W（x）b是并发的，所以它并不重要，所有进程都以相同的顺序看到它们
然而，Wx（a）和R（x）a然后W（x）b是潜在的因果关系，因此它们必须是有序的。
（3）
侵犯了因果关系一致的存储
P2 W（x）b可能因果关系地表示为W（x）a - 例如，它可能是P2中读取值的结果：R（x）a，因此这两个写入是因果关系的。
如果是这样，那么P3和P4必须以相同的顺序看到它们，而并发输出是不正确的并且违反因果一致的顺序。
（4）
在因果一致的存储中正确的事件序列。
在这个图中，P1：W（x）a与P2：W（x）b并发出现，因此它们不是因果相关的，因此P3和P4可以按照不同的顺序看到它们 - 所以可以。
重要？什么是一致性模型？
- 就像在文件系统中一样，您需要查看您提供的一致性模型
- 真实生活的例子：Google邮件。
- 发送邮件被复制到〜2个物理上分离的数据中心（用户在他们认为他们发送邮件并且丢失时讨厌它）; 在执行此复制时邮件将暂停。
- 问：两阶段提交需要多长时间？ 在广阔的区域？
- 标记邮件读取仅在后台复制 - 您可以将其标记为已读，复制可能会失败，并且您不知道任何线索（稍后重读阅读电子邮件并不是什么大问题）
- 发送邮件被复制到〜2个物理上分离的数据中心（用户在他们认为他们发送邮件并且丢失时讨厌它）; 在执行此复制时邮件将暂停。
复制：状态与操作
- 传播内容的可能性：
- 只传播更新通知。
- 排序“失效”协议
- 只传播更新通知。
- 从一个副本传输数据到另一个副本。
- 读写比高，可以传播日志（节省带宽）
- 将更新操作传播到其他副本
- 不要传输数据修改，只有操作 - “主动复制”
何时复制：拉与推协议
在多客户端，单服务器系统的情况下，推挽式协议之间的比较。
- 基于拉：副本/客户端轮询更新（缓存）
- 推送：服务器推送更新（有状态）
失败模式
- 我们今天假设失败和断开连接是相对罕见的事件 - 它们可能经常发生，但是比方说，任何服务器的时间都超过了90％。
- 我们查看了“断开连接的操作”模式。 例如，CMU CODA系统允许AFS文件系统客户端“离线”工作，然后再重新连接。
我们将假设的工具
- 组会员管理
- 允许副本节点加入/离开
- 故障检测器
- 例如进程对监控等。
