Zookeeper分布式一致性原理(一):分布式架构

分布式一致性问题

在分布式系统中一个需要解决的重要问题就是数据的复制问题。分布式系统对于数据复制需求一般都来自以下两个原因:

  • 为了提高系统地可用性,以防止单点故障引起的系统不可用。
  • 提高系统地整体性能,通过负载均衡技术,能够让分布在不同地方的数据副本都能够为用户提供服务

数据一致性就是指对一个数据副本进行更新的时候,必须能够更新其他的副本,否则副本之间的数据就将不一致。然而副本之间的数据不一致就引来了分布式一致性问题。

分布式一致性问题,是指在分布式系统中引入数据复制之后,不同数据节点间可能出现,并无法依靠计算机应用程序自身解决的数据不一致情况。

那么如何来解决这个问题呢?由于数据副本复制延迟的问题,不同数据节点的数据副本可能不一致。针对这个问题,有人就提出了:

既然是由于延迟引起的问题,那么我们就可以将写入数据的动作进行阻塞,直到数据复制完成之后,才能执行写入操作。

总的来说,我们无法找到一种能够满足分布式系统所有属性的一致性解决方案。因此,如何保证数据的一致性,同时又不影响系统运行的性能,是每一个分布式系统都需要重要考虑和权衡的。

  1. 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来就是什么。但是这种一致性很难达到。
  2. 弱一致性:这种一致性级别约束了系统写入数据成功之后,不承认可以立即读取数据写入的值,也不具体承若多久之后能够得到数据的值。
    • 会话一致性:这种一致性级别只保证写入的值,在同一个客户端会话中可以立即读到一致性的值,但是其他的会话不能保证。
    • 用户一致性:该一致性级别只能保证对于写入的值,在同一个用户中可以立即读到一致性的值,但其他用户不能保证。

最终一致性:最终一致性是弱一致性的一种特例,系统会保证在一定时间内,能够达到一致性数据的状态。

1. 从集中式到分布式系统

1.1 集中式的特点

所谓的集中式系统,就是指的是一台或者多台计算机组成的中心节点,数据集中存储到这个中心节点中,并且系统地所有业务单元都集中在部署这个中心节点上,系统地所有功能均由这个中心节点处理。

1.2 分布式的特点

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

一个标准的分布式系统包含如下几个特征:

  • 分布式:分布式系统中的多台计算机都是在空间上随意分布,同时机器的分布情况随时变动。
  • 对等性:分布式系统中的计算机没有主从之分。 副本(Replica)是分布式系统个最常见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。 数据副本是指在不同节点上持久化同一份数据,当某一个节点数据存储丢失时,可以从副本上读取到该数据,这是解决数据丢失的有效方式。
  • 缺乏全局时钟:在分布式系统中,系统通信通过消息,所以很难定义两个事件究竟是谁先谁后,原因就是分布式系统缺乏全局时钟列控制。
  • 故障总是会发生:组成分布式系统的所有计算机,都有可能发生任何形式的故障。

1.3 分布式系统中存在的问题

  1. 通信异常
  2. 网络分区
  3. 消息投递的成功、失败、超时问题。
  4. 节点故障

2. 事务

事务指的就是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元(Unit),狭义上就是指的数据库服务。

2.1 ACID

事务的四大特性 原子性 Atomicity、一致性 Consistency 、隔离性 Isolation、持久性 Durability

原子性

事务的原子性是指事务必须是一个院子的操作序列单元,事务包含的各项操作在一次执行过程中,只允许存在以下两个状态之一:

  • 全部成功执行
  • 全部不执行

一致性

事务的一致性是指事务的执行不能破坏数据的完整性和一致性。 比如 数据库运行过程中出现故障,一个正在运行的事务,部分写入数据修改了数据库,导致数据库出现不一致

隔离性

在并发环境中,一个事务的执行不能被其他事务干扰。 即 一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的哥哥事务之间不能相互干扰。

在标准SQL规范中,定义了4个事务隔离级别,不能的隔离级别对事务的影响不同。

在数据库事务中,定义了4种并发级别:

  • Read_Uncommit
  • Read_Commit
  • Repetable_Read
  • Serializable

3. 分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

分布式事务可以被定义为一种嵌套型的事务,同时也具有了ACID事务特性。但是由于是在分布式系统中,各个子事务的执行时分布式的。因此未来实现分布式事务ACID是很复杂的。

3.1 CAP理论

CAP理论告诉我们,一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Avaliability)和分区容错性(P: partition tolerance)这三个基本需求,最多只能满足其中两项。

Zookeeper分布式一致性原理(一):分布式架构

一致性(Consistency)

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

可用性(Avaliability)

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

容错性(P: partition tolerance)

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

Zookeeper分布式一致性原理(一):分布式架构

3.2 BASE理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)

基本可用(Basically Available)

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

  • 响应时间上的损失。
  • 功能上的损失:电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务

软状态( Soft State)

软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

最终一致性( Eventual Consistency)

最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

  • 因果一致性:如果进程A在更新完某个数据项后通知了进程B,那么进程B之后对该数据项的访问都应该能够获得进程A更新后的最新值。
  • 读己所写一致性:进程A更新了一个数据项之后,它总能是能够访问到数据更新过的最新值。
  • 会话一致性:对系统数据的访问过程框定到了一个会话中:系统能够保证在同一个会话中的实现数据一致性。
  • 单调读一致性:一个进程从系统中读取一个数据项的某个值后,那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
  • 单调写一致性:一个系统能够保证来自同一个进程的写操作被顺序执行。