Goal

1. 提供服务

2. Survive the failure of up to f replicas

3. 提供与非复制版本相同的服务（除了更可靠，也许性能不同）

4. 主备份

   • 由主处理的操作，它将副本传送到备份（s）
   • 副本是“被动”的，即跟随主要
   • 好：简单的协议。 不好：客户必须参与恢复。

5. Quorum consensus

   • 即使在故障情况下，其响应时间也很快
   • 副本是“主动”的 - 参与协议; 本身没有master。
   • 好：客户甚至不会看到失败。 不好：更复杂。

基于主备份的协议

1. 客户与主备份交谈
2. 主要的处理请求，原子和幂等，就像你的锁服务器会
3. 将请求发送到备份
4. 备份回复“确定”
5. 向客户端确认

远程写协议

image.png

支持复制的主要备份协议的最简单形式是所有写入都转到单个服务器（固定）并且读取操作可以在本地执行。
由于阻塞操作，进程将看到最近写入的效果。
非阻塞意味着主节点在收到并提交项目“x”的本地副本后发出ACK，然后通知备份/副本进行更新。 这是以容错为代价的。

本地写协议

image.png

优点：可以在副本上本地执行多个连续写入操作，而读取过程可以访问其本地副本。
请注意，对于实际的性能优势，您必须应用非阻塞协议。
这对于移动计算机是一个有用的方案。 在断开连接之前，移动客户端可以成为要更新的文件的主要服务器。 所有更新操作（处于断开模式）均在本地完成，然后从主服务器传播到备份服务器，以使事情再次进入一致状态。 （有点像CODA？）

主备份协议

1. 注意：如果您不关心强一致性（例如“邮件读取”标志），则可以在与备份达成一致之前回复客户端（有时称为“异步复制”）。
2. 这看起来很酷。 有什么问题？
3. 如果副本失败，我们该怎么办？

• 我们等待...多久？ 直到它被标记为死亡。
• 主备份对故障检测器有很强的依赖性。

4. 这对一些服务是可以的，对其他服务不行
5. 优点：使用N台服务器，可以容忍N-1个副本的丢失

主备份协议实现

1. 在数据库和类似文件系统中复制的常用技术：将日志流式传输到备份。 在回复之前，他们不必实际应用更改，只需使日志持久。

2. 您必须重播日志才能重新上线，但支出廉价。

   
   
   image.png
   
   

   这里失败：
   提交仅在主要日志中记录
   主副本死亡？ 客户端必须重新发送到备份

二次主备份协议

这里失败：
提交在备份时记录
主备份死亡？ 客户端必须检查备份