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