预支付和支付完成回调的并发问题
- 第一步，支付服务，预支付；
- 第二步，调用第三方支付平台，发起支付；
- 第三步，支付完成回调，通知订单服务；
用户重复点击支付，预支付检查订单状态，此时支付回调还没处理完成，并发情况下导致重复支付；
基于 Redission 分布式锁处理重复支付问题；
支付完成回调处理业务问题分析
支付服务通知订单服务，订单支付完成
- 第一步，订单服务更新订单状态“已支付”，发送 "订单支付成功" 消息；
- 第二步，订单服务的内部维护的消费者后台线程，消费处理 "订单支付成功" 消息，通知履约服务，订单已经支付完成；
- 第三步，更新订单状态“已履约”；
基于RocketMQ的延迟机制和死信机制，保证说消息一定可以消费成功，通知履约服务；
思考一下，如果发送“订单支付成功”消息没有问题，更新订单支付状态故障？？？
关于如何保证说更新订单支付状态和发送“订单支付成功”消息的强一致性，可以基于RocketMQ的事务特性；
触发订单履约双异步设计优化
思考一下，如何优化支付完成回调处理逻辑，比如通知履约机制，同步通知改为异步通知；
双异步模式设计，同步调用履约服务改为发送“触发订单履约”消息，异步通知，进一步提升系统性能；
关于如何保证订单服务“订单支付成功”消息的消费者，发送“触发订单履约”消息和更新订单履约状态的事务特性，可以基于RocketMQ的事务特性；
事务消息原理分析
- 第一步，发送 half 消息；
- 第二步，half 消息响应，如果失败，抛出异常，等待后面调用方再次调用；
- 第三步，half 消息响应，如果成功，执行本地事务，本地事务执行成功，提交消息；
- 第四步，half 消息响应，如果成功，执行本地事务，本地事务执行失败，回滚消息，删除消息；
- 第五步，消息提交成功，执行后续业务逻辑；
- 第六步，网络故障或者系统崩溃，RocketMQ 服务端回查事务状态，决定提交消息还是删除消息；
