【聚合系统业务场景设计】异步回调先于同步响应，怎么办？

这篇文章介绍了【聚合系统业务场景设计】异步回调先于同步响应，怎么办？，分享给大家做个参考，收藏Java资料网收获更多编程知识

以请求三方付款为例，通常是先发起付款请求，然后等待三方异步通知付款结果，或者我方主动调三方查询付款结果。见下方时序示意图。

#	我方聚合系统		三方支付系统
#1	发起付款请求	→	接收付款请求，处理付款
#2.1	接收请求，变更付款状态	←←	付款完成，主动回调
#2.2	主动查单	→	接收查单请求，返回付款状态

 

本文我们谈回调，所以让我们细化一下#1、#2.1，其中包含了付款状态的正常流转。

#	我方聚合系统		三方支付系统
#1	发起付款请求（状态=INIT）	→	接收付款请求，处理付款
	保存同步响应结果 （状态变更 INIT→PAYING）	←	同步响应
#2.1	接收请求，变更付款状态 （状态变更 PAYING→PAY_SUCCESS）	←←	付款完成，主动回调

 

某些三方支付，如支付宝，对于支付宝账户转账业务，处理非常快。 这时，会出现 异步回调 先于 同步响应 的情况。见下方时序示意图。从示意图中可知，回调过来的付款状态将无法得到持久化变更。

#	我方聚合系统		三方支付系统
#1	发起付款请求（状态=INIT）	→	接收付款请求，处理付款
#2.1	接收请求，变更付款状态 （发现前置状态不是PAYING，状态变更失败）	←←	付款完成，主动回调
#1	保存同步响应结果 （状态变更 INIT→PAYING）	←	同步响应

 

 

 

那么，针对这种”异步回调在先，同步响应在后“的情况，应该怎么解决呢？

 

修改状态机。处理回调的方法里，将前置状态由 PAYING 改为 PAYING 和 INIT。

 

如果你这么做的话，那你的得分是0。因为这是一个❎错误姿势。

“看似”解决了问题，但是，会存在

• 安全隐患。--->当回调方法不慎被非正常执行时，会出现”未请求银行，付款状态却被更新成了终态“。
• 程序设计隐患。——这为系统熵增埋下伏笔。--->你在这儿修改了状态机控制，日后，付款交易的其他方法里的状态机控制也会被修改。

 

那么，针对这种”异步回调在先，同步响应在后“的情况，应该怎么解决呢？

easy，

....

 

文章来源:https://www.cnblogs.com/buguge/p/18526176
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！