场景：用户在扫码支付成功后，第三方支付方会异步回调本系统内的一个地址，希望收到回调返回成功后，给前端发送 您已支付成功订单 xx 元！
之前没做过消息发送到前端这方面的，想请教下简单的或者常用的做法是什么，就用 websocket ？ 现在后台是 springboot，前端是 ios
This topic created in 2111 days ago, the information mentioned may be changed or developed.
Supplement 1 Aug 17, 2020
嗯 这个系统是给客户端 ios 用的
 | 1 juzzle Aug 17, 2020 刷新一下页面，请求下后端 获取一下支付结果就好了 |
 | 2 aogu555 Aug 17, 2020 扫码支付的话一般是让前端做个定时器轮询，不断发请求查询支付状态 |
 | 3 kkkkkrua Aug 17, 2020 别想着同步的方案，前端轮询就行 |
 | 4 janxin Aug 17, 2020 websocket, long polling |
 | 5 dadaoqueyi Aug 17, 2020 websocket (emq) |
 | 6 TomatoYuyuko Aug 17, 2020 轮询成本最低 |
 | 7 lyusantu Aug 17, 2020 免费就前端轮询，图方便就买服务，如果量不大的话，GoEazy 还挺方便 |
 | 8 paulee Aug 17, 2020 你是想做消息推送吗？一般情况下，前端轮询就行（前端注意轮询频率和边界判断，别写 Bug 把服务器爆了 |
 | 9 wangritian Aug 17, 2020 支付场景轮询就好了，不需要长期推消息 |
 | 10 xuanbg Aug 17, 2020 一般异步结果前端轮询即可 |
 | 11 LongMaoz Aug 17, 2020 轮询就行了，上 WebSocket 也行 |
 | 12 devliu1 Aug 17, 2020 轮询、SSE 、WS 都可以 |
 | 13 xkeyideal Aug 17, 2020 拉倒最后一个评论才说出最好的方式，sse 啊，一个半双工的场景，用 ws 干啥，轮询那么浪费资源，考虑一下服务端压力呢 |
 | 14 ky11223344 Aug 17, 2020 可以试试 server sent events, 看下 js 的 EventSource API |
 | 15 liuzhaowei55 Aug 17, 2020 via iPhone 前端倒数 5 秒然后到后台查询结果，现在大部分都是这个操作吧 |
 | 16 fhsan Aug 17, 2020 eventsource |
 | 17 wc951 Aug 17, 2020 via Android 有一项远古的技术叫 dwr |
 | 18 yingqi7 Aug 17, 2020 via iPhone 感觉大家都前端轮询，或者用户刷新返回消息 |
 | 19 sujin190 Aug 17, 2020 这种等待时间不会很长的，合适的做法还是 ajax 请求后保持直到有数据或者超时，要实现保持也有很多方法，比如 redis 的 pubsub，zookeeper，或者用分布式锁服务啥的都很方便，websocket 会复杂一些，也需要单独长连接处理服务才能支持，不能直接在 web 中实现成一个 rest api https://github.com/snower/slock 用 go 实现过这样一个锁服务，分布式 Event 的语义也很简单，使用支付 ID 为 key，已 1 为 lock_id 在创建订单的时候锁住，前端等待的时候尝试 2 为 lock_id 获取锁，异步通知的时候释放 lock_id 为 1 的锁，这时候 lock_id 为 2 的获取成功就代表这个分布式 Event 被激活了也就是支付完成，前端等待会立刻收到反馈返回，搞定 |
 | 20 berlin4h Aug 17, 2020 1 、支付页面生成一个唯一标识 2 、付款成功后支付页面服务端发起请求，查询唯一标识是否支付成功 3 、服务器收到请求，查询。如果未支付，进入等待(wait)，不立即返回 4 、一旦收到第三方通知支付成功，立即返回(notify) 5 、页面收到结果，做后续处理 步骤大概如此，但是有个问题，步骤 2 如果请求超时，如何处理？处理方式是，一段时间没有扫描后，后端返回 timeout，前端重新发起一个相同的网络请求 |
 | 21 ebony0319 Aug 17, 2020 |
 | 22 BBCCBB Aug 17, 2020 场景简单的话 server sent events 应该是简单靠谱的方案. 好像 twitter 都在用. |
 | 23 rf99wSiT6IxH1Z23 Aug 17, 2020  2 |
 | 24 edk24 Aug 17, 2020 只有这一个场景的话 可以考虑轮询 二维码扫码登录也是用的轮询 |
 | 25 dallaslu Aug 17, 2020 轮询最简单，但是短轮询有可能有一点延迟感。长轮询会好一些。Spring Boot 用可以换 Undertow，用上 WebAsyncTask |
 | 26 gitJavascript Aug 17, 2020 这种东西轮询就好了，没必要搞麻烦的 |
 | 27 wysnylc Aug 17, 2020 websocket-socketio 不要使用 http 轮询,不及时而且浪费资源,最终还是得升级成 websocket 还不如一步到位 |
 | 28 zachlhb Aug 17, 2020 via Android iOS 可以做推送，APP 上收到推送后进行相应的处理 |
 | 29 zhlssg Aug 17, 2020 1 long polling 的性能并不比轮询好 |
 | 30 OHyn Aug 17, 2020 轮循最简单，有点追求就上 websocket |
