求教一个问题

[abc0123xyz]

大佬们，目前我在弄一个类似于自助售货机的东西

流程大概是：机器显示二维码->微信扫码支付->服务器收到微信回调->通知设备支付完成->设备开始工作

服务器通知设备支付完成，这一步该怎么优化比较好,有的地方网络质量不太好

设备数量的话，现在是几十台，过几个月可能会接入一两千台

目前通知设备支付完成，用的是 websocket

大佬们，有没有什么建议..以前一直都是在写 crud😭😭..

[cheng6563]

WebSocket 推送和设备主动轮训一起上。
网络质量实在不好，那也没啥办法啊。

[MoonWalker]

重点是确保设备是真的收到了通知，考虑在服务端加消息队列，设备收到通知后再回复给服务端，然后移除消息。

[paradoxs]

mq ack

[murmur]

有的地方网络质量不太好直接放弃吧，选址是有讲究的

[abc0123xyz]

@murmur #4 这不是我一个农民工能决定的🤣

[Kasumi20]

有没有一种可能，用户支付完成后，服务器返回一个二维码，机器装个摄像头扫码，离线验证

[jeeyong]

多嘴一下吧. 不知道会不会有帮助
我记得 Google 的那个 bbr 加速内核中有几种模式..
至少有一种是通过牺牲流量提高连接的稳定性.
我理解的原理就是每次发送请求都冗余发送, 如果对方回复了, 其余的就抛弃..
这种模式用于网络连接质量差, 但需要稳定的场景..
上次看介绍举例是航空航天领域.

[libook]

WebSocket 对网络质量要求会高一些吧，换来的好处是实时性以及双向通信，但你的项目其实不需要太高的实时性，延迟个几秒也是可以接受的，双向通信也可以用轮询来代替。
现在不少 IoT 项目都是用消息队列来削峰填谷，你可以把交易的每个步骤做成队列，每个步骤都有校验机制和重试机制，再加一些回滚机制，来尽可能提高可靠性。

[registerrr]

MQTT QoS=1

[RedBeanIce]

ack

[zmal]

你的需求对实时性要求不高，“通知设备支付完成”改成设备轮询支付确认接口。网络不好的问题，接口请求限制到一个 MTU(1500)，减少拆包重传之类的网络问题。

[jazzg62]

mqtt 正解

[jazzg62]

mqtt 正解，而且算是比较很成熟的方案了