作者:oschina 来源:开源中国 时间:2018-03-13 20:24:08 我要评论

Cap 原则

CAP 原则又称CAP定理,指的是在一个分布式系统中,consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。是NOSQL数据库的基石。

分布式系统的CAP理论:理论首先把分布式系统中的三个特性进行了如下归纳:

  1. 一致性(Consistency):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)。
  2. 可用性(Availability):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)。
  3. 分区容忍性(patition tolerance):以实际效果而言,分区相当于对通信的时限要求,系统如果不能再时限内达成数据一致性,就意味着发生了分区的情况。必须就当前操作在C和A之间做出选择。

一致性与可用性的抉择编辑

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性使我们必须要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NOSQL系统能同时保证这三点。对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地。

1.数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求不高,允许实现最终一致。(什么场景???)

2.数据库的写实时性和读实时性需求

对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性。比如说:发送一条消息后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

3.对复杂的SQL查询,特别是多表关联查询的需求

  任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

Base理论

BASE是 Basically Available(基本可用),Soft state (软状态)和Eventually Consistency(最终一致)三个词语的简写。Base是对CAP中一致性和可用性权衡的结果,其来源与对大规模互联网系统分布式时间的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong Consistency),但每个应用都可以根据自身的业务特点,采用是低昂的方式来使系统达到最终一致性(Eventual consistency)。

基本可用(Basically Available)

基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性--但注意,这绝不等价与系统不可用,以下两个就是"基本可用"的典型例子。

  1. 响应时间上的损失:正常情况下,一个在线搜索引擎需要0.5秒内返回给用户响应的查询结果,但由于出现异常(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加的了 1~2秒。
  2. 功能上的损失:正常情况下,在一个电子商务网站上进行购物,消费者几乎能够顺利地完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。

软状态(Soft state)

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

最终一致性

最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性 在实际工程实践中,最终一致性存在以下五类主要变种。

因果一致性:

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

读己之所写:

读己之所写是指,进程A更新一个数据项之后,它自己总是能够访问到更新过的最新值,而不会看到旧值。也就是说,对于单个数据获取者而言,其读取到的数据一定不会比自己上次写入的值旧。因此,读己之所写也可以看作是一种特殊的因果一致性。

会话一致性:

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

单调读一致性:

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

单调写一致性:

单调写一致性是指,一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

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

为什么会是这样

我们来看一个简单的问题, 一个DB服务 搭建在两个机房(北京,广州),两个DB实例同时提供写入和读取

输入图片说明

  1. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功 在没有出现网络故障的时候,满足CA原则,C 即我的任何一个写入,更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致, A 即我的读写操作都能够成功,但是当出现网络故障时,我不能同时保证CA,即P条件无法满足

  2. 假设DB的更新操作是只写本地机房成功就返回,通过binlog/oplog回放方式同步至侧边机房 这种操作保证了在出现网络故障时,双边机房都是可以提供服务的,且读写操作都能成功,意味着他满足了AP ,但是它不满足C,因为更新操作返回成功后,双边机房的DB看到的数据会存在暂时不一致,且在网络故障时,不一致的时间差会很大(仅能保证最终一致性)

  3. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务 降级服务,如停止写入,只提供读取功能,这样能保证数据是一致的,且网络故障时能提供服务,满足CP原则,但是他无法满足可用性原则

选择权衡

通过上面的例子,我们得知,我们永远无法同时得到CAP这3个特性,那么我们怎么来权衡选择呢? 选择的关键点取决于业务场景

对于大多数互联网应用来说(如网易门户),因为机器数量庞大,部署节点分散,网络故障是常态,可用性是必须需要保证的,所以只有设置一致性来保证服务的AP,通常常见的高可用服务吹嘘5个9 6个9服务SLA稳定性就本都是放弃C选择AP

对于需要确保强一致性的场景,如银行,通常会权衡CA和CP模型,CA模型网络故障时完全不可用,CP模型具备部分可用性,实际的选择需要通过业务场景来权衡(并不是所有情况CP都好于CA,只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务)

分布式系统的典型应用

分布式系统是一个非常广泛的概念,它最终要落实到解决实际问题上,不同的问题有不同的方法和架构。所有的开源软件都是以某个应用场景出现,而纯粹以“分布式”概念进行划分的比较少见。 但如果以算法划分,到能分出几类:

1.以Leader选举为主的一类算法,比如paxos、viewstamp,就是现在zookeeper、Chuby等工具的主体

2.以分布式事务为主的一类主要是二段提交,这些分布式数据库管理器及数据库都支持

3.以若一致性为主的,主要代表是Cassandra的W、R、N可调节的一致性

4.以租赁机制为主的,主要是一些分布式锁的概念,目前还没有看到纯粹“分布式”锁的实现

5.以失败探测为主的,主要是Gossip和phi失败探测算法,当然也包括简单的心跳

6.以弱一致性、因果一致性、顺序一致性为主的,开源尚不多,但大都应用在Linkedin、Twitter、Facebook等公司内部

7当然以异步解耦为主的,还有各类Queue

五、ACID和BASE的区别与联系

ACID是传统数据库常用的设计理念,追求强一致性模型。BASE支持的是大型分布式系统,提出通过牺牲强一致性获得高可用性。

ACID和BASE代表了两种截然相反的设计哲学,在分布式系统设计的场景中,系统组件对一致性要求是不同的,因此ACID和BASE又会结合使用。



文章转载自 开源中国社区 [http://www.oschina.net]

本文地址:https://my.oschina.net/u/3421984/blog/1634221

12阅读 | 0评论
你的回应
写文章

联系我们