分布式架构下的数据一致性

最新推荐文章于 2023-06-25 17:11:59 发布

weixin_34378045

最新推荐文章于 2023-06-25 17:11:59 发布

阅读量278

点赞数

文章标签： git python java

原文链接：https://my.oschina.net/jsycwangwei/blog/1931198

版权

2019独角兽企业重金招聘Python工程师标准>>>

分布式系统区别于传统的单体应用，单体应用的业务模块和数据都在同一个应用当中，利用spring的事务管理器即可完成对事务的控制。在分布式系统中，来自客户端的一次请求可能会分布在不同的服务中，分布式的一致性问题由此而生。

一、分布式一致性原理 1.1、CAP理论分布式系统的三个特性：一致性（Consistency），任何情况下都保持数据的同步一致性。可用性（Availability）, 任何情况下都不会出现服务的掉线。分区容忍性（Partition tolerance），任何情况下都能保证服务的可靠性。

结论：
任何分布式系统智能满足以上三个特性中的两个，架构设计的时候进行取舍。

1.2、BASE理论在分布式系统设计的时候，我们往往考虑的是可用性，重要性高于一致性，如何实现高可用呢？这就是BASE理论，它是用来对CAP理论的扩充，BASE理论是指：基本可用（Basically Available）软状态（Soft State）最终一致性（Eventually Consistent） Base理论是对CAP理论在一致性和可用性上权衡的结果，核心思想就是：我们无法做到强一致，但每个应用可以根据自己的业务特点，采用适当的方式达到系统的最终一致性。

二、分布式一致性算法/解决方案

2.1、分布式一致性算法

2.2、2PC 二阶段提交的算法思路可以概括为，操作者将操作成功或者失败的结果通知给协调者，再由协调者根据参与者的反馈确定是提交结果还是终止操作。第一阶段，准备阶段（投票阶段）；第二阶段，提交阶段（确认阶段）。

「2PC的遗留问题」

o 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 o 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。 o 二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

2.3、3PC 三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的commit或rollback请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续commit。相对于两阶段提交虽然降低了同步阻塞，但仍然无法避免数据的不一致性。在分布式数据库中，如果期望达到数据的强一致性，那么服务基本没有可用性可言，这也是为什么许多分布式数据库提供了跨库事务，但也只是个摆设的原因，在实际应用中我们更多追求的是数据的弱一致性或最终一致性，为了强一致性而丢弃可用性是不可取的。

2.4、TCC TCC采用的就是补偿机制，TCC和传统的事务机制XA模式的区别主要在于，它不是通过资源管理器来支持的，而是通过业务逻辑的调度来实现的分布式事务。对于业务系统中一个特定的业务逻辑S，其对外提供服务时，必须接受一些不确定性，即对业务逻辑执行的一次调用仅是一个临时性操作，调用它的消费方服务M保留了后续的取消权。如果M认为全局事务应该rollback，它会要求取消之前的临时性操作，这就对应S的一个取消操作。而当M认为全局事务应该commit时，它会放弃之前临时性操作的取消权，这对应S的一个确认操作。每一个初步操作，最终都会被确认或取消。因此，针对一个具体的业务服务，TCC事务机制需要业务系统提供三段业务逻辑：初步操作Try、确认操作Confirm、取消操作Cancel。

核心思想是：给每个操作都绑定一个确认与补偿的接口，它的主要流程分为三个阶段： o Try 阶段主要是对业务系统做检测及资源预留； o Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认 Confirm阶段是不会出错的； o Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。