分布式架构了解篇

无论你是不是一名合格的码农，你都应该对分布式架构有一定的了解。在了解分布式架构之前，先来了解下集中式架构。自20世纪60年代大型主机被发明出来之后，凭借其超强的计算和IO处理能力以及在稳定性和安全性方面的卓越表现，在很长的一段时间里引领了计算机行业的发展。
伴随着大型主机的发展，集中式的计算机系统架构也称为了主流，由于依靠大型主机卓越的性能和良好的稳定性，集中式单机处理能力的优势非常明显。但是在20世界80年代后期，随着计算机网路化和微型化的发展趋势，集中式的处理模式越来越显得捉襟见肘。也是在那个时期，计算机系统经历着一场从集中式到分布式架构的变革。

集中式的特点

集中式系统是指由一台或者多台主计算机组成中心节点，数据集中存储在这个中心节点上。并且整个系统的业务处理也都集中在这个中心节点上，系统的所有功能均由其集中处理。这种系统架构最大的特点就是部署起来非常简单，基本只需要一次部署。

分布式的特点

分布式系统是一个硬件或软件组建分布在不同的网络计算机上，彼此之间紧紧通过消息传递进行通信和协调的系统。《分布式系统概念和设计》

通过上面这个概念，我们可以了解到分布式系统的几个明显的特征：分布性，对等性，并发性。

• 分布性
  分布式系统的多台计算机节点在空间上是随意分布的，并且空间位置是随时变化的。
• 对等性
  分布式系统的多台计算机节点之间没有主从之分，比较常见的概念是副本，指的是分布式系统会对数据和服务进行冗余处理。
• 并发性
  在分布式系统中，并发操作时非常常见的，比如数据库资源或者分布式存储等。

分布式系统典型常见问题

通信异常

由于分布式系统的各个节点在空间上是可任意分布的，相互之间的沟通只能靠网络进行通信，而网络通信的不确定性又非常的大。在一次网络通信中，路由器、DNS、物理传输媒介等等，任何一个缓解出现问题都会导致此次网络通信失败。

网络分区(脑裂)

在网路通信出现异常的情况下，可能会出现一部分节点无法对外提供服务，只有部分节点能正常工作，这样就会出现一个小的服务集群，及时在这种情况下，也要保证对外提供的服务的正确性，挑战较大。

三态

在集中式处理模式下，一个操作要么成功，要么失败，结果非常清晰，但是在分布式环境中，由于沟通是靠网络传递信息的，在传递的过程中存在消息超时现象。所以就会出现一种不确定的状态，即为第三种状态。

分布式事务

ACID

熟悉事务操作的一定知道事务的ACID特性，下面简单介绍下A(Atomicity)、C(Consistency)、I(Isolation)、D(Durability)各自的含义。

• 原子性(Atomicity)是指一个事务要么全部执行,要么不执行.也就是说一个事务不可能只执行了一半就停止了.比如你从取款机取钱,这个事务可以分成两个步骤:1划卡,2出钱.不可能划了卡,而钱却没出来.这两步必须同时完成.要么就不完成.
• 一致性(Consistency)是指事务的运行并不改变数据库中数据的一致性.例如,完整性约束了a+b=10,一个事务改变了a,那么b也应该随之改变.
• 独立性(Isolation）:事务的独立性也有称作隔离性,是指两个以上的事务不会出现交错执行的状态.因为这样可能会导致数据不一致.
• 持久性(Durability）:事务的持久性是指事务执行成功以后,该事务所对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚.

在标准的SQL规范中，定义了四种事务隔离级别，由低到高依次为Read uncommitted(读未提交)、Read committed(读已提交)、Repeatable read(重复读)、Serializable(序列化)。下图展示了各个级别之间的区别。

screenshot

分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上，通常一个分布式事务中会涉及对多个数据资源或者业务系统的操作。经典的跨银行转账操作，这个操作会调用两个异地的银行服务，其中一个提供的取款服务，另外一个提供的存款服务，这两个服务本身是无状态的且相互独立的，两个服务操作共同构成了一个完整的分布式事务。由此也可以看出，由于在分布式事务中，各个子事务的执行时分布式的，因此相比较于集中式的满足ACID特性的分布式事务系统就异常复杂。

CAP原则

2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！CAP简单概括如下，下图展示了CAP猜想示意图。

• C（一致性）：所有的节点上的数据时刻保持同步
• A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
• P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

screenshot

高可用、数据一致是很多系统设计的目标，但是分区又是不可避免的事情, 一个分布式系统无法同时满足CAP三个特性，那么我门就来看看放弃其中一项的场景说明.

• CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
• CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
• AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

BASE理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

• 基本可用（Basically Available）
  基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
  电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
• 软状态（ Soft State）
  软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
• 最终一致性（ Eventual Consistency）
  最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。