这要取决充电桩厂家充满自停是如何控制检测的，正常充电达到捐流电后低于多少 w 就会自动停止充电。充满自停也是下发的一个最大充电时长，你要观察你的车子充满和断电的时间。

查询条件单独封装成实体，有同参数的定义成父类由子类查询体继承比如开始结束这种时间查询统一命名，然后时间属性这个字段可以由前端来传给你，尽量和库里时间字段保持一致，这样还支持多个时间字段的查询，不用定死。

首发 15pro 155 次循环，100%

90%机场问题，以前碰到过

@Kevinyy 通讯协议主流的就 mqtt,tcp 那几样。接入也方便不要购买冷门协议的就行。服务端负责下发指令就好了，后续加业务逻辑也方便

主要看设备的通讯协议，和设备交互还是让后端做吧小程序做通讯不太友好。

一口气 30-40 吧。夏天基本每天都会做 2 ，3 组一百来个

为什么不用 url 方式……

emqx 有规则规则引擎，直接 java 写个接口，配置到 emqx 规则引擎上就行。自己定义 sql 规则

@lynan 17 版本还是偶尔会有

用的什么 orm 框架，拦截 sql 就可以啊。

@zbinlin 是的是这样，高峰期就会。

@sujin190 是的，只有高峰期会这样，主从搭了还没用。用 mqtt 工具监听设备开启端口的指令已经回复了。我猜测是不是消息太多导致线程池处理不过来堵塞了？不在高峰期就算后台几千个订单进行中开启充电也是毫秒级的

@sujin190 没有做保证连接成功的机制，但是如果是高峰期导致的 ws 连接时间边长或者 ws 其他原因，设备上报成功开启端口的指令是没有影响的。然后再服务器中观察订单状态是没有更新成功的还是处于订单未开启的状态。按道理我更新订单状态和更新设备端口使用状态这个过程不受影响的啊。所以这个问题很迷，打算换其他方式。谢谢指导

@sujin190 是的用的 MQTT ，生成订单的时候服务器就会下发指令给设备开启端口。服务器收到设备开启端口的返回指令之后将该消息处理之后再使用 ws 推给小程序。这个小程序收不到消息的问题时而有时而没有。

@brader 这些都做了，服务器够大跑单体是没问题的。估计代码哪里有问题吧

@bootvue 嗯嗯有这个想法。现在猜测 ws 可能有问题，但是系统出现的问题没法复现，不好下手。