质量属性--可用性

本篇阅读笔记的主要内容是：

1.可用性的要求

2.可用性的实际需求，在不同阶段的不同战术

3.可用性战术的实际案例，我能想到的

可用性是系统能够正常运行的时间比例，由此得出可用性的计算公式是

可用性=平均工作时间/（平均正常工作时间+平均修复时间）

在书中提出了错误和故障的的观点，也就是错误如果在未被观察的情况下被修复那么可以不成做故障，由此我想到了，可用性的标准就是，尽可能的降低修复bug所使用的时间，所谓的可用性的战术应该有部分是使用在这个部分。

往后看书，确实如此，书中提出的可用性的实际需求，我觉得最重要的一点是，将错误的影响局限在一定的范围内，至少能够把错误的影响限制在一定的范围内，从而使修复成为可能。

可用性的战术一般分为三个阶段，即错误的检测，错误的修复，和错误的预防

在错误的检测方面可用性的战术有三点：

1.命令/响应，这个指的是一方发出消息，另一方接受以后回复收到信息，类似于信息交换的三次握手协议，看到这个我最先想到的是http的三次握手传递信息，而所谓的层级结构在搭建pt模拟器的网络的时候也会用到向同级的设备发送信息确保搭建成功，给我的感觉使用的也是这个原理

2.心跳 心跳，我感觉，证明一下组件还在正常运行并且传递一些信息，类似于定期开会？？？

3.异常，这个在代码中还是很常见的，使用try catch捕捉异常，并且使用finally处理常见的异常。

命令/响应和心跳指的是组件和组件之间的交互，而异常一般是单个组件内部的异常措施。

接下来是在错误的恢复方面的战术，这里我到目前还全部理解，就将我理解的几点用自己的语言表述出来：

1.表决，在多台处理机的情况下使用，为了确保是否有程序或者处理机出现错误，当有某台处理机的输出结果不正确的时候，就可以据此推断是否有某台机器或者算法出现了问题，一般的表决采用的算法是“多数规则”或者“首选组件”的算法，即是说采用某台处理机优先或者少数服从多数的原则。对应的战术实例...暂时还没想到有什么实例是我曾经用到的。

2.主动冗余（热重启），多程序并发进行，切换时间很少， 发送者和接收者为了确保进程的同步，要采用可靠的信息传输协议。当发生错误的时候可以抛弃错误组件的信息，所消耗的时间紧紧是切换组件的内容的时间，适合用于需要及时响应的系统中，例如在课本中提出的数据库管理系统（没搜...没懂）

3.被动冗余（暖重启/双冗余/三冗余），组件分为主要和备用组件，周期性的切换组件可以提高整体系统的可用性，被动切换组件的主要和备用关系，可以是由备用组件决定，也可以是由其余的组件决定。

4.备件 ，备用件是由计算平台配置的用于更换不同故障的组件。有点类似于，电池？出现故障的适合可以及时的进行更换，然后对其进行更换之后就可以正常运行。

书中在这个部分将战术进行了分隔，接下来的战术主要是组件重新引入，那么上述的算什么，大概，是冗余组件的组合和切换？

组件的重新引入书中介绍了三个战术：1.shadow操作，为了保证恢复该组件之前，模仿工作组件的行为。2.状态再同步，组件状态的及时更新，为了适应系统所以出现的，应尽可能简短的描述信息，确保组件的状态更新 3.检查点/回滚，方便系统的定期修复和排查错误，回到一致状态。