内容概览
- 服务模式
- TCC解决方案
- 可靠消息最终一致性解决方案
- 最大努力通知型解决方案
最终一致性分布式解决方案并不要求参与事务的各个节点数据时刻保持一致，允许其存在中间状态，只要一段时间后，能够达到数据的最终一致状态即可。
优缺点
优点
1.性能较高，不会长时间持有事务
2.适合高并发场景 缺点
1.某个时刻数据可能会不一致
2.不太适合事务一致性要求高的场景
1. 服务模式
1.1. 可查询操作
需要服务的操作具有可标识性，主要体现在服务的操作具有全局唯一标识，如订单号、流水号等。业务服务需要提供操作业务的接口以保证通过可查询的接口获取服务的处理情况。
1.2. 幂等操作
即操作具有幂等性
1.3. TCC操作
1.3.1. Try
完成所有业务的一致性检查；预留必要的业务资源并与其他操作隔离 1.3.2. Confirm
用预留的资源真正执行业务操作；满足幂等性 1.3.3. Cancel 释放Try阶段预留的业务资源；满足幂等性
1.4. 可补偿操作
在某些数据处于不正常状态时，需要通过某种方式进行业务补偿。(需要满足幂等)
2. TCC解决方案
主要解决跨服务调用场景下的分布式事务 本质上讲，TCC是一种在应用层实现的2PC
需要实现的服务模式有TCC操作、幂等性操作、可补偿操作、可查询操作
2.1. 适用场景
适用于具有强隔离性、严格一致性要求的业务场景，以及执行时间较短的业务。
2.2. 执行流程
1.try 阶段 不执行任何业务逻辑，仅做一致性检查和预留相应的资源 2.Confirm阶段 try阶段成功后开始执行Confirm阶段。一般来说，只要第一阶段成功这个阶段就不会出错。如果出错就需要引入重试机制或人工干预。 3.Canel阶段 出现异常需要回滚事务，执行分支事务的取消并释放try阶段预留的资源。如果这个阶段出错也需要引入重试机制或人工干预
2.3. 优缺点
优点 1.在应用层实现逻辑，锁的粒度较小。
2.Confirm 和 Cancel阶段的操作具有幂等性，保证数据的一致性。
3.只要发起事务的业务和分支业务为集群模式，就能避免XA规范的单点故障问题。
缺点 1.和业务耦合度高
2.4. TCC需要注意的问题
1.空回滚问题 当某个事务分支出现网络等异常没有执行try阶段，当恢复后，执行回滚操作，如果分支不能处理Cancel这种情况就会出空回滚。
解决方案： 须有相应的全局事务记录和分支事务记录，如果执行Cancel时分支没有try或没有数据>操作,就不做操作。
2.幂等问题 由于引入了重试机制所以可能会导致数据不一致
解决方案：在分支记录中增加事务的执行状态，每次执行分支事务以及Confirm、Cancel阶段时，都查询此事务的状态，从而保证幂等性。
3.悬挂问题 预留业务资源后，由于网络、宕机等异常无法继续往下处理。 解决方案：在执行Try阶段的方法时，先判断分支记录中是否已经存在全局事务下的Confirm或Cancel阶段的事务记录，如果存在则不再执行Try阶段方法
3.可靠消息最终一致性解决方案
指事务发起方完成本地事务后，发出一条消息，事务参与者收能收到消息并执行成功，事务最终达到一致状态。
实现的服务模式：可查询操作和幂等操作
3.1 适用场景
耦合度低，对业务数据一致性的时间敏感度高的场景
3.2 执行流程
- 事务发起方发送消息到可靠消息服务
可靠消息服务：本地消息数据表或消息中间两者方式都可。
- 事务参与方从消息中间件接收消息
消息确认服务和消息恢复服务都是为了解决分布式问题
消息确认服务： 该服务会定时检查事务发起方的执行状态和消息库中的数据，若两者数据不一致，消息确认服务会同步两者的数据，使数据一致，确保事务发起方完成本地事务后消息一定发送成功。 消息恢复服务； 该服务会定时检测事务参与方的执行状态会消息库的中的数据，若事务参与方执行状态与消息库中数据不一致（执行失败等），该服务就会恢复消息库中的消息状态为未消费的状态。
3.3 优缺点
- 基于本地消息表的可靠消息服务方式
优点： 减少了中间件依赖
缺点： 耦合性高，不宜扩展
- 基于中间件的可靠消息服务方式
优点：解耦，并发和吞吐量高于本地消息表
缺点：需要实现消息的回查，增加了开发成本。
3.4 需要注意的问题
- 事务发送方本地事务与消息发送的原子问题
本地事务和发送消息要么都成功要么都失败
解决方法：通过消息确认服务解决
- 事务参与方接收消息的可靠性
事务参与方无法消费消息或消费后无法将结果正确传回消息库
解决方法：通过消息恢复服务保证参与方的可靠
- 事务参与方与接收消息的幂等性
解决方法：事务参与方的方法实现要具有幂等性，只要参数相同，无论调用多少次，只会执行一次
4. 最大努力通知型解决方案
允许丢失消息，但需要提供业务主动方提供事务状态查询接口给参与方主动调用并恢复丢失的业务。
实现服务模式：可查询操作和幂等操作
4.1. 适用场景
最终一致性时间敏感度低，且参与方的处理结果不影响主动方的处理结果。如支付后的异步通知。
4.2. 执行流程
4.3. 需要注意的问题
- 消息重复通知
解决方案：事务参与方接收消息通知的方法具有幂等型
- 消息丢失
解决方案：业务主动方需要提供消息接口满足参与方主动查询消息以恢复丢失的业务。
最大努力通知和可靠消息最终一致性的区别
- 设计不同
1)可靠消息需要事务发起方一定要将消息发送成功。
2)最大努力通知消息可能丢失
- 业务场景
- 可靠消息适用时间敏感度高
- 时间敏感度低，事务主动方只需将处理结果发送出去
