<!------------处理逻辑----------------------------------------------------------------->
同步:指发出一个请求后,需要等待返回,才能进行下一个请求触发,有个等待的过程
异步:指发出一个请求后,不需要等待返回,随时可以触发下一个请求,不需要等待
区别:一个需要等待,一个不需要等待,在部分情况下、有的项目开发中都会优先选择不需要等待的异步交互方式。
哪些情况建议使用同步交互呢?比如银行的转账系统,对数据库的保存操作等等,都会使用同步交互操作,其余情况都优先使用异步交互。
换种方式也可以这样理解:
1.用户(买家)支付完成后,电商平台需要实时的给用户一个通知,如支付已经处理等待订单确认。
2.电商平台,这块就需要考虑系统技术方面的各个环节,考虑应对复杂多变的并发用户量、业务、流量、网络环境等因素,我们需要把可以异步化的任务进行分离,算是保障系统可造性、可用性的一个重要的点。
3.电商网站每秒钟承接1w、5w、10W交易量甚至更高的时候,实时处理这些请求挑战很大,但如果把这些请求分离业务状态实现异步化,放入消息系统、异步准实时环境,进而整体网站的复杂度降低,这就是同步和异步通知存在的意义。
4.第三方支付公司接入文档上都会有以异步通知为准的约束。
5.其实除了通知这块,还有一块会被忽略,就是支付查询类接口,这一块的作用如果用好了,对系统业务层会省很多人力
我们测试一般当完成一个支付请求被发送到支付渠道方,支付渠道会很快返回一个结果。但是这个结果,只是告诉你调用成功了,不是扣款成功,这叫同步调用。很多人拿这个结果当作支付成功了,那就会被坑死,结果就是支付成功率特别高,伴随着一堆无法解释的坏账率,测试人员尤其要注意测试数据的篡改:金额,同步返回结果,订单号等。
同步请求参数里面会有一个回调地址,这个地址是支付渠道在扣款成功后调用的,这叫异步调用。一般同步接口仅检查参数是否正确,签名是否无误等。异步接口才告诉你扣款结果。一般异步接口有5秒以内的延迟。调用不成功会重试。有时候是这边成功了,但支付渠道侧没收到返回,于是会继续调。当天的支付到第二天还在被异步调用也都是正常的。这也是开发人员需要特别注意的地方,不要当做重复支付。测试人员也要对重复回调进行测试,应只有一次有效。这还不是最坑的,一般支付渠道侧,只有支付成功了才通知你。要是支付失败了,压根儿都不告诉你。 另一方面,如何老收不到异步结果呢?那就得查查了。同步结果不可靠,异步调用不可靠,那怎么确定支付结果?最终的杀招就是查单了,反查,一般支付渠道侧都会提供反查接口,定时获取DB中待支付的订单调用支付渠道侧的反查接口,最终把支付渠道侧扣款成功的订单完成掉。