分布式事务

2018-10-24 08:45:28来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

1.  分布式理论

1.1.  CAP定律

CAP指的是:一致性(Consistency)可用性(Availability)分区容错性(Partition tolerance)

CAP定律说的是,在一个分布式系统中,最多只能满足C、A、P中的两个,不可能三个同时满足。

在分布式系统中,网络无法 100% 可靠,分区其实是一个必然现象。如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证一致性,这个时候必须拒绝请求,但是 A 又不允许,所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构

而且,显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。

更多请参考  https://queue.acm.org/detail.cfm?id=1394128

1.2.  BASE理论

往往在分布式系统中无法实现完全一致性,于是有了BASE理论,它是对CAP定律的进一步扩充

BASE指的是:

  • Basically Available(基本可用) : 分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用
  • Soft state(软状态) : 允许系统中存在中间状态,这个状态不影响系统可用性
  • Eventually consistent(最终一致性) : 经过一段时间后,所有节点数据都将会达到一致

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果

BASE理论核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性

BASE理论是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态

2.  分布式事务解决方案

2.1.  基于XA协议的两阶段提交

XA协议包含两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,目前主流的关系型数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

优点:尽量保证了数据的强一致,适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致)

缺点:XA协议遵循强一致性。在事务执行过程中,各个节点占用着数据库资源,只有当所有节点准备完毕,事务协调者才会通知提交,参与者提交后释放资源。这样的过程有着非常明显的性能问题。

(PS:XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段,并且引入了超时机制。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。)

两阶段提交方案锁定资源时间长,对性能影响很大,基本不适合解决微服务事务问题。

2.2.  TCC方案

TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。

将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚。  

拿前面的下单的例子来说,服务A的try相当于查询是否有可用的积分,Confirm相当于扣减积分,Cancel相当于增加积分。

优点:跟2PC比起来,实现以及流程相对简单了一些,但数据的一致性比2PC也要差一些

缺点:TCC属于应用层的一种补偿方式,所以需要程序员在实现的时候多写很多补偿的代码,而且补偿的时候也有可能失败,在一些场景中,一些业务流程可能用TCC不太好定义及处理。

2.3.  本地消息表

其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。

消息生产方,需要额外建一个消息表,并记录消息发送状态。消息表和业务数据要在一个事务里提交,也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败,会进行重试发送。

消息消费方,需要处理这个消息,并完成自己的业务逻辑。此时如果本地事务处理成功,表明已经处理成功了,如果处理失败,那么就会重试执行。如果是业务上面的失败,可以给生产方发送一个业务补偿消息,通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表,把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑,这种方案还是非常实用的。

本地消息表是一个比较好的做法,这样可以有效防止重复消息处理

以转账为例,这种方式的过程是这样的:

  1. 当A想给B转100元时,A账户先减100元,然后在其本地消息表中加一条记录,写明A给B转100元,并且状态是消息未发送。这个向消息表写数据的操作和A账户扣减100元在同一个事务中,依靠数据库本地事务保证一致性,即只要A减100成功了,这条记录必然成功。
  2. 定时任务去轮询消息表,把没有发出去的消息都发出去,并标记状态为已发送
  3. B收到这个消息的时候先存入本地的消息表,标记未处理
  4. B这边定时扫描未处理的消息,处理完成后更新状态为已处理

有了消息表以后,可以防止重复、可以重试、保证消息不丢失、做幂等性校验

优点一种非常经典的实现,避免了分布式事务,实现了最终一致性

缺点:消息表会耦合到业务系统中,如果没有封装好的解决方案,会有很多杂活需要处理。

2.4.  MQ(非事务消息)

如果不把本地数据库操作和消息投递放在同一个事务中,那么很难保证本地事务成功后消息一定发送成功

如果把它们放在同一个事务中,那么考虑下面几种情况:

  • 第1种情况:本地数据库操作成功,消息发送成功,皆大欢喜
  • 第2种情况:本地数据库操作失败,消息不会发送
  • 第3种情况:本地数据库操作成功,消息发送失败(抛异常),事务回滚

以上三种情况都是正常的,不会有什么问题

然而,考虑下面这种情况:

本地数据库操作成功,消息投递成功,应用服务器挂了,事务回滚,于是不一致出现了,即本地数据库操作没成功,而消息却发成功了

如果这是转账的话,对方会无缘无故多出一笔钱

究其原因,是因为发消息不是数据库操作,它不受ACID的限制,也就是说数据库事务管不了发消息,因为他们不是同一个数据库的同一个事务,当然还有一个原因是发出去的消息是无法撤销的。(PS:在后面将要介绍的RocketMQ的事务消息可以撤销)

而上面消息表的话,是同一个数据库的同一个事务,因此不会出现这种问题

综上,这种方式有一定的风险,它无法保证本地数据库操作 与 消息投递的一致性,不建议使用

2.5.  MQ(事务消息)

目前,仅阿里云的RocketMQ支持事务消息。帮助用户实现类似 X/Open XA 的分布事务功能,通过 MQ 事务消息能达到分布式事务的最终一致。

说明:

  1. 发送方向 MQ 服务端发送消息
  2. MQ Server 将消息持久化成功之后,向发送方 ACK 确认消息已经发送成功,此时消息为半消息
  3. 发送方开始执行本地事务逻辑
  4. 发送方根据本地事务执行结果向 MQ Server 提交二次确认(Commit 或是 Rollback),MQ Server 收到 Commit 状态则将半消息标记为可投递,订阅方最终将收到该消息;MQ Server 收到 Rollback 状态则删除半消息,订阅方将不会接受该消息
  5. 在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达 MQ Server,经过固定时间后 MQ Server 将对该消息发起消息回查
  6. 发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果
  7. 发送方根据检查得到的本地事务的最终状态再次提交二次确认,MQ Server 仍按照步骤4对半消息进行操作

其中,事务消息发送对应步骤1、2、3、4,事务消息回查对应步骤5、6、7

更多请参见  https://help.aliyun.com/document_detail/43348.html?spm=a2c4g.11186623.6.551.2ddc47b1P5PHi2

2.6.  GTS

全局事务服务(Global Transaction Service,简称 GTS)是一款高性能、高可靠、接入简单的分布式事务中间件,用于解决分布式环境下的数据一致性问题。GTS 可以保证分布式系统中的分布式事务的 ACID 特性。它是阿里云的一款产品。

更多请参见  https://help.aliyun.com/document_detail/48726.html?spm=a2c4g.11186623.6.542.53ff681awWVYxc

3.  参考

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

https://www.cnblogs.com/jiangyu666/p/8522547.html

https://www.jianshu.com/p/16b1baf015e8

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:秒杀系统

下一篇:struts2_HelloWorld