分布式事务

• 一致性 隔离性 持久性 原子性
• ACID
• 强一致，弱一致，最终一致
• 解决方案

两阶段提交

• 存在一个负责协调所有资源的事务管理器
• 第一阶段是询问各个资源是否准备就绪，当有一个不就绪，直接回滚
• 全部就绪后再统一提交
• 存在很多问题
• 同步堵塞，有资源占用的时候会阻塞其他事务
• 事务管理器故障以后，所有事务不可用
• 二阶段提交以后，如果宕机，不能确保数据一致

TCC try confirm cancel

• Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
• Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。
• Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。
• 在 Try 阶段，是对业务系统进行检查及资源预览，比如订单和存储操作，需要检查库存剩余数量是否够用，并进行预留，预留操作的话就是新建一个可用库存数量字段，Try 阶段操作是对这个可用库存数量进行操作。
• 基于 TCC 实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口，所以代码实现复杂度相对较高。

本地消息表

• 有消息生产者与消费者两个角色
• 假设a是消息生产者 b 是消息消费者
• a先操作入库，然后入库消息表，脚本定期轮询消息表放入mq
• b消费mq消息，执行业务
• 如果b产生错误，需要通知a回滚，b拉取消息失败，需要重试，所有需要实现幂等性
• 其实核心就是需要分布式处理的事务存储在一个可以访问的地方，b持续消费这里面的事务

可靠消息最终一致性

• a先向mq发送一条prepare消息，如果发送失败，直接取消操作
• 消息发送成功，执行本地操作
• 本地事务成功后，向mq发送confirm消息，发送失败回滚事务
• b定期消费mq里confirm消息，执行本地事务，并发送ack消息，如果b本地事务失败，会重试，业务失败，向系统a发送回滚请求
• mq会定期轮询prepare消息调用系统a提供的接口查询消息处理情况，如果执行成功，则重试发送confirm，否则回滚

尽最大努力通知

• 最大努力通知适用于对最终一致性时间敏感度低的业务
• 系统a执行完成后，写入mq
• 消费mq，调用b的服务
• 如果执行失败，一直重试，实在不行就放弃