区块链开发：一致性算法（三）#C15
2019-05-21 本文已影响1人
纳兰少
本篇部分为资料整理
5. 解决方案 ( ★分布式事务中保持数据一致性 )
MQ实现二阶段提交
目前主流的一致性解决方案都是利用MQ来实现二阶段提交（事务性）。
涉及三个模块：
- 上游应用，执行业务并发送 MQ 消息。
- 可靠消息服务和 MQ 消息组件，协调上下游消息的传递，并确保上下游数据的一致性。
- 下游应用，监听 MQ 的消息并执行自身业务。
上游应用执行业务并发送 MQ 消息（第一阶段）
上游应用将本地业务执行和消息发送绑定在同一个本地事务中，保证要么本地操作成功并发送 MQ 消息，要么两步操作都失败并回滚。
- 上游应用发送待确认消息到可靠消息系统
- 可靠消息系统保存
待确认消息并返回 - 上游应用执行本地业务
- 上游应用通知可靠消息系统确认业务已执行并发送消息。
- 可靠消息系统修改消息状态为
发送状态（已发送）并将消息投递到 MQ 中间件。
可靠消系统一开始为待确认状态，当步骤1-3出错时，上游应用整个事务回退，不影响一致性。而当4、5发生错误时，会出现不一致性，需要做如下处理：
- 可靠消息服务定时监听消息的状态，如果存在状态为
待确认并且超时的消息，则表示上游应用和可靠消息交互中的步骤 4 或者 5 出现异常。 - 向上游应用查询业务执行的情况
- 业务未执行，则删除该消息，保证业务和可靠消息服务的一致性。业务已执行，则修改消息状态为已发送，并发送消息到 MQ 组件。
下游应用监听 MQ 消息并执行业务（第二阶段）
下游应用监听 MQ 消息并执行业务，并且将消息的消费结果通知可靠消息服务。
可靠消息的状态需要和下游应用的业务执行保持一致，可靠消息状态不是已完成时，确保下游应用未执行，可靠消息状态是已完成时，确保下游应用已执行。
- 下游应用监听 MQ 消息组件并获取消息
- 下游应用根据 MQ 消息体信息处理本地业务
- 下游应用向 MQ 组件自动发送 ACK 确认消息被消费
- 下游应用通知可靠消息系统消息被成功消费，可靠消息将该消息状态更改为
已完成。
步骤4发生错误时，会造成不一致性，此时可靠消息服务中存在消息状态为已发送并且超时的消息，执行以下操作：
- 可靠消息服务定时查询状态为已发送并超时的消息
- 可靠消息将消息重新投递到 MQ 组件中
- 下游应用监听消息，在满足幂等性的条件下，重新执行业务。
- 下游应用通知可靠消息服务该消息已经成功消费。
此外还有 TCC和最大努力通知方案。ref
TCC
tcc模式中，活动管理器就等同于对外接口，先调用主服务，主服务调用从服务的try；如果从服务都try成功，那么主服务再执行业务操作，再将从服务接口返回给活动管理器，后续由活动管理器来调用从服务的执行或回滚。
但是细究可以发现，该模式适合有主从业务等级的划分，因为从服务的接口是由主服务来获取，但实际中可能主服务的调用在从服务之后，而且不一定有主从关系。再者活动管理器可以直接就知晓各服务接口，然后顺序调用，只是每个服务 都需要有do和cancel接口。
具体实践可以参考RAS-MSG
