ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【聚合体系业务场景设计】异步回调先于同步响应，怎么办？ [打印本页]

作者: 慢吞云雾缓吐愁 时间: 2024-11-4 20:15
标题: 【聚合体系业务场景设计】异步回调先于同步响应，怎么办？
以请求三方付款为例，通常是先发起付款请求，然后等待三方异步通知付款结果，或者我方主动调三方查询付款结果。见下方时序表现图。
#我方聚合体系三方支付体系#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，
....

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)