总结：服务等级协议、分布式系统指标、CAP定理

服务等级协议（SLA）

SLA是服务提供者对客户的一个服务承诺，是衡量分布式系统是否“健康”的常见方法，无论我们服务的是内部用户，还是外部用户，我们都应该给自己的设计的系统定义好一个SLA。因为SLA是一个承诺，所以指标可以多样。常用的指标有以下四种：可用性、准确性、系统容量、延迟

可用性

• 可用性是指系统正常运行的时间占比（几乎不可能构建一个100%的系统，所以量力承诺）
• 对于许多系统能够做到4个9，就能被称为高可用了（每年50分钟、一天86秒的系统中断）

准确性

• 准确性是指是否允某些数据数不准确的或者丢失的，用户的接受的概率是多少
• 通常用错误率衡量（单位时间窗口：系统内部错误导致的无效请求/有效的请求数）
• 准确性评估一般采用：性能测试 或者 统计系统错误日志，两种评估方法

系统容量

• 容量是指系统预期负载量是多少，一般以秒为单位（QPS）

延迟

• 延迟指系统收到请求到响应的时间间隔
• 定义延迟指标时通常采用p95或者p99
• RT包括：网络损耗 + 系统处理两部分

分布式系统指标

前面提到用SLA评估分布式系统，下面说下分布式系统的另外几个指标：可扩展性、一致性、持久性

• 可扩展性
  可扩展性是分布式系统的核心，数据越来越大（ GB->TB->PB）单机已无法处理
  工作中也常碰到这样的场景，之前设计的系统无法处理日渐增长的负载。这时，我们需要增加系统容量。最常见的扩容模型有两种：水平扩展 和 垂直扩展

水平扩展，就是在现有系统增加机器节点
在日常运维中水平扩展操作简单，并且保证了系统的可用性，但是无节制增加机器数量也会带来问题，比如：机器管理、调度、通信会更复杂，出错的可能性会更高，更难保证数据一致性

垂直扩展，就是在不改变系统节点数量的情况下，“升级”单机性能，如：内存
垂直扩展没有让整个系统变得复杂，控制系统不需要做调整，但是限制比较多。多数情况下，单个机器的性能提升是有限的。受摩尔定律限制，提供机器性能要比购买机器更昂贵

• 一致性

可用性对于分布式系统很重要。一般来说，构建分布式系统节点的可用性要低于系统的可用性，举个例子：如果我们要构建一个99.999的分布式系统（每年5分钟的中断时间），但是我们使用的单机节点的可用性是99.99（每年约8个小时的宕机时间）。那么要想达成目标就是加机器，这样即使部分节点宕机了系统是可用的。

这种情况下我们就要思考一个问题：如何保证系统中的不同节点在同一时间，接收和输出的数据一致性呢？这时就引入了一致性的概念

回到刚才的例子，要保证分布式系统内机器节点有相同的配置，就需要机器之间定期同步。

然而，信息发送有失败的可能，比如信息丢失或者节点正好宕机无法接收。因此，一致性在高可用的系统里是非常核心的概念。

常用的一致性模型：强一致性、弱一致性、最终一致性

• 强一致性：系统中数据被成功更新后，后续任何对该数据的读取操作都是更新后的最新值。所以，任意时刻，同一系统的节点数据是一样的

• 弱一致性：系统中的数据被成功更新后，后面对该数据的读取操作可能读到的是更新后的值，也可能是更改前的值。但经过“不一致的时间窗口”这段时间后，后续对该数据的读取是更新后的值

• 最终一致性：是弱一致性的特殊形式。存储系统保证，在没有新的更新条件下，最终所有的访问都是最后更新的值

强一致性系统中只要数据更新，这个数据的副本都要同步更新，以保证这个更新被传播到所有备份中。在这个过程结束后，才允许其他服务来读取这个数据。所以，强一致性会牺牲延迟指标，并且对全局时钟的要求非常高。

在最终一致性系统中，我们无需等到数据更新被所有节点同步就可以读取。尽管不同的进程读取的数据可能不一致，但是最终所有的更新都会按时间顺序同步到所有的节点。所以，最终一致性系统支持异步读取，他的延迟比较小

在实际系统中，强一致性是很难实现的，应用最广的是最终一致性

• 持久性

数据持久性意味着数据一旦被成功存储就可以一直使用，及时系统节点下线、宕机或数据损坏也是如此

不同的分布式数据库拥有不同级别的持久性。有些系统支持节点级别的持久性，有些做到了集群级别，而有些系统压根没有持久性

想要提高持久性，数据复制是较为通用的做法。把同一份存储到不同的节点上，及时有节点无法连接，数据仍然可以被访问

在分布式系统中还有一个持久性概念“消息持久性”。在分布式系统中，节点之间需要经常相互发送消息去保证一致性。对于重要的系统而言，常常不允许任何消息丢失

CAP定理

前面提到两个重要概念：可用性和一致性，这里说说与这两个概念相关，并且在设计分布式系统时都会讨论的CAP定理（三选二，架构师必须学会取舍）

C属性：一致性

一致性这里指的是线性一致性。在线性一致性的保证下，所有分布式环境下的操作都像是在单机上完成一样，也就是说图中ServerA、B、C的状态一直是一致

打个比方，现在有两个操作，A和B，需要在一个分布式系统上完成：

我们假设A作用在系统上的时候，所看见的所有系统状态叫做状态A，而操作B作用在系统上的时候，所看见的所有系统状态叫做状态B

如果操作A在操作B之前发生的，并且A操作成功，那么系统状态B必须要比系统状态A更加新

举例：购物车系统

A属性：可用性

在分布式系统中，任意非故障节点都必须用用户请求做出响应。

当系统满足可用性的时候，只要系统还有一个节点未崩溃，那么这个节点必须最终响应客户端

P属性：分区容错

分区容错性要拆开两个维度看：“分区”和“容错”

在一个分布式系统里，由于某些故障会导致部分节点无法连通，这就造成整个网络分成几块区域，从而使数据分散在这些无法连通的区域中，这就发生了分区错误

如图，如果数据只能存储在Server A，当系统出现分区错误时，不能直接连接Server A时，是无法获取数据的。我们要“分区容错”，即使出现这样的“错误”系统也要能“容忍”。也就是说，即使系统错误也必须能够返回消息

分区容错性，在这里指的是我们系统允许网络丢失从一个节点发送到另一节点的任意多条消息

在现实系统中节点故障和网络丢包是不可避免的，如果不允许分区容错的话，我们的系统就不再继续工作了（举例：审核平台中分区容错的例子？）

所以，大部分情况下，系统设计会保留P，然后在A和C中二选一（举例：哪个中间件产品放弃了P？）