阿里Java二面：了解分布式事务？说说最大努力通知及RocketMQ实现
文章目录
- 分布式事务解决方案之最大努力通知
- 什么是最大努力通知
- 交互流程:
- 通过上边的例子我们总结最大努力通知方案的目标：
- 最大努力通知与可靠消息一致性有什么不同？
- 1、解决方案思想不同
- 2、两者的业务应用场景不同
- 3、技术解决方向不同
- 解决方案
- 方案1：
- 方案2：
- RocketMQ实现最大努力通知型事务
- 业务说明
- 业务流程如下图：
- 交互流程如下：
- 总结
分布式事务解决方案之最大努力通知
什么是最大努力通知
最大努力通知也是一种解决分布式事务的方案，下边是一个是充值的例子：
交互流程:
- 账户系统调用充值系统接口
- 充值系统完成支付处理向账户系统发起充值结果通知若通知失败，则充值系统按策略进行重复通知
- 账户系统接收到充值结果通知修改充值状态。
- 账户系统未接收到通知会主动调用充值系统的接口查询充值结果。
通过上边的例子我们总结最大努力通知方案的目标：
目标： 发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
具体包括：
1、有一定的消息重复通知机制。 因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
2、消息校对机制。 如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
最大努力通知与可靠消息一致性有什么不同？
1、解决方案思想不同
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
2、两者的业务应用场景不同
可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。
最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
3、技术解决方向不同
可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。
最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。
解决方案
通过对最大努力通知的理解，采用MQ的ack机制就可以实现最大努力通知。
方案1：
本方案是利用MQ的ack机制由MQ向接收通知方发送通知，流程如下：
- 发起通知方将通知发给MQ。（使用普通消息机制将通知发给MQ。注意： 如果消息没有发出去可由接收通知方主动请求发起通知方查询业务执行结果。）
- 接收通知方监听 MQ。
- 接收通知方接收消息，业务处理完成回应ack。
- 接收通知方若没有回应ack则MQ会重复通知。（MQ会按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔（如果MQ采用rocketMq，在broker中可进行配置），直到达到通知要求的时间窗口上限。）
- 接收通知方可通过消息校对接口来校对消息的一致性。
方案2：
本方案也是利用MQ的ack机制，与方案1不同的是应用程序向接收通知方发送通知，如下图：
交互流程如下：
- 发起通知方将通知发给MQ。使用可靠消息一致方案中的事务消息保证本地事务与消息的原子性，最终将通知先发给MQ。
- 通知程序监听 MQ，接收MQ的消息。方案1中接收通知方直接监听MQ，方案2中由通知程序监听MQ。通知程序若没有回应ack则MQ会重复通知。
- 通知程序通过互联网接口协议（如http、webservice）调用接收通知方案接口，完成通知。通知程序调用接收通知方案接口成功就表示通知成功，即消费MQ消息成功，MQ将不再向通知程序投递通知消息。
- 接收通知方可通过消息校对接口来校对消息的一致性。
方案1和方案2的不同点：
- 方案1中接收通知方与MQ接口，即接收通知方案监听 MQ，此方案主要应用与内部应用之间的通知。
- 方案2中由通知程序与MQ接口，通知程序监听MQ，收到MQ的消息后由通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。
RocketMQ实现最大努力通知型事务
业务说明
本实例通过RocketMq中间件实现最大努力通知型分布式事务，模拟充值过程。
本案例有账户系统和充值系统两个微服务，其中账户系统的数据库是bank1数据库，其中有张三账户。充值系统的数据库使用bank1_pay数据库，记录了账户的充值记录。
业务流程如下图：
交互流程如下：
- 用户请求充值系统进行充值。
- 充值系统完成充值将充值结果发给MQ。
- 账户系统监听MQ，接收充值结果通知，如果接收不到消息，MQ会重复发送通知。接收到充值结果通知账户系统增加充值金额。
- 账户系统也可以主动查询充值系统的充值结果查询接口，增加金额。
创建数据库
导入数据库脚本：sql\bank1.sql、资料\sql\bank1_pay.sql，已经导过不用重复导入。
创建bank1库，并导入以下表结构和数据(包含张三账户)
创建bank1_pay库，并导入以下表结构：
启动RocketMQ
rocketmq启动方式与RocketMQ实现可靠消息最终一致性事务中完全一致
discover-server
discover-server是服务注册中心，测试工程将自己注册至discover-server。
导入：资料\基础代码\dtx 父工程，此工程自带了discover-server，discover-server基于Eureka实现。已经导过不用重复导入。
导入dtx-notifymsg-demo
dtx-notifymsg-demo是本方案的测试工程，根据业务需求需要创建两个dtx-notifymsg-demo工程。
（1）导入dtx-notifymsg-demo导入：资料\基础代码\dtx-notifymsg-demo到父工程dtx下。
两个测试工程如下：
dtx/dtx-notifymsg-demo/dtx-notifymsg-demo-bank1 ，操作张三账户，连接数据库bank1
dtx/dtx-notifymsg-demo/dtx-notifymsg-demo-pay，操作李四账户，连接数据库bank1_pay
（2）父工程maven依赖说明
在dtx父工程中指定了SpringBoot和SpringCloud版本
在dtx-notifymsg-demo父工程中指定了
rocketmq-spring-boot-starter的版本。
( 3 ) 配置rocketMQ
在
application-local.propertis中配置rocketMQ nameServer地址及生产组：
rocketmq.producer.group = producer_bank2 rocketmq.name‐server = 127.0.0.1:9876
dtx-notifydemo-pay
dtx-notifydemo-pay实现如下功能：
- 充值接口
- 充值完成要通知
- 充值结果查询接口
2）Dao
3）Service
4）Controller
dtx-notifydemo-bank1
dtx-notifydemo-bank1实现如下功能：
- 监听MQ，接收充值结果，根据充值结果完成账户金额修改。
- 主动查询充值系统，根据充值结果完成账户金额修改。
1）Dao
2）AccountInfoService
3）监听MQ
4）Controller
测试场景
- 充值系统充值成功，账户系统主动查询充值结果，修改账户金额。
- 充值系统充值成功，发送消息，账户系统接收消息，修改账户金额。
- 账户系统修改账户金额幂等测试。
总结
最大努力通知方案是分布式事务中对一致性要求最低的一种,适用于一些最终一致性时间敏感度低的业务；
最大努力通知方案需要实现如下功能：
- 消息重复通知机制。
- 消息校对机制。