可靠消息最终一致性解决方案
可靠消息最终一致性分布式事务解决方案指的是事务的发起方执行完本地事务之后，发出一条消息，事务的参与方，也就是消息的消费者一定能够接收到这条消息并且处理完成，这个方案强调的是只要事务发起方将消息发送给事务参与者，事务参与方就一定能够执行完成，事务最终达到一致性的状态
适用的场景
适用于消息数据能够独立存储，能够减低系统之间耦合度，并且业务对数据一致性的时间敏感度高的场景
需要实现的服务模式
需要实现的服务模式是可查询操作和幂等操作，需要参与分布式事务的业务服务提供可查询自身事务状态的接口，发生异常时，能够通过接口查询具体的事务状态，这就是可查询操作，参与分布式事务的各个业务接口需要保证数据操作的幂等性。
方案的执行流程
可靠消息最终一致性方案中，事务发起方执行完本地事务后，通过可靠消息服务将消息发送给事务参与方，事务参与方收到消息后，一定能够成功执行，这里的可靠消息服务可以通过本地消息表实现，也可以通过RocketMq消息队列实现
首先，事务发起方将消息发送给可靠消息服务，这里的可靠消息服务可以基于本地数据表实现，也可以基于消息队列中间件实现。然后，事务参与方从可靠消息服务中接收消息。事务发起方和可靠消息服务之间、可靠消息服务和事务参与方之间都是通过网络进行通信的。由于网络本身的不稳定性，可能会造成分布式事务问题，因此在实现上，需要引人消息确认服务和消息恢复服务。
消息确认服务会定期检测事务发起方业务的执行状态和消息库中的数据，如果发现事务发起方业务的执行状态与消息库中的数据不一致，消息确认服务就会同步事务发起方的业务数据和消息库中的数据，保证数据一致性，确保事务发起方业务完成本地事务后消息定会发送成功。
消息恢复服务会定期检测事务参与方业务的执行状态和消息库中的数据，如果发现事务参与方业务的执行状态与消息库中的数据不一致(这里的不一致，通常指的是事务参与方消费消息后，执行本地事务操作失败，导致事务参与方本地事务的执行状态与消息库中的数据不一致)，消息恢复服务就会恢复消息库中消息的状态，使消息的状态回滚为事务发起方发送消息成功，但未被事务参与方消费的状态。
方案的优缺点
消息最终一致性方案的可靠消息服务可以基于本地消息表和消息队列中间件两种方式实现
基于本地消息表实现的最终消息一致性方案
优点：
- 在业务应用中实现了消息的可靠性，减少了对消息中间件的依赖
缺点：
- 绑定了具体的业务场景，耦合度太高，不可公用和扩展
- 消息数据与业务数据同在一个数据库，占用了业务系统的资源
基于消息队列中间件实现的最终消息一致性方案
优点：
- 消息数据能够独立存储，与具体的业务数据库解耦
- 消息的并发性和吞吐量由于本地消息表方案
缺点：
- 发送一次消息需要完成两次网络交互，一次是消息的发送，另外一次是消息的提交或者回滚
- 需要实现消息的回查接口，增加了开发的成
需要注意的问题
使用可靠消息最终一致性方案解决分布式事务问题时，需要注意本地事务与消息发送的原子性问题、事务参与方接收消息的可靠性与幂等性问题
1、事务发送方本地事务与消息发送的原子性问题
- 产生的原因：可靠消息最终一致性要求事务发起方的本地事务与消息发送的操作具有原子性，也就是事务发起方执行本地事务成功后，一定要将消息发送出去，执行本地事务失败后，一定要丢弃消息。执行本地事务和发送消息，要么都成功，要么都失败
- 原子性问题的解决方案：在实际的解决方案中，可以通过消息确认服务解决本地事务与消息发送的原子性问题
2、事务参与方接收消息的可靠性问题
- 可靠性问题产生的原因：由于服务器宕机、服务崩溃或网络异常等原因，导致事务参与方不能正常接收消息或者接收消息后处理事务的过程中发生异常，无法将结果正确回传到消息库中。此时，就会产生可靠性问题
- 可靠性问题的解决方案：可以通过消息恢复服务保证事务参与方的可靠性
3、事务参与方接收消息的幂等性问题
- 幂等性问题产生的原因：在实际场景中，由于某种原因，可靠消息服务可能会多次向事务参与方发送消息，如果事务参与方的方法不具有幂等性，就会造成消息重复消费的问题，这就是典型的幂等性问题
- 幂等性问题的解方案：解快方案就是事务参与方的方法实现要具有幂等性，只要参数相同，无论调用多少次接口或方法、得出的结果都与第一次调用接口或方法得出的结果相同
最大努力通知型解决方案
当分布式事务跨越多个不同的系统，尤其是不同企业之间的系统时，解决分布式事务问题就需要用到最大努力通知型方案
适用的场景
最大努力通知型解决方案适用于最终一致性时间敏感度低的场景，并且事务被动方的处理结果不会影响主动方的处理结果，典型的使用场景就是支付成功后，支付平台异步通知商户支付结果
需要实现的服务模式
最大努力通知型解决方案需要实现的服务模式是可查询操作和幂等操作。例如，在充值业务场景中，用户调用支付服务充值成功后，支付服务会按照一定的阶梯型通知规则调用账户服务的接口，向账户服务发送支付数据。此时，账户服务的接口需要满足幂等性，这就是幂等操作。如果支付服务调用账户服务的接口超过了设置的最大次数，仍然没有调用成功，则支付服务需要提供查询支付结果的接口，以便账户服务调用并恢复丢失的业务
方案的执行流程
最大努力通知型分布式事务解决方案在执行的过程中，允许丢失消息，但需要业务主动方提供事务状态查询接口，以便业务被动方主动调用并恢复丢失的业务
实现最大努力通知型方案时，需要实现如下功能。
- 业务主动方在完成业务处理后，会向业务被动方发送消息通知。发送消息通加时，允许消息丢失
- 在实现上，业务主动方可以设置时间阶梯型通知规则，在消息通知失败后，可以按照规则再次通知，直到到达最大通知次数为止
- 业务主动方需要提供查询接口供业务被动方按照需要查询，用于恢复丢失的消息
方案的优缺点
最大努力通知型方案存在如下优点：
- 能够实现跨企业的数据一致性。
- 业务被动方的处理结果不会影响业务主动方的处理结果
- 能够快速接入其他业务系统，达到业务数据一致性。
最大努力通知型方案存在如下缺点：
- 只适用于时间敏感度低的场景。
- 业务主动方发送的消息可能丢失，造成业务被动方收不到消息。
- 需要业务主动方提供查询消息的接口，业务被动方需要按照主动方的接口要求查数据，增加了开发成本
需要注意的问题
业务被动方需要保证接收通知的方法的幂等性，关键是要业务主动方通过一定的机最大限度地将业务的处理结果通知给业务被动方，因此必须解决如下两个问题
1、消息重复通知产生的问题：
- 消息重复通知产生的原因：由于业务主动方发送消息通知后，业务被动方不一定能够接收到消息，因此需要一定的阶梯型通知规则重复向业务被动方发送消息通知。此时，就出现了消息重复通情况，因为业务被动方的方法被执行了多次，所以有可能造成数据不一致的问题
- 消息重复通知的解决方案：保证业务被动方接收消息通知的方法具备幂等性，则在业务上就能够解决消息重影知的问题
2、消息通知丢失的问题
- 消息通知丢失问题的原因：如果业务主动方尽最大努力都没有将消息通知给业务被动方，或者业务被动方接收消息并执行完毕后，需要再次获取消息。此时，业务主动方已经删除对应的通知消息,向业务被动方发送消息通知，也就是说，消息通知已经丢失
- 消息通知丢失的解决方案：业务主动方需要提供查询消息的接口来满足业务被动方主动查询消息的需求，以恢复丢失的业务。另外，业务主动方在设计消息回查接口时，一定要注意接口的安全性和并发性
