Zookeeper系列(1)--分布式一致性理论,CAP,BASE理论
分布式的问题
为什么会有分布式数据一致性问题
在上面,我们介绍了一下分布式和分布式下的一些问题,接下来,我们要讨论,为什么会出现分布式数据一致性问题。因为在分布式系统中,节点宕机是常态,为了高可用性,我们一般会部署多台服务器,势必就会存在数据的复制问题。分布式系统对于数据的复制需求一般来自于以下两个原因:- 高可用:将数据复制到分布式部署的多台机器中,可以消除单点故障,防止系统由于某台(些)机器宕机导致的不可用。
- 性能:通过负载均衡技术,能够让分布在不同地方的数据副本全都对外提供服务。有效提高系统性能。
CAP理论
CAP是Consistency、Availablity和Partition-tolerance的缩写。分别是指:
1.一致性(Consistency):每次读操作都能保证返回的是最新数据,在分布式系统中,如果能针对一个数据项的更新执行成功后,所有的用户都可以读到其最新的值,这样的系统就被认为具有严格的一致性。
2.可用性(Availablity):任何一个没有发生故障的节点,会在合理的时间内返回一个正常的结果,也就是对于用户的每一个请求总是能够在有限的时间内返回结果;
3.分区容忍性(Partition-torlerance):当节点间出现网络分区(不同节点处于不同的子网络,子网络之间是联通的,但是子网络之间是无法联通的,也就是被切分成了孤立的集群网络),照样可以提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。
CAP理论指出:CAP三者只能取其二,不可兼得。
首先,如果我们要使网络分区不存在,就必须将系统部署在单个节点上,因为网络总是会出现故障,分区总是存在的,所以当部署在单节点上,可以同时保证CP,但是这时候,就没什么意义了,这都不是分布式了,同时单点故障可能会发生,就不会保证A可用性。
所以我们必须明确一点:对于分布式系统而言,分区容错性是必须要满足的,因为分区的出现时必然,也是必须要解决的问题。所以,P必须要保证,那么我们就要在C和A之间做权衡。
>有两个或以上节点时,当网络分区发生时,集群中两个节点不能相互通信(也就是说不能保证可用性A)。此时如果保证数据的一致性C,那么必然会有一个节点被标记为不可用的状态,违反了可用性A的要求,只能保证CP。
>反正,如果保证可用性A,即两个节点可以继续各自处理请求,那么由于网络不通不能同步数据,必然又会导致数据的不一致,只能保证AP。
BASE理论
基本可用:
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性——但请注意,这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。
1. 响应时间上的损失:正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加到了1~2秒。
2. 功能上的损失:正常情况下,在一个电子商务网站上进行购物,消费者几乎能够顺利地完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。
弱状态
弱状态也称为软状态,和硬状态相对,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
注意:最终一致性是一种特殊的弱一致性:系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问都能够获取到最新的值。同时,在没有发生故障的前提下,数据达到一致状态的时间延迟,取决于网络延迟、系统负载和数据复制方案设计等因素。在实际工程实践中,最终一致性存在以下五类主要变种。
1 因果一致性(Causal consistency)
因果一致性是指,如果进程A在更新完某个数据项后通知了进程B,那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值,并且如果进程B要对该数据项进行更新操作的话,务必基于进程A更新后的最新值,即不能发生丢失更新情况。与此同时,与进程A无因果关系的进程C的数据访问则没有这样的限制。
2 读己之所写(Read your writes)
读己之所写是指,进程A更新一个数据项之后,它自己总是能够访问到更新过的最新值,而不会看到旧值。也就是说,对于单个数据获取者来说,其读取到的数据,一定不会比自己上次写入的值旧。因此,读己之所写也可以看作是一种特殊的因果一致性。
3 会话一致性(Session consistency)
会话一致性将对系统数据的访问过程框定在了一个会话当中:系统能保证在同一个有效的会话中实现“读己之所写”的一致性,也就是说,执行更能操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。
4 单调读一致性(Monotonic read consistency)
单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后,那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
5 单调写一致性(Monotonic write consistency)
单调写一致性是指,一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
事实上,最终一致性并不是只有那些大型分布式系统才涉及的特性,许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中,大多都会采用同步和异步方式来实现主备数据复制技术。1 .在同步方式中,数据的复制过程通常是更新事务的一部分,因此在事务完成后,主备数据库的数据就会达到一致(强一致性)。2. 而在异步方式中,备库的更新往往会存在延时,这取决于事务日志在主备数据库之间传输的时间长短,如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上,那么很显然,从备库中读取的数据将是旧的,因此就出现了数据不一致的情况。当然,无论是采用多次重试还是人为数据订正,关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。
总的来说,BASE理论面向的是大型高可用可扩展的分布式系统,和传统事务的ACID特性是相反的,它完全不同于ACID的强一致性模型,而是提出通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。但同时,在实际的分布式场景中,不同业务单元和组件对数据一致性的要求是不同的,因此在具体的分布式系统架构设计过程中,ACID特性与BASE理论往往又会结合在一起使用。
以上BASE相关的理论来自《从Paxos到Zookeeper分布式一致性原理与实践》。