目录一、先区分两个顺序二、完整落地方案生产级智慧充电实践1. 设备端源头约束是顺序的根基2. 传输层选型MQTT vs WebSocket3. 消息中间件解耦设备长连接网关 ↔ 订单服务4. 订单服务消费端业务层保证顺序最核心方案 A单线程消费每个会话简单中小规模方案 B单 partition消费线程设置为 1简单粗暴幂等必须配套5. 乱序兜底延迟消息 设备补报机制6. 极端 case 处理三、架构简图四、避坑点项目高频踩坑五、补充如果不用 MQ网关直接长连接推送订单服务六、核心总结一句话业务背景充电桩设备通过长连接MQTT/WebSocket上报实时充电报文开始充电、电压电流、功率、电量、结束充电等订单服务消费报文生成充电流水、更新订单状态。 问题风险网络抖动、重连、报文重传、服务异步处理会出现时序错乱比如先收到结束充电再收到充电过程采样数据导致订单状态异常、电量统计错误。核心矛盾网络层不保证有序 长连接断线重连会乱序 / 重复 服务端多线程消费乱序要从「设备端、传输协议、消息标识、服务端消费、兜底补偿」五层做顺序保障。一、先区分两个顺序设备产生事件的物理时序设备本地真实发生顺序采样 1→采样 2→结束这是源头不能被破坏。服务端处理顺序服务端必须按照设备发生顺序处理不能颠倒。注意长连接 MQTT/WebSocket单 TCP 连接内网络报文本身是 TCP 有序的但一旦发生断线重连、设备多线程发送、QoS 重传、服务端多线程并发消费就会出现乱序。 TCP 只保证同一个 socket 链路的字节流有序一旦断连新建 socket新连接消息和旧连接消息之间没有网络层顺序保证。二、完整落地方案生产级智慧充电实践1. 设备端源头约束是顺序的根基单设备单上报队列串行发送禁止多线程并发上报充电报文设备内部维护充电事件 FIFO 队列充电状态报文严格入队一个发送完成再发下一条不能多个线程同时往长连接写数据。反面设备多线程同时上报采样数据即使同一个 TCP 连接应用层输出顺序乱掉。每条充电报文携带 3 个核心时序字段{ deviceId:桩编号, orderNo:充电订单号, seq:12345, // 本订单内单调递增序列号每个充电会话从1开始每上报一条1 eventTimestamp:17xxxxxx, // 设备本地事件发生时间真实采样时间不是发送时间 sessionId:桩充电会话唯一ID, // 一次充电会话全局唯一断线重连不变新充电会话换新id dataType:sampling/start/stop }seq同一个充电会话内严格单调自增不回退、不重复。设备本地内存维护一次充电从 1 开始断电丢失可以由设备从充电会话本地存储恢复 seq。sessionId区分不同充电会话旧会话消息不允许干扰新订单。设备重启、拔枪sessionId 变更。eventTimestamp设备实际发生时间用来兜底校验不能用服务端接收时间。断线重连策略 重连成功后先补发断线期间未确认的报文再发送新报文不允许重连后直接发送最新数据把历史数据丢了。MQTT QoS1/QoS2 可以实现报文重传但 QoS 只会保证至少一次不保证业务顺序业务层必须自己带 seq。重点TCP 有序只针对当前存活的连接。断连后旧连接滞留报文 新连接报文网络到达服务端完全可能乱序TCP 无能为力。2. 传输层选型MQTT vs WebSocket智慧充电大多用 MQTTMQTT 同一个 clientIdbroker 内部同一个 topicQoS 下同一个会话内broker 投递是有序但是设备断开会话过期之后再次重连缓存消息和新消息消费者多线程消费依然会乱序。❗MQTT broker 只能保证 broker 内部发送顺序不能保证消费端多线程消费顺序。很多人踩坑以为用 MQTT 就天然有序消费线程池并发消费直接乱序。关键点顺序性不能交给中间件中间件只做投递业务层必须做 seq 校验。3. 消息中间件解耦设备长连接网关 ↔ 订单服务架构分层充电桩设备 → MQTT Broker / WebSocket 网关 →消息网关服务→ RocketMQ/Kafka → 订单服务网关收到设备长连接报文不直接调用订单服务 RPC。 如果网关直接同步调用订单服务订单服务卡顿会阻塞设备上报同时多线程 RPC 返回无法保证顺序。网关按deviceId sessionId作为分区 key 投递到 MQKafkakeydeviceId_sessionId保证同一个充电会话所有消息进入同一个 partition。同一个 partition 消息在 broker 层面是有序的。RocketMQ相同 key 进入同一个队列。这一步非常关键同一个充电会话全部消息落在同一个队列避免跨队列乱序。 ⚠️ 但是即使单 partition如果消费者开启多线程并发消费该 partition依然乱序4. 订单服务消费端业务层保证顺序最核心方案 A单线程消费每个会话简单中小规模同一个deviceIdsessionId的消息串行处理内存维护当前期望序列号expectSeq。收到消息如果 sessionId 已经是已结束会话订单已完结直接丢弃这条过期消息历史延迟到达的采样报文。判断报文 seqseq expectSeq正常业务处理处理完成 expectSeq 1seq expectSeq重复 / 延迟旧报文直接幂等丢弃seq expectSeq中间报文缺失暂停消费放入本地缓冲队列等待缺失 seq 到达等待超时则触发补报告警。问题内存缓冲如果服务重启内存缓冲丢失需要持久化存储每个会话的expectSeq存入 Redis。 Redis 存储结构key:charging:seq:{deviceId}:{sessionId}value 当前期望序列号同时设置会话过期时间。方案 B单 partition消费线程设置为 1简单粗暴同一个 topic 下每个设备会话落到一个 partition消费组消费该 partition 只用1 个消费线程。优点代码简单天然 broker 顺序缺点并发能力受 partition 数量限制充电桩数量巨大场景不适合。幂等必须配套因为长连接重传会有重复报文seq 同时做幂等 key避免重复扣电量、重复生成流水。5. 乱序兜底延迟消息 设备补报机制现实网络一定会出现丢包、报文延迟结束报文先到采样后到当订单收到 stop 结束报文标记订单为「待结束」不立刻完结开启延迟窗口例如 30~60s。 延迟窗口内继续接收该 sessionId 的采样报文更新订单电量窗口时间到再正式闭合订单。服务端检测 seq 缺口比如收到 seq10但 expectSeq7缺 8、9下发 MQTT 指令通知设备重传该 session 缺失 seq 区间的历史充电数据。会话超时超过最大充电时长自动关闭会话清理 Redis 中 seq 状态。6. 极端 case 处理结束报文先到达采样报文后到达session 收到 stop 报文进入延迟窗口期后续迟到的采样 seq 只要合法依旧更新流水窗口期结束直接忽略迟到报文。设备重启sessionId 更新旧 sessionId 消息全部做过期丢弃新 session 从 seq1 重新开始。新旧会话完全隔离互不干扰。服务实例重启所有会话的expectSeq持久化在 Redis重启后读取 Redis 继续校验 seq不会丢失顺序状态。重复重传报文MQTT QoS1 至少一次seq expectSeq直接丢弃天然幂等。三、架构简图充电桩设备本地FIFO队列携带seqsessionId ↓长连接MQTT MQTT Broker ↓网关转发keydevicesessionId RocketMQ/Kafka同会话进入同一个队列partition ↓ 订单服务消费 ├─ Redis维护每个会话expectSeq ├─ seq校验、缺口缓冲 ├─ stop报文开启延迟窗口 └─ 缺口下发补报指令给设备四、避坑点项目高频踩坑❌ 只依赖 TCP/MQTT 保证顺序业务不加 seq。断连重连后乱序订单电量错乱。❌ Kafka 单 partition但是消费者配置多线程消费同一个 partition。partition 有序多线程消费之后处理完全乱序。❌ 使用服务端接收时间做排序。网络延迟接收时间不能代表真实充电发生顺序。必须以设备上报 eventTimestampseq 为主。❌ 内存保存 expectSeq服务重启状态丢失顺序校验失效必须 Redis 持久化。❌ 收到 stop 报文直接关闭订单后面迟到采样报文无法更新电量统计少算 / 多算电量。五、补充如果不用 MQ网关直接长连接推送订单服务如果架构是 WebSocket/MQTT 网关直接调用订单服务不走消息队列 网关层需要做会话级串行同一个deviceIdsessionId网关内部维护内存队列串行推送给订单服务上一个业务 ACK 返回再推下一条。 一旦网关集群部署设备会漂移到不同网关实例内存队列失效所以这种架构不适合集群生产环境强烈建议引入消息中间件做会话分区。六、核心总结一句话TCP/MQTT 只能保证单连接内网络投递有序断线重连、集群、多线程消费都会打破顺序。真正保证充电业务顺序设备端单调 seqsessionId消息按会话分区投递消费端持久化维护期望序列号stop 结束做延迟窗口兜底缺口触发设备补报。
