分布式事务解决方案总结
1 概念
在开始前，我们先看几个概念：
-
ACID
ACID是指为保证事务的正确可靠，事务所必须具备的四个特性：- Atomicity（原子性
- Consistency（一致性）
- Isolation（隔离性）
- Durability（持久性）
-
CAP
CAP定理指出一个分布式计算系统不可能同时满足以下三点：- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance）
-
BASE
BASE理论内容：- Basically Available(基本可用)
- Soft State（软状态）
- Eventually Consistent（最终一致性）
BASE理论是基于CAP定理逐步演化而来的，其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
2 解决方案
以下是网上整理的几种解决方案:
2.1 规避分布式事务——业务整合
把多个服务调用整合到一个服务中，使分布式事务转换为本地事务，规避了分布式事务。
优点：规避了分布式事务
缺点：把拆分好的业务又耦合到了一起
2.2 eBay模式(异步消息模式)
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
消息日志发送的几种方式：
- 新建消息表
用异步线程不断关系表并扫描发送至消息队列，其它服务监听该队列消费消息
优点：服务间解耦
缺点：扫描频繁，对数据库压力大；扫描间隔时间长，时效性又低 - 挖掘数据库事务日志
当对数据库进行更新是，数据库的事务日志会记录更改信息，使用其它工具读取事务日志发向消息队列发送消息
优点：事件发布变得简单
缺点：数据库日志的格式对不同的数据库是专有的；记录于事务日志中的低级别更新可能难以对高级业务事件进行逆向工程 - 事件溯源
事件溯源通过使用完全不同的、不间断的方式来持久化业务实体，实现无2PC原子性。应用程序不存储实体的当前状态，而是存储一系列状态改变事件。通过无回放事件来重建实体当前状态。由于保存事件是一个单一操作，因此具有原子性
优点：可以在状态发生变化时可靠地发布事件，解决了数据一致性；持久化的是事件而不是领域对象，避免了对象关系阻抗失配问题；提供对业务实体所做更改的100%可靠的审计日志；业务逻辑包括松耦合的交换事件业务实体，从单体应用程序迁移到微服务架构更加容易
缺点：是一种不同而陌生的编程风格，存在学习曲线；事件存储仅支持通过主键查找业务实体；必须使用命令查询责任分离（CQRS）来实现查询，应用程序必须处理最终一致的数据
2.3 事务的各个参与方都需要同步得到结果，增加第三方比对服务
在每个参与方的本地业务库同实例上放一个事务记录表。
A同步调用B，C，A调用B,C成功后需要更新本地事务记录表，B、C同理，如果有一次A调用B失败，B有可能是失败，也可能超时。则由一个中心服务对比三方的事务记录表，做一个最终决定。
2.4 需要多个服务强一致性的场景
例如创建订单中，只有锁券和减库存成功后，创建订单才能成功。
要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。
不依赖分布式事务框架方案如下：
我们可以在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。
2.5 分布式事务框架
可以参考常用的分布式事务解决方案
网友评论