TCC设计理解-其他分布式事务(5)

原子业务要求的ACID,在事务上的设计除了TCC还有最经典的2PC

两阶段提交2PC,需要数据库XA支持以及相关支持X/Open协议的框架,比如java的atomikos

其他分布式事务,除了TCC主要的还有:

  • 异步确保型
  • 最大努力通知型

这些分布式事务都有其自身的设计优缺点,选型最终还需要按照场景来具体对待

可靠性消息(异步确保)

我的理解用于公司内部执行的对账、定时执行的部分功能,通过可靠性消息系统提供支持

可靠性消息通常由主动方来执行控制,被动的动作如果在执行时,需要支持幂等操作。被动方的处理结果不影响主动方的处理结果。

第一种

业务活动的主动方,在完成业务处理的同一个本地事务中,记录消息数据实时消息服务,业务处理事务提交后、通过实时消息服 务通知业务被动方,实时通知成功后删,除消息数据

消息恢复系统
• 消息恢复系统定期找到未成功发送的消息,交给实时消息服务补发送

第二种

可靠消息的另一种实现

事务开始:创建消息数据库消息,但不发送
确认发送:业务数据都成功,多条消息数据提交,
取消发送:业务数据失败,多条消息数据失败

业务处理服务在业务事务提交前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送

成本

• 一次消息发送需要两次请求
• 业务处理服务需实现消息状态回查接口

过程

• 消息状态确认系统定期找到未确认发送 或回滚发送的消息,向业务处理服务询 问消息状态,业务处理服务根据消息ID 或消息内容确定该消息是否有效
• 业务处理服务在业务事务提交后,向实 时消息服务确认发送。只有在得到确认 发送指令后,实时消息服务才真正发送 消息消息恢复系统

优点
• 消息数据独立存储、独立伸缩
• 降低业务系统与消息系统间的耦合

最大努力通知

交易结果的通知,依赖于MQ适用于第三方请求的外部服务
需要提供通知的状态查询,可以理解为有限通知