建议先关注、点赞、收藏后再阅读。
跨多个服务的业务处理:当一个业务操作涉及到多个服务时,每个服务都需要完成各自的事务操作,但需要保证这些操作要么都成功,要么都失败,以保持数据的一致性。
Event sourcing(事件溯源)架构:在事件溯源架构中,所有的状态改变都通过事件进行记录和恢复。当一个事务的操作需要产生多个事件,并且这些事件需要按特定顺序执行时,努力通知型分布式事务就变得必要。
例如,假设有一个电商平台,包含库存管理服务和订单管理服务。当用户下单时,需要从库存中扣减商品数量,并创建一个订单。这个操作涉及两个服务,需要保证两个服务的事务要么都成功,要么都失败。
如果在第三步中,库存管理服务无法发送成功通知(例如网络故障),订单管理服务将进行补偿操作,撤销之前的创建订单操作。
通过以上例子,可以看出努力通知型分布式事务的方案是必要的,因为它可以保证多个服务的事务操作的一致性,避免了数据不一致的问题。
努力通知型分布式事务的基本原理是基于可靠消息传递的原理,它将分布式事务的参与者设计为消息的发送者和接收者。
事务的发起者(即事务的主导者)向参与者发送事务请求,包括执行的操作和所需的数据。
参与者收到事务请求后,开始执行操作,并将执行结果保存到本地持久化存储中。
参与者将执行结果封装为消息,并发送给协调者(事务主导者)。
协调者收到消息后,将消息发送给其他参与者,让他们验证操作的合法性。
其他参与者收到消息后,在本地执行同样的操作,并将执行结果发送给协调者。
协调者收到所有参与者的执行结果后,进行全局事务状态的判断:
参与者接收到协调者的提交或回滚指令后,进行相应的操作执行。如果执行成功,参与者将发送执行结果给协调者。
协调者接收到所有参与者的执行结果后,根据结果进行事务的提交或回滚操作。