以请求三方付款为例，通常是先发起付款请求，然后等待三方异步通知付款结果，或者我方主动调三方查询付款结果。见下方时序示意图。
| # | 我方聚合系统 | 三方支付系统 | |
|---|---|---|---|
| #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，
….
© 版权声明
THE END
![表情[baoquan]-拾光赋](https://blogs.ink/wp-content/themes/zibll/img/smilies/baoquan.gif)
暂无评论内容