当客户端将节点1上的A修改为2后,系统出现了网络分区,其中节点1和节点2在一个网络分区中,而节点3在另一个分区中
当有客户端尝试读取节点3上的A值时,系统将面临两难困境
系统等待节点3从节点1同步A的值,待数据一致后再返回客户端响应,但是因为节点3和节点1不在一个分区中,双方无法进行通信,导致系统无法在限定时间内给客户端返回读取结果,这明显不符合可用性的要求。
系统立即返回一个A=1的旧值给客户端,由于A的值在不同节点上不一样,导致一致性的条件被破坏。
因而,对于满足分区容错性的系统而言,强一致性和可用性的要求难以同时被满足。其实这是很容易理解的,即使没有网络分区,因为不同节点上的数据需要经过网络通信来保持一致性,这个过程本身就比较花时间,当需要在给定很短的时限内基于客户端响应时,对于一致性的保证自然就比较弱。
3.2 如何正确理解CAP定理对于分布式系统而言CAP三要素不可兼得,但并不意味着在任何时刻都必须从中做出取舍,或者在构建分布式系统之初就选择其中两个而放弃另一个,这种看法具有片面性。
由于网络分区出现的可能性非常小,系统在正常运行的情况下还是应该兼顾AC两者,在进入网络分区模式后才需要对P进行保证,从A和C中选择牺牲一个。
A和C并不是一个硬币的两面,只能选择其中一个;A和C应该看成天平,系统可以选择向哪边倾斜,但另一边也应该一定程度的保留。
对于A和C之间的选择,不应该粗粒度的整个系统级别进行选取,而应该针对系统中的不同子系统,针对性的采取不同的取舍策略。
4. 一致性的妥协——最终一致性和Base原则由CAP定理可知,在分布式系统中过于追求数据的强一致性将导致可用性一定程度被牺牲,这意味着系统将不能很好的响应用户的请求,这会一定程度影响用户体验。因而对于大部分布式系统而言,应当在保证系统高可用的前提下去追求数据的一致性,BASE原则正是对这一思想的描述。
BA(Basically Available)
基本可用:系统在绝大部分时间应处于可用状态,允许出现故障损失部分可用性,但保证核心可用。
S(Soft State)
软状态:数据状态不要求在任何时刻都保持一致,允许存在中间状态,而该状态不影响系统可用性。对于多副本的存储系统而言,就是允许副本之间的同步存在延时,并且在这个过程中系统依旧可以响应客户端请求。
E(Eventual Consistency)
最终一致性:尽管软状态不要求分布式数据在任何时刻都保持一致,但经过一定时间后,这些数据最终能达到一致性状态。
BASE理论的核心思想是:把分布式系统的可用性放在首位,放弃CAP中对数据强一致性的追求,只要系统能保证数据最终一致。
4.1 CAP,BASE以及ACID的关系CAP描述了对于一个分布式系统而言重要的三要素:数据一致性,可用性,分区容错性之间的制约关系,当你选择了其中的两个时,就不得不对剩下的一个做一定程度的牺牲。BASE和ACID都可以看做是对CAP三要素进行取舍后的某种特殊情况
BASE强调可用性和分区容错性,放弃强一致性,这是大部分分布式系统的选择,比如NoSQL系统,微服务架构下的分布式系统
ACID是单机数据的事务特性,因为不是分布式系统无需考虑分区容错,故而是选择了可用性和强一致性后的结果。
它们之间的关系如下所示
幂等的概念来自于抽象代数,比如对于一元函数来说,满足以下条件
即可称为满足幂等性。在计算机科学中,一个操作如果多次执行产生的影响与一次执行的影响相同,这样的操作即符合幂等性。在分布式系统中,服务消费方调用服务提供方的接口,多次调用的结果应该与一次调用的结果一样,这正是分布式环境下幂等性的语义。为什么幂等性对分布式系统而言如此重要？因为在分布式环境下,服务的调用一般采用http协议或者rpc的方式,即双方需要通过网络进行通信,而因为网络故障或者消息超时的存在,可能服务消费方已经成功调用了服务提供方的服务接口,但是消费方并没有收到来自对方的成功响应,导致消费方以为服务调用失败从而再次进行调用,也就是说网络的不可靠性导致了服务接口被多次调用的可能。分布式系统必须保证在这种情况下,即使接口被多次调用,它对系统产生的影响应该与该接口只被调用一次的结果一样。
6.微服务架构的分布式一致性和幂等性问题 6.1 微服务架构下的分布式一致性问题