ZooKeeper篇:从ACID到CAP再到BASE



        随着互联网的快速发展,单机系统已经逐渐无法满足业务需求,于是分布式系统逐渐成了主流架构,同时带来的还有系统变迁过程中的一系列问题。其中比较典型的就是数据一致性问题,因此也就有了从单机事务ACID到分布式事务CAP理论再到BASE理论的演变



ACID


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

        一方面,当多个应用程序并发访问数据库时,事务可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作互相干扰。
        另一方面,事务为数据库操作序列提供了一个 从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。
        事务具有四个特征,分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),简称为事物的ACID特性。

原子性(Atomicity)

        事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中,只允许出现以下两种情况状态之一:全部执行成功、全部不执行。任何一项操作失败都将导致整个事务失败,同时其他已经被执行的操作都将被撤销兵回滚,只有所有的操作全部成功,整个事务才算是成功完成。


一致性(Consistency)

        事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行之前和执行之后,数据库都必须处于一致性状态,也就是说,事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态,一次当数据库只包含成功事务提交的结果时,就能说数据库处于一种一致性状态。而如果数据库系统在运行过程中发生故障,有些事务尚未完成就被迫中断,这些未完成的事务对数据库所做的修改有一部分已写入物理数据库,这是数据库就处于一种不正确的状态,或者说是不一致的状态。

隔离性(Isolation)

        事务的隔离性是指在并发环境中,并发的事务是相互隔离的,一个事务的执行不能被其他事务干扰,也就是说,不同的事务并发操纵相同的数据时,每个事务都有各自完整的数据空间,即一个事物内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。

在标准的SQL规范中,定义了4个事务隔离级别:未授权读,授权读,可重复读、串行化,不同的隔离级别对事务的处理不同,对应三种不同的并发的数据读取问题:脏读、幻读、不可重复读。

脏读

        读取未提交数据
        A事务读到了B事务尚未提交的数据,此时如果B事务发生错误并执行回滚操作,A事务读取到的就是脏数据。

不可重复读

        前后两次读取数据不一致
        A事务对同一数据前后两次读取期间,B事务更改了该数据并提交,导致A同一个事务内前后两次读同一数据读到数据不一致

幻读

        前后多次读取,数据总量不一致
        A事务前后两次统计数据的总量期间,B事务新增或删除了数据并提交,导致A在同一事务内前后两次统计到的数据量不一致


四种事务隔离级别对应上诉三种问题:

未授权读

        也被称为读未提交,隔离级别最低,允许脏读。

授权读

        也被称为读已提交,只允许获取已经被提交的数据,允许不可重复读

可重复读

        保证实物处理过程中,多次读取同一个数据时,其值都和实物开始时刻是一致的。因为禁止了不可重复读和脏读,允许幻读

串行化

        最雅阁的实物隔离级别。要求所有实物串行执行,不能并发执行

事务隔离级别越高,就越能保证数据的完整性和一致性,同时对并发性能的影响也越大。推荐使用授权读+业务层面悲观锁或者乐观锁来进行事务控制

持久性(Durability)

        也称为永久性,指一个事务一旦提交,它对数据库中对应数据的状态变更就应该是永久性的,即使发生系统崩溃活着机器宕机等故障,只要数据库能够重新启动,那么一定能够将其恢复到成功结束时的状态。



        单机情况下,很容易就能实现一套满足ACID特性的事务处理系统,但分布式系统中,会碰到诸如:通信异常(网络波动)、网络分区(节点之间数据不同步)、三态(成功、失败与超时)、节点故障灯问题,在可用性和一致性之间永远无法存在一个两全其美的方案,于是对于如何构建一个兼顾可用性和一致性的分布式系统,出现了如CAP和BASE这样的分布式系统进店理论。

CAP

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

一致性(C:Consistency)

        在分布式环境中,一致性是指数据在多个副本之间能否保持一致的特性。当一个系统在数据一致的状态下执行更新操作后,应该保持系统的数据仍然处于一致的状态。
        在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到其最新的值,那么这样的系统就被人为具有强一致性(或严格的一致性)

可用性(C:Consistency)

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


分区容错性(P:Partition tolerance)

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


        由于上文提到CAP不可能同时满足,于是就有三种不同的方案:
        (1)放弃P:一种简单的做法是将所有的数据都放在一个分布式节点上,相当于放弃了系统的可扩展性(不可能被接受,违背了分布式系统的最初目的)
        (2)放弃A:一旦系统遇到网络分区或其他故障时,受影响的服务需要等待一段时间,因为等待期间无法对外提供服务,即不可用
        (3)放弃C:放弃一致性是指放弃数据的强一致性,而保留数据的最终一致性。即允许一定时间内的数据不一致

        由于分区容错性是分布式系统必然面对和解决的问题,因此主要设计在于根据业务特点在C(一致性)和A(可用性)之间寻求平衡


BASE


        BASE是Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent(最终一致性)三个短语的缩写。BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于CAP定理逐步眼花而来的,其核心思想是即使无法做到强一致性,但可以采用适当方法来使系统大道最终一致性。

基本可用

        基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性:              响应时间上的损失:出现故障时,允许响应时间增加

             功能上的损失:服务降级

弱状态

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

最终一致性

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

参考:

《从Paxos到ZooKeeper分布式一致性原理与实践》

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值