【聚合体系业务场景设计】异步回调先于同步响应，怎么办？
以请求三方付款为例，通常是先发起付款请求，然后等待三方异步通知付款结果，或者我方主动调三方查询付款结果。见下方时序表现图。#我方聚合体系 三方支付体系#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企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]