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