容错
本节目标: 了解容错, 掌握衡量标准并理解其重要性。
什么是容错?
现实世界中的大型应用程序运行着数百台服务器和数据库,以满足数十亿用户的请求,也承担着存储重要数据的任务。这些应用程序需要一种保证数据安全并通过避免单点故障来避免重新计算的计算密集型任务的机制。(也就是容错)
容错指即使一个或多个组件发生故障,系统也能持续执行的能力。相关组件可以是软件(常见的校验程序)或硬件(RAID0~9等)。构思一个百分百容错的系统实际上非常困难。
容错相关系统特性:
可用性侧重于 24*7 用户请求成功与否。
可靠性侧重于每个客户的请求与其响应结果。
容错技术
故障一般发生在 硬件 或 软件 级别, 并最终对数据造成影响
从系统结构的角度, 可以有很多方法实现容错.
接下来我们讨论一些通用的 容错技术.
复制
基于复制的容错 是应用最广泛的容错技术。使用这种技术,我们可以复制服务和数据,将故障节点替换为健康节点,将故障数据存储替换为其副本。大型服务可以在不影响最终客户的情况下透明地进行切换。
为单独的存储创建数据的多个副本也引入了新的技术挑战。
技术难点
当数据发生更新时,所有副本都需要定期更新以保持一致性。更新副本中的数据是一项具有挑战性的工作。当系统需要强一致性时,我们可以同步更新副本中的数据。但是,这会降低系统的可用性。
如果可以容忍最终一致性,我们可以异步更新副本中的数据,但这会导致读过时。
需要使用 CAP 定理 对系统进行灵活的设计
相关信息
笔者的话: 实际项目中, 对应 各种中间件的主从备份 日志备份等
检查点
检查点是一种将系统某个稳定的一致的点 保存在稳定存储中的技术。
检查点可以按照一定的规则在多个时间点执行。主要目的是保存给定点的计算状态。当系统发生故障时,我们可以从上一个检查点获取最后计算的数据并从重新开始工作。
技术难点
检查点也有我们在复制中遇到的同样问题。
当系统必须执行检查点时,需要确保系统处于一致状态,这意味着所有修改系统状态的进程都将停止。这种类型的检查点称为同步检查点。
另一方面,不一致状态下的检查点会导致数据不一致问题。让我们看下图,了解一致状态和不一致状态之间的区别:
Consistent state一致状态:上图显示系统执行检查点时进程之间没有通信。所有进程在检查点之前和之后都在发送或接收消息。系统的这种状态称为一致状态。
Inconsistent state不一致状态:上图还显示了当系统执行检查点时,进程通过消息进行通信。这表示不一致的状态,因为当我们得到一个先前保存的检查点时,进程 i
有消息 m1
,进程j
将没有消息发送记录。