场景：用户在扫码支付成功后，第三方支付方会异步回调本系统内的一个地址，希望收到回调返回成功后，给前端发送 您已支付成功订单 xx 元！
之前没做过消息发送到前端这方面的，想请教下简单的或者常用的做法是什么，就用 websocket ？ 现在后台是 springboot，前端是 ios
This topic created in 2273 days ago, the information mentioned may be changed or developed.
Supplement 1 · Aug 17, 2020
嗯 这个系统是给客户端 ios 用的
 |
juzzleAug 17, 2020
1
刷新一下页面，请求下后端 获取一下支付结果就好了
|
 |
aogu555Aug 17, 2020
2
扫码支付的话一般是让前端做个定时器轮询，不断发请求查询支付状态
|
 |
kkkkkruaAug 17, 2020
3
别想着同步的方案，前端轮询就行
|
 |
janxinAug 17, 2020
4
websocket, long polling
|
 |
dadaoqueyiAug 17, 2020
5
websocket (emq)
|
 |
TomatoYuyukoAug 17, 2020
6
轮询成本最低
|
 |
lyusantuAug 17, 2020
7
免费就前端轮询，图方便就买服务，如果量不大的话，GoEazy 还挺方便
|
 |
pauleeAug 17, 2020
8
你是想做消息推送吗？一般情况下，前端轮询就行（前端注意轮询频率和边界判断，别写 Bug 把服务器爆了
|
 |
WaldenHorizonAug 17, 2020
9
支付场景轮询就好了，不需要长期推消息
|
 |
xuanbgAug 17, 2020
10
一般异步结果前端轮询即可
|
 |
LongMaozAug 17, 2020
11
轮询就行了，上 WebSocket 也行
|
 |
devliu1Aug 17, 2020
12
轮询、SSE 、WS 都可以
|
 |
xkeyidealAug 17, 2020
13
拉倒最后一个评论才说出最好的方式，sse 啊，一个半双工的场景，用 ws 干啥，轮询那么浪费资源，考虑一下服务端压力呢
|
 |
ky11223344Aug 17, 2020
14
可以试试 server sent events, 看下 js 的 EventSource API
|
 |
liuzhaowei55Aug 17, 2020 via iPhone
15
前端倒数 5 秒然后到后台查询结果，现在大部分都是这个操作吧
|
 |
fhsanAug 17, 2020
16
eventsource
|
 |
wc951Aug 17, 2020 via Android
17
有一项远古的技术叫 dwr
|
 |
yingqi7Aug 17, 2020 via iPhone
18
感觉大家都前端轮询，或者用户刷新返回消息
|
 |
sujin190Aug 17, 2020
19
这种等待时间不会很长的，合适的做法还是 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 被激活了也就是支付完成，前端等待会立刻收到反馈返回，搞定 |
 |
berlin4hAug 17, 2020
20
1 、支付页面生成一个唯一标识
2 、付款成功后支付页面服务端发起请求，查询唯一标识是否支付成功 3 、服务器收到请求，查询。如果未支付，进入等待(wait)，不立即返回 4 、一旦收到第三方通知支付成功，立即返回(notify) 5 、页面收到结果，做后续处理 步骤大概如此，但是有个问题，步骤 2 如果请求超时，如何处理？处理方式是，一段时间没有扫描后，后端返回 timeout，前端重新发起一个相同的网络请求 |
 |
ebony0319Aug 17, 2020
21
|
 |
BBCCBBAug 17, 2020
22
场景简单的话 server sent events 应该是简单靠谱的方案. 好像 twitter 都在用.
|
 |
23
|
2 |
edk24Aug 17, 2020
24
只有这一个场景的话 可以考虑轮询
二维码扫码登录也是用的轮询 |
 |
dallasluAug 17, 2020
25
轮询最简单，但是短轮询有可能有一点延迟感。长轮询会好一些。Spring Boot 用可以换 Undertow，用上 WebAsyncTask
|
 |
gitjavascriptAug 17, 2020
26
这种东西轮询就好了，没必要搞麻烦的
|
 |
wysnylcAug 17, 2020
27
websocket-socketio
不要使用 http 轮询,不及时而且浪费资源,最终还是得升级成 websocket 还不如一步到位 |
 |
zachlhbAug 17, 2020 via Android
28
iOS 可以做推送，APP 上收到推送后进行相应的处理
|
 |
29
long polling 的性能并不比轮询好
|
 |
OHynAug 17, 2020
30
轮循最简单，有点追求就上 websocket
|
|
OHynAug 17, 2020
31
对了，还有 server sent events，这个最合适。
|
 |
bagelAug 17, 2020
32
说 Server Sent Events 的，没看到是 iOS 吗。都不在浏览器里。
|
 |
las917vkiAug 17, 2020
33
長轮询就行了。
|
 |
spritAug 17, 2020
34
不能叫前端叫客户端
|
 |
BoarBoarAug 17, 2020
35
轮询实现简单，性能低。ws 性能高但实现相对复杂，特别是如果其他场景都是 http 的话，需要重写一些组件比如鉴权，为了一个性能要求不高的场景显然是不划算的
|
|
devliu1Aug 17, 2020
36
补充一下，SSE 只是一种传输方式，和浏览器没有必然的联系。
|
 |
ccraohngAug 18, 2020 via Android
37
观察 大厂们相关服务，云后台，类似的都是轮训。性能低从何谈起
|
 |
Nich0la5Aug 18, 2020 via Android
38
虽然轮训的确性能低，但大厂都在用
|
 |
pkoukkAug 18, 2020
39
这种情况就是典型的轮询
|
 |
CantSeeAug 18, 2020
40
必然是轮询!让他循环查询,间隔个一两秒!
|
 |
2506810Aug 18, 2020
44
这种情况下当然是轮询了，用了 websocket 的话技术复杂度增加，而且 nginx 配置还得改
|
|
2506810Aug 18, 2020
45
轮询技术难度低方便扩展，而且你看微信公众号或阿里云二维码登录都是 2 秒一次轮询后台的
|
 |
admingyuAug 18, 2020
46
只是这个场景没必要 websocket，就每隔两秒请求一次服务器该订单的支付状态，有结果之后跳转就行了
|
 |
wyz123723Aug 18, 2020
47
setinterval 循环完事儿了
|
 |
evamAug 18, 2020
48
小程序不支持 Server-sent events 。
https://developers.weixin.qq.com/community/develop/doc/000e0e0bba0720a167a8c5cfa56000 |
 |
liKeYunKejiAug 18, 2020
49
定时轮询，例如 2 秒请求一次支付结果
1 、发起支付请求，向数据库创建订单，标记为未支付 2 、支付成功后，异步发送支付结果，更新订单，标记为已支付 3 、轮询当前订单的支付状态 |
 |
justin2018Aug 18, 2020
50
我已支付 支付遇到问题 两个按钮 😁
|
 |
stevenkangAug 18, 2020
51
网商银行还款，之前操作后界面上立马就有反应，现在倒计时 5 秒后才有结果，你猜为什么。
|
 |
DoUSeeMeAug 18, 2020
52
心跳机制了解一下
|
Select Language