这是一个创建于 990 天前的主题，其中的信息可能已经有所发展或是发生改变。
大佬们，目前我在弄一个类似于自助售货机的东西
流程大概是：机器显示二维码->微信扫码支付->服务器收到微信回调->通知设备支付完成->设备开始工作
服务器通知设备支付完成，这一步该怎么优化比较好,有的地方网络质量不太好
设备数量的话，现在是几十台，过几个月可能会接入一两千台
目前通知设备支付完成，用的是 websocket
大佬们，有没有什么建议..以前一直都是在写 crud😭😭..
 |
1
cheng6563 2022-03-07 14:20:07 +08:00
WebSocket 推送和设备主动轮训一起上。
网络质量实在不好，那也没啥办法啊。 |
 |
2
MoonWalker 2022-03-07 14:22:32 +08:00
重点是确保设备是真的收到了通知，考虑在服务端加消息队列，设备收到通知后再回复给服务端，然后移除消息。
|
 |
3
paradoxs 2022-03-07 14:24:50 +08:00
mq ack
|
 |
4
murmur 2022-03-07 14:31:35 +08:00
有的地方网络质量不太好直接放弃吧，选址是有讲究的
|
 |
5
abc0123xyz OP @murmur #4 这不是我一个农民工能决定的🤣
|
 |
6
Kasumi20 2022-03-07 15:12:14 +08:00
有没有一种可能，用户支付完成后，服务器返回一个二维码，机器装个摄像头扫码，离线验证
|
 |
7
jeeyong 2022-03-07 15:17:54 +08:00
多嘴一下吧. 不知道会不会有帮助
我记得 Google 的那个 bbr 加速内核中有几种模式.. 至少有一种是通过牺牲流量提高连接的稳定性. 我理解的原理就是每次发送请求都冗余发送, 如果对方回复了, 其余的就抛弃.. 这种模式用于网络连接质量差, 但需要稳定的场景.. 上次看介绍举例是航空航天领域. |
 |
8
libook 2022-03-07 15:30:10 +08:00
WebSocket 对网络质量要求会高一些吧，换来的好处是实时性以及双向通信，但你的项目其实不需要太高的实时性，延迟个几秒也是可以接受的，双向通信也可以用轮询来代替。
现在不少 IoT 项目都是用消息队列来削峰填谷，你可以把交易的每个步骤做成队列，每个步骤都有校验机制和重试机制，再加一些回滚机制，来尽可能提高可靠性。 |
 |
9
registerrr 2022-03-07 15:35:43 +08:00
MQTT QoS=1
|
 |
10
RedBeanIce 2022-03-07 15:49:08 +08:00
ack
|
 |
11
zmal 2022-03-08 12:01:29 +08:00
你的需求对实时性要求不高，“通知设备支付完成”改成设备轮询支付确认接口。网络不好的问题，接口请求限制到一个 MTU(1500)，减少拆包重传之类的网络问题。
|
 |
12
jazzg62 2022-03-08 16:58:36 +08:00
mqtt 正解
|
|
13
jazzg62 2022-03-08 16:59:13 +08:00
mqtt 正解，而且算是比较很成熟的方案了
|
Select Language