请教一般后端发送给前端消息该怎么实现

[rqxiao]

场景：用户在扫码支付成功后，第三方支付方会异步回调本系统内的一个地址，希望收到回调返回成功后，给前端发送 您已支付成功订单 xx 元！

之前没做过消息发送到前端这方面的，想请教下简单的或者常用的做法是什么，就用 websocket ？ 现在后台是 springboot，前端是 ios

嗯 这个系统是给客户端 ios 用的

[juzzle]

刷新一下页面，请求下后端 获取一下支付结果就好了

[aogu555]

扫码支付的话一般是让前端做个定时器轮询，不断发请求查询支付状态

[kkkkkrua]

别想着同步的方案，前端轮询就行

[janxin]

websocket, long polling

[dadaoqueyi]

websocket (emq)

[TomatoYuyuko]

轮询成本最低

[lyusantu]

免费就前端轮询，图方便就买服务，如果量不大的话，GoEazy 还挺方便

[paulee]

你是想做消息推送吗？一般情况下，前端轮询就行（前端注意轮询频率和边界判断，别写 Bug 把服务器爆了

[wangritian]

支付场景轮询就好了，不需要长期推消息

[xuanbg]

一般异步结果前端轮询即可

[LongMaoz]

轮询就行了，上 WebSocket 也行

[devliu1]

轮询、SSE 、WS 都可以

[xkeyideal]

拉倒最后一个评论才说出最好的方式，sse 啊，一个半双工的场景，用 ws 干啥，轮询那么浪费资源，考虑一下服务端压力呢

[ky11223344]

可以试试 server sent events, 看下 js 的 EventSource API

[liuzhaowei55]

前端倒数 5 秒然后到后台查询结果，现在大部分都是这个操作吧

[fhsan]

eventsource

[wc951]

有一项远古的技术叫 dwr

[yingqi7]

感觉大家都前端轮询，或者用户刷新返回消息

[sujin190]

这种等待时间不会很长的，合适的做法还是 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 被激活了也就是支付完成，前端等待会立刻收到反馈返回，搞定

[berlin4h]

1 、支付页面生成一个唯一标识
2 、付款成功后支付页面服务端发起请求，查询唯一标识是否支付成功
3 、服务器收到请求，查询。如果未支付，进入等待(wait)，不立即返回
4 、一旦收到第三方通知支付成功，立即返回(notify)
5 、页面收到结果，做后续处理
步骤大概如此，但是有个问题，步骤 2 如果请求超时，如何处理？处理方式是，一段时间没有扫描后，后端返回 timeout，前端重新发起一个相同的网络请求

[ebony0319]

mqtt,轮询 https://cn.aliyun.com/product/mq4iot

[BBCCBB]

场景简单的话 server sent events 应该是简单靠谱的方案. 好像 twitter 都在用.

[rf99wSiT6IxH1Z23]

三种方案：
1. Long polling
2. WebSocket
3. Server Sent Events

链接地址： https://javascript.info/

正好我也有类似需求

[edk24]

只有这一个场景的话 可以考虑轮询

二维码扫码登录也是用的轮询

[dallaslu]

轮询最简单，但是短轮询有可能有一点延迟感。长轮询会好一些。Spring Boot 用可以换 Undertow，用上 WebAsyncTask

[gitjavascript]

这种东西轮询就好了，没必要搞麻烦的

[wysnylc]

websocket-socketio
不要使用 http 轮询,不及时而且浪费资源,最终还是得升级成 websocket 还不如一步到位

[zachlhb]

iOS 可以做推送，APP 上收到推送后进行相应的处理

[zhlssg]

long polling 的性能并不比轮询好

[OHyn]

轮循最简单，有点追求就上 websocket

[OHyn]

对了，还有 server sent events，这个最合适。

[bagel]

说 Server Sent Events 的，没看到是 iOS 吗。都不在浏览器里。

[las917vki]

長轮询就行了。

[sprit]

不能叫前端叫客户端

[BoarBoar]

轮询实现简单，性能低。ws 性能高但实现相对复杂，特别是如果其他场景都是 http 的话，需要重写一些组件比如鉴权，为了一个性能要求不高的场景显然是不划算的

[devliu1]

补充一下，SSE 只是一种传输方式，和浏览器没有必然的联系。

[ccraohng]

观察 大厂们相关服务，云后台，类似的都是轮训。性能低从何谈起

[Nich0la5]

虽然轮训的确性能低，但大厂都在用

[pkoukk]

这种情况就是典型的轮询

[CantSee]

必然是轮询!让他循环查询,间隔个一两秒!

[CantSee]

@xkeyideal 是 IOS 不是 H5

[xkeyideal]

@CantSee 看一下楼主补充的时间与我回复的时间

[linxb]

@Nich0la5 simple is best 轮训最可靠

[2506810]

这种情况下当然是轮询了，用了 websocket 的话技术复杂度增加，而且 nginx 配置还得改

[2506810]

轮询技术难度低方便扩展，而且你看微信公众号或阿里云二维码登录都是 2 秒一次轮询后台的

[admingyu]

只是这个场景没必要 websocket，就每隔两秒请求一次服务器该订单的支付状态，有结果之后跳转就行了

[wyz123723]

setinterval 循环完事儿了

[evam]

小程序不支持 Server-sent events 。
https://developers.weixin.qq.com/community/develop/doc/000e0e0bba0720a167a8c5cfa56000

[liKeYunKeji]

定时轮询，例如 2 秒请求一次支付结果
1 、发起支付请求，向数据库创建订单，标记为未支付
2 、支付成功后，异步发送支付结果，更新订单，标记为已支付
3 、轮询当前订单的支付状态

[justin2018]

我已支付 支付遇到问题 两个按钮 😁

[stevenkang]

网商银行还款，之前操作后界面上立马就有反应，现在倒计时 5 秒后才有结果，你猜为什么。

[DoUSeeMe]

心跳机制了解一下