分布式事务

[NeoZephyr]

基于事务消息的分布式事务

1. 事务发起者预先发送一个事务消息
2. MQ 系统收到事务消息后，将消息持久化，消息的状态是待发送，并给发送者一个 ACK 消息
3. 事务发起者如果没有收到 ACK 消息，则取消本地事务的执行；如果收到了 ACK 消息，则执行本地事务，并给 MQ 系统再发送一个消息，通知本地事务的执行情况
4. MQ 系统收到消息通知后，根据本地事务的执行情况更改事务消息的状态，如果成功执行，则将消息更改为“可消费”并择机下发给订阅者；如果事务执行失败，则删除该事务消息。
5. 本地事务执行完毕后，发给 MQ 的通知消息有可能丢失了。所以支持事务消息的 MQ 系统有一个定时扫描逻辑，扫描出状态仍然是“待发送”状态的消息，并向消息的发送方发起询问，询问这条事务消息的最终状态如何并根据结果更新事务消息的状态。因此事务的发起方需要给 MQ 系统提供一个事务消息状态查询接口。
6. 如果事务消息的状态是“可发送”，则 MQ 系统向下游参与者推送消息，推送失败会不停重试。
7. 下游参与者收到消息后，执行本地事务，本地事务如果执行成功，则给 MQ 系统发送 ACK 消息；如果执行失败，则不发送 ACK 消息，MQ 系统会持续推送给消息

[NeoZephyr]

基于本地消息的分布式事务

事务的发起方维护一个本地消息表，业务执行和本地消息表的执行处在同一个本地事务中。业务执行成功，则同时记录一条“待发送”状态的消息到本地消息表中。系统中启动一个定时任务定时扫描本地消息表中状态为“待发送”的记录，并将其发送到 MQ 系统中，如果发送失败或者超时，则一直发送，知道发送成功后，从本地消息表中删除该记录。后续的消费订阅流程则与基于事务消息的模式雷同

[NeoZephyr]

最大努力通知型分布式事务

支付宝支付联通话费，操作的流程如下：

选择充值金额，支付宝支付 联通网上营业厅创建一个充值订单，状态为“支付中”，并跳转到支付宝的支付页面 支付宝验明确认小明的支付后，从小明的账户中扣除 50 元，并向联通的账户中增加 50 元。执行完毕后向 MQ 系统发送一条消息，消息的内容标识支付是否成功，消息发送允许失败 如果消息发送成功，那么支付宝的通知服务会订阅到该消息，并调用联通的接口通知本次支付的结果。如果此时联通的服务挂掉了，导致通知失败了，则会按照 5min、10min、30min、1h、...、24h 等递增的时间间隔，间隔性重复调用联通的接口，直到调用成功或者达到预订的时间窗口上限后，则不再通知。这就是尽最大努力通知的含义 如果联通服务恢复正常，收到了支付宝的通知，如果支付成功，则给账户充值；如果支付失败，则取消充值。执行完毕后给支付宝通知服务确认响应，确认响应允许失败，支付宝系统会继续重试。所以联通的充值接口需要保持幂等性。 如果联通服务故障时间很久，恢复正常后，已超出支付宝通知服务的时间窗口，则联通扫描“支付中”的订单，主动向支付宝发起请求，核验订单的支付结果。