容错和(高)可用性之间有什么区别和关系？
来自Coulouris的分布式系统
第18章复制18.1增加可用性:用户要求服务高度可用。也就是说，以合理的响应时间访问某项服务的时间比例应接近100%。除了由于悲观的并发控制冲突(由于数据锁定)而造成的延迟外，与高可用性相关的因素还有：
- 服务器故障；
- 网络分区和断开连接的操作(通信断开，通常是计划外的，是用户移动的副作用)。
首先，复制是一种在服务器故障的情况下自动维护数据可用性的技术。如果数据是在两个或多个与故障无关的服务器上复制的，那么客户端软件可以在默认服务器故障或无法访问的情况下访问另一个服务器上的数据。网络分区(见第15.1节)和断开操作是影响高可用性的第二个因素。容错:高度可用的数据不一定是严格正确的数据。例如，它可能过时了；或者网络分区对面的两个用户可能会更新冲突，需要解决。相反，容错服务总是保证严格正确的行为，尽管有一定数量和类型的错误。正确性涉及向客户端提供的数据的新鲜度以及客户端操作对数据的影响。正确性有时还涉及服务响应的及时性，例如，在空中交通管制系统的情况下，需要在短时间内提供正确的数据。用于高可用性的相同的基本技术--在计算机之间复制数据和功能--也适用于实现容错。如果f+1服务器崩溃，原则上至少还有一个服务器可以提供该服务。如果多达f台服务器可能出现拜占庭式故障，那么原则上，一组2f +1服务器可以提供正确的服务，方法是让正确的服务器投票给失败的服务器(后者可能提供虚假的值)。但是容错比这个简单的描述看起来要微妙得多。系统必须精确地管理其组件的协调，以维护在任何时候都可能发生的故障时的正确性保证。
和
18.3容错服务(本节描述实现容错的方法)。它介绍了线性化和顺序一致性的正确性准则，然后探讨了两种方法:被动(主备份)复制，其中客户端与区分副本通信；主动复制(主动复制，客户端通过多播方式与所有副本通信) 18.4高可用性服务的案例研究:流言消息体系结构、Bayou和Coda (考虑了用于高可用服务的三个系统的案例研究。在流言和Bayou架构中，更新是在共享数据的副本之间懒洋洋地传播。在Bayou中，使用操作转换技术来执行一致性。Coda是高度可用的文件服务的一个例子。)
我试图理解容错和(高)可用性之间的区别和关系。
- 容错是否意味着高可用性？也就是说，如果一个服务是容错的，那么它一定是高度可用的吗？
- 据我所读(不一定是正确的)，18.3容错服务假设副本之间没有网络分区，并且实现了线性化一致性，而18.4高可用服务的案例研究可以容忍副本之间的网络分区，但具有较弱的一致性。这是真的吗？
我也在想容忍失败和掩盖失败之间有什么区别和关系？。
谢谢。
回答 1
Software Engineering用户
发布于 2019-12-29 16:15:48
基本概念是正交的，但它们是相关的。一个与应用程序的可用性有关，另一个与应用程序的正确性有关。请记住，有不同级别的错误(也称为bug)。
容错
“一切都会失败”--沃纳·沃格尔，亚马逊首席技术官
在设计容错时，您要解决的问题如下：
- 如果我的服务无法访问所需的资源(数据库、存储、消息队列等)，会发生什么？
- 如果我收到坏数据会发生什么？
- 我应该如何处理另一项服务太长时间才能作出回应？
- 我必须符合哪些表现准则？
还有其他相关的问题，你必须问自己。重要的是要认识到，有很多模式可以使您的代码失败，而且运行时间越长，就越有可能遇到软故障场景。
并不是所有的失败都会导致代码崩溃，但是避免崩溃是容错系统更可用的一个重要原因。
高可用性
确保您的软件可供使用，这意味着当其他人也在使用该系统时，用户不应感到不便。这与系统的运行成本及其可用性有着直接的关系。很简单，它的成本更高，普遍可用。
要成为可用的，意味着当代码控制之外的事情导致问题时，您需要紧急情况：
- 如何扩展我的应用程序？
- 我能以多快的速度扩展应用程序？
- 当我的数据中心不可用时会发生什么？
- 当网络饱和时会发生什么？
- 如果我的数据中心是灾难的受害者，我该如何回应(自然灾害和战争会导致你不得不改变数据中心)
- 这要花我多少钱？
你可以开始明白为什么微服务和云是互联网工程的关键组成部分。这样做的想法是，与扩展(更多CPU和RAM)相比，您可以更快、更便宜地扩展(更多实例)。此外，当交通高峰结束时，你也可以很容易地缩小流量，以便在交通较慢的时候节省一些钱。
当然，您也需要为此设计。这可能需要处理数据分区、多区域部署、多可用性区域冗余等。当然，如果这是在用户的硬件(即桌面应用程序)上运行，那么您可能需要交换内存中的模块，这取决于您是否使用它们。
结束游戏
您需要这两个学科来设计一些能够随着应用程序需求的增长而顺利扩展的东西。您必须开始最好地猜测您现在最可能面临的适当问题，然后在应用程序运行时监视它。这将向您显示您当前的设计在哪里有一个困难的时间跟上需求，可靠。
我向你保证，人们期望依赖的大型系统中没有一个是从现在开始的。你可以看看Twitter，Facebook，Airbnb，Netflix，甚至这个网站，发现它们各自的架构是不同的，尽管它们有一些共同之处。这是因为使用这些系统的不同方式需要不同的定制。更能说明问题的是他们是如何到达那里的。我们中的大多数人都不会像互联网上那些大牌公司那样设计出这么大的东西，但是我们可以从他们所做的决定中学习，并在较小的范围内应用它。
https://softwareengineering.stackexchange.com/questions/403064
复制相似问题
腾讯云开发者
