2019-06-06：支付同步和异步处理关系

支付流程同步和异步处理关系

处理逻辑

同步：指发出一个请求后，需要等待返回，才能进行下一个请求触发，有个等待的过程

异步：指发出一个请求后，不需要等待返回，随时可以触发下一个请求，不需要等待

区别：一个需要等待，一个不需要等待，在部分情况下、有的项目开发中都会优先选择不需要等待的异步交互方式。

哪些情况建议使用同步交互呢？比如银行的转账系统，对数据库的保存操作等等，都会使用同步交互操作，其余情况都优先使用异步交互。

换种方式也可以这样理解：

1.用户（买家）支付完成后，电商平台需要实时的给用户一个通知，如支付已经处理等待订单确认。

2.电商平台，这块就需要考虑系统技术方面的各个环节，考虑应对复杂多变的并发用户量、业务、流量、网络环境等因素，我们需要把可以异步化的任务进行分离，算是保障系统可造性、可用性的一个重要的点。

3.电商网站每秒钟承接1w、5w、10W交易量甚至更高的时候，实时处理这些请求挑战很大，但如果把这些请求分离业务状态实现异步化，放入消息系统、异步准实时环境，进而整体网站的复杂度降低，这就是同步和异步通知存在的意义。
4.第三方支付公司接入文档上都会有以异步通知为准的约束。
5.其实除了通知这块，还有一块会被忽略，就是支付查询类接口，这一块的作用如果用好了，对系统业务层会省很多人力

我们测试一般当完成一个支付请求被发送到支付渠道方，支付渠道会很快返回一个结果。但是这个结果，只是告诉你调用成功了，不是扣款成功，这叫同步调用。很多人拿这个结果当作支付成功了，那就会被坑死，结果就是支付成功率特别高，伴随着一堆无法解释的坏账率，测试人员尤其要注意测试数据的篡改：金额，同步返回结果，订单号等。

同步请求参数里面会有一个回调地址，这个地址是支付渠道在扣款成功后调用的，这叫异步调用。一般同步接口仅检查参数是否正确，签名是否无误等。异步接口才告诉你扣款结果。一般异步接口有5秒以内的延迟。调用不成功会重试。有时候是这边成功了，但支付渠道侧没收到返回，于是会继续调。当天的支付到第二天还在被异步调用也都是正常的。这也是开发人员需要特别注意的地方，不要当做重复支付。测试人员也要对重复回调进行测试，应只有一次有效。这还不是最坑的，一般支付渠道侧，只有支付成功了才通知你。要是支付失败了，压根儿都不告诉你。 另一方面，如何老收不到异步结果呢？那就得查查了。同步结果不可靠，异步调用不可靠，那怎么确定支付结果？最终的杀招就是查单了，反查，一般支付渠道侧都会提供反查接口，定时获取DB中待支付的订单调用支付渠道侧的反查接口，最终把支付渠道侧扣款成功的订单完成掉。