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