支付回调场景方案

目录

支付回调

​编辑

问题：如何知道用户是否支付成功呢？

1. 支付宝主动发起的支付通知

2. 接入方主动回查支付结果

列举下常见的主动回查支付结果的方案：

1. 前端界面定时主动短轮询回查几次支付结果

2. 长轮询机制

3. WebSocket机制

---

支付回调

在现有支付体系下，项目想使用支付功能，都需要对接类似于支付宝 微信 聚合支付这种第三方公司，那我们系统如何知道用户是否真的付款了呢？

先来看看支付宝手机网站支付的流程图

问题：如何知道用户是否支付成功呢？

        首先要知道的是有什么方式可以获取到支付结果，拿支付宝举例 平台提供了两种方式以供我们获取到支付结果，如上图所示分别为：

1. 支付宝主动发起的支付通知

        固定时间固定频率推送

2. 接入方主动回查支付结果

        在平台上购买商品，用户付款结束后一般都会在支付界面停留一小段时间 就会显示支付成功，这段时间系统发生了什么？

---

列举下常见的主动回查支付结果的方案：

1. 前端界面定时主动短轮询回查几次支付结果

        这里查询有两种：一种是只查询自己系统状态，一种是穿透到支付渠道方去查支付宝实时状态

        查询自己系统订单状态 相较于 每次都穿透到支付渠道查询实时状态，性能要更好，但是实时性、用户体验感要稍差

        无论是哪种查询，如果同时支付的用户较多，会出现高并发场景，从而对后台服务造成一定压力

        优化方案：可设置前端查询间隔的频率，做多轮轮询[例如支付成功后1s 3s 5s 7s 10s查询]，如还是未查询到最终兜底界面兼顾用户体验感

---

2. 长轮询机制

流程：

        1. 将请求和响应暂存起来，此时请求是被hold住的，并没有响应给客户端
        2. 会释放掉tomcat的⼯作线程，提升tomcat的并发处理能⼒
        3. 异步执⾏完成后，把结果set进去，同时响应给客户端
        4. tomcat有⼀个超时检测，如果异步执⾏太久了，也会超时的。会触发超时响应的那个方法

优点：

        通过DeferredResult将耗时的业务从tomcat⼯作线程中剥离，这样释放了tomcat的⼯作线 程，提升了tomcat的处理能⼒

缺点：

        主流浏览器最多支持同时6个连接，长轮询消耗了一个，会导致网页加载速度变慢，这种技术有弊端

        注：Apollo、Nacos等知名平台都有用到长轮询机制

---

3. WebSocket机制

        上面两个方案其实本质都是轮询，他们都有的问题是：带来很多无谓请求，浪费带宽，效率低下，而WebSocket它实现了浏览器与服务器全双工通信，被誉为Web TCP

        只需要客户端与服务端通过握手连接成功后，一旦订单支付结果发生变化，可以及时通知到具体的用户

        注：长轮询机制、WebSocket机制都需要解决集群环境下的问题，可参考：WebSocket集群解决方案-CSDN博客

---

可以根据自身业务特性权衡下各方案的优劣从而进行选择

参考资料：

IT好友：Zeng.X.Y

DeferredResult 如何实现长轮询？ (qq.com)