分布式系统

分布式与集中式

集中式的特点

所谓的集中式系统就是指有一台或多台主计算机组成中心节点,数据集中存储于这个中心节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均有其集中处理。每个终端或客户端机器仅仅负责数据的录入和输出,而数据的存储与控制完全交给主机来完成。

很鲜明的特点就是部署的结构简单,由于集中式系往往基于底层性能卓越的大型主机,因此无须考虑如何对服务进行多个节点的部署,也不用考虑多个结点之间的分布式协作问题。

分布式的特点

同一个分布式系统中的计算机在空间部署上是可以随意分布的,这些计算机可能被放在不同的机柜里,也可能在不同的机房中,甚至分布在不同的城市。无论如何一个标准的分布式系统在没有任何特定业务逻辑约束的情况下,都会有如下几个特征 :

分布性

分布式系统中多台计算机都会在空间上随意分布,同时机器的分布情况也会随时变动。

对等性

分布式系统的计算机没有主从之分。副本(Replica)是分布式系统最常见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。数据副本是指在不同的及诶单上持久化同一份数据,当某一个结点在存储的数据丢失时,可以从副本上读取到该数据。这是解决分布式系统数据丢失问题最有有效的手段。另一类副本是服务副本,之多个结点提供同样的服务,每个节点都有能力接受来自外部的请求并进行相应的处理。

并发性

在一个分布式系统中的多个节点,可能会并发操作一些共享的资源,注入数据库或分布式存储等。

缺乏全局时钟

一个典型的分布式系统是由一系列在空间爱你上随意分布的多个进程组成的,具有明显的分布性,这些进程之间通过交换信息来进行通信。因此在分布式系统中,很难定义两个时间究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的始终序列控制。

故障总是会发生

组成分布式系统的所有计算机,都有可能发生任何形式的故障。一个被大量工程时间所检验的黄金定理:任何在设计阶段考虑的异常情况,一定会在系统实际运行中发生,并且,在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障,所以,除非需求指标允许,在系统设计时不能放过任何异常情况。

分布式环境的各种问题

通信异常

在集中式向分布式演变的过程中,必然引入了网络因素,而由于网络本身的不可靠性,因此引入了额外的问题。分布式系统需要在各个节点进行网络通信,因此每次网络通信都会伴随着网络不可用的风险,网络光纤,路由器或是 DNS 等硬件设备或是系统不可用都会导致分布式系统无法顺利完成一次通信。需要特别注意的是,单机内存访问的延时在纳秒数量级(通常是 10ns 左右),而正常的一次网络通信的延迟在0.1-1ms左右(相当于内存访问延时的105-106倍)。

网络分区

当网络由于发生异常情况,导致分布式系统中部分结点之间网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分结点之间能够进行正常通信,而另一些结点则不能,这种情况成为网络分区,俗称“脑裂”。脑裂会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能。

三态

三态指的是成功、失败与超时。传统单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应:成功与失败。在分布式系统中,由于网络是不可靠的,在网络出现的异常情况下,除了成功和失败,还可能出现超市现象:

  • 由于网络原因,该消息没有成功发送到请求方,而是在发送过程就发生了消息丢失现象
  • 该消息成功被接收方接收后,并进行了处理,但是在响应反馈给发送方的过程中,发生了消息丢失。

当出现这样的超时现象,网络通信的发起方是无法确定当前请求是否成功处理的。

结点故障

结点故障是分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器结点出现的宕机或 “僵死” 现象。

从 ACID 到 CAP/BASE

ACID事务指的是原子性、一致性、隔离性、持久性,在 数据库原理 中已经分析过,这里主要看分布式系统事务处理 CAP/BASE

CAP定理

一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition toleance)这三个基本需求,最多只能同时满足其中的两项

一致性

在分布式环境中,一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下,当一个系统在数据一致的情况下执行更新操作后,应该保证系统的数据仍然处于一致的状态。