| 31 OHyn Aug 17, 2020 对了，还有 server sent events，这个最合适。 |
 | 32 bagel Aug 17, 2020 说 Server Sent Events 的，没看到是 iOS 吗。都不在浏览器里。 |
 | 33 las917vki Aug 17, 2020 轮询就行了。 |
 | 34 sprit Aug 17, 2020 不能叫前端叫客户端 |
 | 35 BoarBoar Aug 17, 2020 轮询实现简单，性能低。ws 性能高但实现相对复杂，特别是如果其他场景都是 http 的话，需要重写一些组件比如鉴权，为了一个性能要求不高的场景显然是不划算的 |
| 36 devliu1 Aug 17, 2020 补充一下，SSE 只是一种传输方式，和浏览器没有必然的联系。 |
 | 37 ccraohng Aug 18, 2020 via Android 观察 大厂们相关服务，云后台，类似的都是轮训。性能低从何谈起 |
 | 38 Nich0la5 Aug 18, 2020 via Android 虽然轮训的确性能低，但大厂都在用 |
 | 39 pkoukk Aug 18, 2020 这种情况就是典型的轮询 |
 | 40 CantSee Aug 18, 2020 必然是轮询!让他循环查询,间隔个一两秒! |
 | 44 2506810 Aug 18, 2020 这种情况下当然是轮询了，用了 websocket 的话技术复杂度增加，而且 nginx 配置还得改 |
| 45 2506810 Aug 18, 2020 轮询技术难度低方便扩展，而且你看微信公众号或阿里云二维码登录都是 2 秒一次轮询后台的 |
 | 46 admingyu Aug 18, 2020 只是这个场景没必要 websocket，就每隔两秒请求一次服务器该订单的支付状态，有结果之后跳转就行了 |
 | 47 wyz123723 Aug 18, 2020 setinterval 循环完事儿了 |
 | 48 evam Aug 18, 2020 小程序不支持 Server-sent events 。 https://developers.weixin.qq.com/community/develop/doc/000e0e0bba0720a167a8c5cfa56000 |
 | 49 liKeYunKeji Aug 18, 2020 定时轮询，例如 2 秒请求一次支付结果 1 、发起支付请求，向数据库创建订单，标记为未支付 2 、支付成功后，异步发送支付结果，更新订单，标记为已支付 3 、轮询当前订单的支付状态 |
 | 50 justin2018 Aug 18, 2020 我已支付 支付遇到问题 两个按钮 |
 | 51 stevenkang Aug 18, 2020 网商银行还款，之前操作后界面上立马就有反应，现在倒计时 5 秒后才有结果，你猜为什么。 |
 | 52 DoUSeeMe Aug 18, 2020 心跳机制了解一下 |
Select Language