系统设计与实践（二） GeekBand

分布式系统

分布式系统基础重要要点

1. 对外提供无状态节点，内部实现具体有状态或者无状态节点逻辑，节点即可以是提供服务，也可以是存储数据。
2. 拜占庭问题，在分布式系统中的使用，目的是保证服务可用，而不是找出错误的节点，如果。
3. 异常常见情况，机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP。可能是收到消息后宕机、也可能是处理完成以后机器宕机、处理完成任务后发送确认消息是网络异常。也有可能是发出去的消息丢失，或者发送确认消息时丢失。可能先发送出去的数据后收到。
4. 分布式状态、成功、失败、超时。超时的情况，不能判断是否成功，原有同上。
5. 数据存储在机械硬盘上，随时有可能发生异常，导致数据没有能正确存储。
6. 无法归类的异常，比如，系统的处理能力时高、时低，的诡异行为。
7. 即使是小概率事件，在每天百万、千万、及以上的运算量时也会上升为大概率事件。
8. 副本提高数据的冗余，提高系统的可用性，但是在使用副本代来好处的同时，也导致维护副本需要成本。如副本的一致性，多个副本一致性，多个副本直接可能到不一致。
9. 一致性级别：强一致性、单调一致性，读取最新数据、会话一致性，通过版本读取统一值。最终一致性、弱一致性。

机器宕机

机器宕机是最常见的异常之一。在大型集群中每日宕机发生的概率为千分之一左右。在实践中，一台宕机的机器恢复的时间通常认为是24小时，一般需要人工介入重启机器。宕机造成的后果通常为该机器上节点不能正常工作。假设节点的工作流程是三个独立原子的步骤，宕机造成的后果是节点可能在处理完某个步骤后不再继续处理后续步骤。

当发生宕机时，节点无法进入正常工作的状态，称之为“不可用”(unavailable)状态。机器重启后，机器上的节点可以重新启动，但节点将失去所有的内存信息。在某些分布式系统中，节点可以通过读取本地存储设备中的信息或通过读取其他节点数据的方式恢复内存信息，从而恢复到某一宕机前的状态，进而重新进入正常工作状态、即“可用”(available)状态。而另一些分布式系统中的某些无状态节点则无需读取读取任何信息就可以立刻重新“可用”。使得节点在宕机后从“不可用”到“可用”的过程称为宕机恢复。

分布式系统的三态

由于网络异常的存在，分布式系统中请求结果存在“三态”的概念。在单机系统中，我们调用一个函数实现一个功能，则这个函数要么成功、要么失败，只要不发生宕机其执行的结果是确定的。然而在分布式系统中，如果某个节点向另一个节点发起RPC(Remote procedure call)调用，即某个节点A向另一个节点B发送一个消息，节点B根据收到的消息内容完成某些操作，并将操作的结果通过另一个消息返回给节点A，那么这个RPC执行的结果有三种状态：“成功”、“失败”、“超时（未知）”，称之为分布式系统的三态。

如果请求RPC的节点A收到了执行RPC的节点B返回的消息，并且消息中说明执行成功，则该RPC的结果为“成功”。如果请求RPC的节点A收到了执行RPC的节点B返回的消息，并且消息中说明执行失败，则该RPC的结果为“失败”。但是，如果请求RPC的节点A在给定的时间内没有收到执行RPC的节点B返回的消息，则认为该操作“超时”。对于超时的请求，我们无法获知该请求是否被节点B成功执行了。这是因为，如果超时是由于节点A发向节点B的请求消息丢失造成的，则该操作肯定没有被节点B成功执行；但如果节点A成功的向节点B发送了请求消息，且节点B也成功的执行了该请求，但节点B发向节点A的结果消息被网络丢失了或者节点B在执行完该操作后立刻宕机没有能够发出结果消息，从而造成从节点A看来请求超时。所以一旦发生超时，请求方是无法获知RPC的执行结果的。

异常

被大量工程实践所检验过的异常处理黄金原则是：任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非需求指标允许，在系统设计时不能放过任何异常情况。

工程中常常容易出问题的一种思路是认为某种异常出现的概率非常小以至于可以忽略不计。这种思路的错误在于只注意到了单次异常事件发生的概率，而忽略了样本的大小。即使单次异常概率非常小，由于系统规模和运行时间的作用，事件样本将是一个非常大的值，从而使得异常事件实际发生的概率变大。

副本

副本（replica/copy）指在分布式系统中为数据或服务提供的冗余。对于数据副本指在不同的节点上持久化同一份数据，当出现某一个节点的存储的数据丢失时，可以从副本上读到数据。数据副本是分布式系统解决数据丢失异常的唯一手段。另一类副本是服务副本，指数个节点提供某种相同的服务，这种服务一般并不依赖于节点的本地存储，其所需数据一般来自其他节点。
例如，GFS系统的同一个chunk的数个副本就是典型的数据副本，而Map Reduce系统的Job Worker则是典型的服务副本。

副本一致性

分布式系统通过副本控制协议，使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相同，称之为副本一致性(consistency)。副本一致性是针对分布式系统而言的，不是针对某一个副本而言。

例1.3：某系统有3副本，某次更新数据完成了其中2个副本的更新，第3个副本由于异常而更新失败，此时仅有2个副本的数据是一致的，但该系统通过副本协议使得外部用户始终只读更新成功的第1、2个副本，不读第3个副本，从而对于外部用户而言，其独到的数据始终是一致的。

依据一致性的强弱即约束条件的不同苛刻程度，副本一致性分为若干变种或者级别：

• 强一致性(strong consistency)：任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。强一致性是程度最高的一致性要求，也是实践中最难以实现的一致性。

• 单调一致性(monotonic consistency)：任何时刻，任何用户一旦读到某个数据在某次更新后的值，这个用户不会再读到比这个值更旧的值。单调一致性是弱于强一致性却非常实用的一种一致性级别。因为通常来说，用户只关心从己方视角观察到的一致性，而不会关注其他用户的一致性情况。

• 会话一致性(session consistency)：任何用户在某一次会话内一旦读到某个数据在某次更新后的值，这个用户在这次会话过程中不会再读到比这个值更旧的值。会话一致性通过引入会话的概念，在单调一致性的基础上进一步放松约束，会话一致性只保证单个用户单次会话内数据的单调修改，对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。实践中有许多机制正好对应会话的概念，例如php中的session概念。可以将数据版本号等信息保存在session中，读取数据时验证副本的版本号，只读取版本号大于等于session中版本号的副本，从而实现会话一致性。

• 最终一致性(eventual consistency)：最终一致性要求一旦更新成功，各个副本上的数据最终将达到完全一致的状态，但达到完全一致状态所需要的时间不能保障。对于最终一致性系统而言，一个用户只要始终读取某一个副本的数据，则可以实现类似单调一致性的效果，但一旦用户更换读取的副本，则无法保障任何一致性。

• 弱一致性(week consistency)：一旦某个更新成功，用户无法在一个确定时间内读到这次更新的值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。弱一致性系统一般很难在实际中使用，使用弱一致性系统需要应用方做更多的工作从而使得系统可用。