阅读 55

Zookeeper分布式一致性原理与实践(一)

分布式架构

集中式架构的特点

有一台或者多台计算机组成中心节点,数据的存储和处理能力都放在了这个中心节点。所以集中式的特点是部署结构简单,无需考虑多节点的协作问题。

分布式结构的特点

分布式系统是一个硬件或者软件分布在不同的网络的计算机上,这个定义包含了几乎所有有效的部署上是可以所以分布的。标准的分布式系统在没有任何特定业务逻辑约束的情况下,有如下几个特征。

  1. 分布性

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

  2. 对等性

    分布式系统的计算机没有主/从之分,既么诶有控制真个系统的主机,也没有被控制的从机,组成分布式系统的索引计算机节点都是对等。副本是(replica)是分布式系统的最常见的概念之一,指的设计分布式系统对数据和服务提供的一种冗余方式。一般的分布式系统都需要高可用,需要对数据和服务提供副本的冗余。数据副本是指在不同的节点上持久化同一份数据,当数据丢失时可以从副本上读取数据,服务副本是指多个节点提供了同样的服务,每个节点都有能力接收来自外部的请求并进行相应的处理。

  3. 并发性

    在一个计算机网络中,程序运行过程中的并发是指多个分布式系统节点可以并发的操作一些共享的资源。

  4. 缺乏全局时钟

    分布式系统的分布特性使得服务之间的通信只能通过消息的交换来实现。因此在分布式系统中很难定义谁先谁,原因是缺乏一个全局的时钟序列控制。

  5. 故障总是会发生的

    组成分布式系统的所有计算机,都有可能发生任何形式的故障。

分布式的问题

  1. 通信异常

    从集中到分布的过程就必然会引起网络的因素,由于网络本身的不可靠也额外的引入了这个问题。

  2. 网络分

    分布式的节点之间的网络问题就引起了部分节点之间无法通信,而部分节点是可以通信的,这个现象称为网络分区,俗称为"脑裂"。在极端的情况下这些集群可以完成原本小整个分布式系统才能完成的功能,包括对数据的事务处理,这也需要对一致性提出更高的要求。

  3. 三态

    "三态"既网络请求成功,失败或者超时。传统的服务中调用一个方法会得到一个明确的答案,但是分布式系统中由于网络的不可靠就无法及时的做出响应,导致出现了超时的现象,主要的有一下两种情况。

     1. 网络原因消息没有发到接收方,发起的过程就消息丢失了
     
     2. 该消息成功的被接收方接收后,并进行了处理,但是在响应反馈的给发送方的过程中,发生了消息的丢失
    复制代码
  4. 节点故障

    节点故障时分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现宕机或者"僵死"现象,每个节点都可能会出现这种情况.

ACID到CAP/BASE

事务具备了四大特征,分别是原子性(Atomicity),一致性(Consistency),隔离性(Isolation)和持久性(Duability)。

原子性

事务的原子性是指事务必须是一个院子的操作序列单元。事务中包含了各项操作在一次执行过程中的,只允许出现以下两个状态:1.全部成功执行2.全部不执行。
复制代码

一致性

事务的执行是指事务执行不能破坏数据库的完整性和一致性,一个事务在执行之前和之后,数据必须从一个状态到另一个状态,因此数据库当数据库包含成功事务提交的结果是,就是数据库处于一致性状态。
复制代码

隔离性

事务的隔离性是指并发环境中,并发的事务是相互隔离的,一个事务的执行不能被其他事务干扰。标准的SQL规范中定义了4种事务隔离级别,不同的隔离界别对事务的处理不同,

1. 读未提交(Read Uncommitted)

该隔离级别允许脏读,隔离级别是最低。该级别的隔离是一个事务正在处理某些数据,并且对数据进行了操作但是还没有对该事务进行提交,而与此同时,另外事务能够访问这些数据。


2.读已提交(Read Committed)

和读为提交相似,唯一的区别是只允许获取已经被提交的数据。

3. 可重复读

可重复读取(Repeatable Read),简单的说,就是保证事务处理过程中,多次读取同一个数据的时候,其值都和事务开始时刻是一致的,该事务禁止了不可重复读和脏读。


4. 串行化

串行化(Serializable)是最严格的事务隔离级别。要求所有的事务都被串行执行,即事务只能一个接一个的进行处理,不能并发执行。
复制代码

持久性

事务的持久性也被成为永久性,是指一个事务一旦提交,它对数据库中对应数据的状态的变更就应该是永久性的,换句话说。一旦某个事务成功结束,那么它对数据库所做的变更就要永久保存下来的,即使系统发生了奔溃或者宕机,只要能够重启,那么就可以恢复到事务成功结束时的状态.

分布式事务

CAP和BASE理论

对于本地事务处理或者集中式的事务处理系统,ACID模型时可以保证数据的严格一致性。但是在分布式的系统中随着分布式事务的出现,传统的淡季事务模型很难胜任。此时,CA和BASE这样的分布式定理就孕育而生了。

CAP定理

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

一致性

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

可用性

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

分区容错性

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

BASE理论

BASE是Basically Available(基本可用),Soft state(软件状态)和Eventually consistent(最终一致性)三个短语的简写,是由来自eBay的架构师的Dan Pritchett在其文章的BASE:An Acid Alternative 中首次明确剔除的。BASE是对CAP中的一致性的可用性权衡的结果,器来源于对大规模互联网系统的分布式时间的总结,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一直性,但是每个英语都可以根据自身的业务特点,采用适当的方式是系统达到最终一致性。

基本可用

基本可用性是指分布式你系统在出现不可预知的故障的时候,允许损失部分可用性,但是不等价于不可用。

  • 响应时间上的损失:一般一个搜索需要在0.5s之内返回给用户相应的结果,但是出现故障,查询时间增加到1-2s。
  • 功能上的损失:正常的情况下,为了系统的稳定运行,部分用户会被引导到一个降级的页面。

弱状一致性

最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步知乎,最终达到一个一直的状态。因此,最终一直性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致。

关注下面的标签,发现更多相似文章
评论