可用性

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。

“有限的时间内”是指对于用户的一个操作请求,系统必须能够在指定的时间内返回对应的处理结果,如果超过了这个时间范围,那么系统能够被认为是不可用的。这个“有限的时间”是系统设计之初就设定好的指标,不同的系统会有很大的不同。

“返回结果”是可用性的另一个非常重要的指标,他要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能明确反映出对请求的处理结果,即成功和失败。

分区容错性

分区容错性约束了一个分布式系统需要具有如下特性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性服务,除非是整个系统环境都发生了故障。

1.png

放弃CAP定理 说明
放弃P 如果希望能够避免系统出现分区容错性问题,一种较为就简单的做法是将所有的数据都放在一个分布式结点上,这样的做法虽然无法100%保证不会出错,但至少不会碰到由于网络分区带来的负面影响。但是放弃P的同事也就意味着放弃了系统的可扩展性
放弃A 放弃可用性做法是一旦系统遇到网络分区或其他故障时,那么受到影响的服务需要等待一定的时间,因此在等待期间系统无法对外提供正常的服务,即不可用
放弃C 放弃一致性,并不是完全不需要数据一致性,放弃一致性指的是放弃数据的强一致性(强一致性是在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到最新的值,那么这样的系统被认为具有强一致性),保留数据的最终一致性、这样的系统无法保证数据保持实时的一致性,但是能够承诺的是,数据最终会达到一个一致的状态,这就引入了一个时间窗口的概念,具体多久能够达到数据一致性取决于系统的设计。

BASE理论

BASE 是基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)三个短语的缩写。

BASE 理论是对 CAP 中一致性和可用性权衡的结果,它的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

基本可用

指分布式系统在出现故障的时候,保证核心可用,允许损失部分可用性。

例如,电商在做促销时,为了保证购物系统的稳定性,部分消费者可能会被引导到一个降级的页面。

软状态

指允许系统中的数据存在中间状态,并认为该中间状态不会影响系统整体可用性,即允许系统不同节点的数据副本之间进行同步的过程存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能达到一致的状态。

在实际工程实践中,最终一致性存在以下五类主要变种

因果一致性

如果进程A在更新完某个数据项后通知了进程B,那么B之后对该数据项的访问都应该能够获取到进程A更新后的最新值,并且如果进程B要对该数据项操作更新的话,务必基于进程A更新后的最新值。与此同时,与进程A无因果关系的进程C的数据访问则没有这样的限制

知己之所写

进程A更新一个数据项后,他自己总是能够访问到更新后的最新值,而不会看到旧址,也就是说,对于单个数据获取者来说,其读取到的数据,一定不会比自己上次写入的值旧。

会话一致性

会话一致性将对系统数据访问过程框定在一个会话当中:系统能保证在同一个有效的会话中实现“知己之所写”的一致性,也就是说,执行更新操作之后,客户端能够在一个会话中读取到该数据项的最新值。

单调读一致性

单调读一致性是如果一个进程从系统中读取一个数据项的某个值后,那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

单调写一致性

一个系统需要能够保证来自同一个进程的写操作被顺序的执行。




最终一致性并不是只有那些大型分布式系统才涉及的特性,许多现代的关系型数据库都采用了最终一致性。

BASE理论面向的是大型高可用可扩展的分布式系统,和传统事务的ACID特性是相反的,他完全不同于ACID的强一致性模型,而是提出通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到抑制状态。在实际的分布式场景中,不同业务单元和组件对一致性的要求是不同的,因此 ACID 和 BASE 往往会结合在一起使用。

本篇主要介绍分布式系统和集中式系统之间的关系与区别、分布式系统的常见问题以及分布式系统事务管理中的CAP定理,通过放弃CAP其中一项来达成一种权衡,即BASE理论。

参考资料

  • 从 Paxos 到 ZooKeeper 分布式一致性原理与实践.倪超.电子工业出版社