分布式系统应当有一定的容错性，发生故障时仍能运行
一些概念：
可用性Availability：系统是否准备好立即使用
可靠性Reliability：系统连续运行不发生故障
安全性：衡量安全故障的指标，没有严重事件发生
可维护性Maintainability：衡量修复系统的难度
错误fault
一个系统在不能满足其规格时发生错误
容错性：存在故障时，系统仍能提供服务种类：暂时、间歇性、永久性故障
暂时、间歇性故障不易修复，难以复现
故障模型
1、崩溃故障 ：服务器停止，但正常工作，直到停止
2、遗漏/省略故障 ：接收遗漏、发送遗漏；服务器无法响应传入请求；服务器无法接收传入消息；服务器失败服务器的响应位于
3、定时故障 ：服务器响应超时；服务器的响应位于指定的时间间隔之外
4、响应失败 ：值故障、状态传递错误；服务器的响应不正确，响应的值错误，服务器偏离了正确的控制流
5、任意故障（拜占庭故障）：服务器可能在任意时间产生任意响应
故障掩盖masking
解决方法：冗余
信息冗余
循环冗余检查（CRC），纠错位
时间冗余
重试，直到成功完成
物理冗余
重复组件（SW/HW）：RAID
流程复制Process Replication
通过复制来屏蔽进程故障。
将流程组织成组，发送给一个组的消息将传递给所有成员。
我们需要创建多少个副本？
如果一个系统有k个故障进程，即使它也能存活和工作，那么它就是k个容错的
崩溃故障： k+1副本
拜占庭失败： 2k+1副本
分布式协议算法
为什么我们需要达成协议？◦
领导，提交，同步问题
要求：
所有无故障的过程在有限的步骤中达成一致共识，无论这个一致是否好。
拜占庭一般问题 ：假设：进程不可靠；通道可靠 ；如果通道不可靠 ？
A，B两方为了保证可靠性，导致无休止地握手
怎么解决
可靠RPC
可能发生的错误
1、客户端无法找到服务器
向客户机返回错误报告，
客户端收到错误通知后可以采用指数退避算法重试，直至超时；或者连接备用服务器
2、客户端请求丢失
重传请求
3、服务器响应丢失
没有简单的解决方案，因为它可能很难区分这种情况与服务器的崩溃。
如果请求是幂等 的，我们可以尝试重新发送 它们。
4、服务器崩溃
症状：发送多次无回应
至少一次语义（At-least-once-semantics）：服务器保证无论如何，它都将至少执行一次操作
要实现至少一次语义，客户端可以不断重发请求，直到从服务器接收到响应或确认。服务器可能需要处理幂等操作，以处理重复的请求。
在金融交易中，至关重要的是资金转账至少执行一次，即使可能导致重复的转账
最多一次语义：服务器保证它最多只执行一次操作
要实现至多一次语义，客户端和服务器可以使用唯一的请求标识符或序列号来识别和丢弃重复的请求。服务器可以维护已执行操作的记录以防止重复执行
在分布式文件系统中，您可能希望确保文件至多被删除一次，以避免数据丢失
5、客户端崩溃
服务器端的孤立计算，免费保留一些资源。服务器或客户端（重新启动后）应该处理孤立文件
恢复recovery
1、前向恢复forward：找到一个系统可以继续运行到新状态（恢复到明天）
先会退止上一个恢复点，在借助log（记录了request）再追赶到新进入的request
2、回滚恢复backward：将系统带回以前的无错误状态；我们需要提前建立恢复点；我们需要让流程合作来确定恢复的一致状态。
recovery line是两个合适的状态相同的checkpoint 相连级联回滚：如果检查点是在"错误"的时刻完成的，则恢复线可能位于系统启动时。事务中的所有操作被撤销，数据库回到事务开始之前的状态，就好像事务从未执行过一样
独立的检查点 ：每个进程都独立地接受检查点，并存在级联回滚到系统启动的风险
协调检查点 ：每个进程在一个全局协调操作之后都接受一个检查点。
简单解决方案（两阶段阻塞）
协调器多播检查点请求消息
当参与者收到这样的消息时，它会执行检查点，停止发送（应用程序）消息，并报告它已经执行了检查点
当所有检查点都在协调器上得到确认时，后者会广播一条检查点完成消息，以允许所有进程继续进行
分布式消息队列
没有消息遗漏
副本如何部署：副本和主数据不能放在一起
snapshot：如何定义checkpoint
logs存放：不能在系统上，在外部；logs不能与实际存储放一起；需要logs的副本吗
同一物理机上多个逻辑分区集群