背景在车联网场景中数采平台需要实时接收数百至上千辆车辆的上报数据涵盖实时遥测、心跳、故障、状态变更等多种消息类型。每辆车按 10~30 秒间隔上报千辆车并发意味着每秒需要处理数十到上百条 MQTT 消息且每条消息需经过解码、去重、存储、规则评估等多个环节。本文结合一个 Go 语言实现的车辆数据采集平台分享 MQTT 消息处理链路中的高并发设计实践。整体架构数据从车载终端到最终落库的链路如下车载终端 → EMQX → collector(订阅/解码/分发) → [state, storage, rule]核心设计原则入口简单设备只感知 EMQX不感知内部架构处理解耦collector 不直接写业务逻辑通过标准事件模型分发给下游模块可水平扩展EMQX 共享订阅支持多 collector 实例并行消费关键设计1. 共享订阅实现多实例负载均衡EMQX 的共享订阅Shared Subscription是实现多 collector 实例并行消费的核心机制。订阅时在 topic 前加上$share/group/前缀// mqtt_client.gofunc(p*pahoClient)Subscribe(topics[]string,qosbyte,handlerfunc(RawMessage))error{for_,topic:rangetopics{subTopic:topicifp.sharedGroup!{subTopicfmt.Sprintf($share/%s/%s,p.sharedGroup,topic)}// 订阅 subTopic如 $share/tbox-collect/atlas//realtimedata}}效果同一个 topic 下的消息会被 EMQX 轮询分配到同组内的不同 collector 实例实现无状态水平扩展。当前配置的共享组名为tbox-collect后续新增实例无需修改配置。2. Redis Stream 持久化队列避免内存消息丢失问题纯内存通道chan RawMessage在进程重启时会丢失未处理的消息。对于车辆遥测数据丢失意味着历史数据出现缺口。方案引入 Redis Stream 作为持久化缓冲层。MQTT 回调不再直接投递到内存 channel而是通过XADD写入 Redis Stream// collector.gofunc(c*Collector)onMessage(msg RawMessage){ifc.streamIngress!nil{// 路径 ARedis Stream 持久化c.streamIngress.Enqueue(ctx,msg.Topic,msg.Payload,msg.QoS,msg.ReceivedAt)return}// 路径 B内存 channel开发/轻量环境select{casec.msgCh-msg:default:c.log.Warn(collector queue full, dropping message)}}消费端使用单协程XREAD顺序消费保证严格 FIFO处理成功后XDEL删除// ingress.go - 核心消费循环func(i*Ingress)RunSequential(ctx context.Context,processfunc(context.Context,Delivery)error){afterID:0-0for{streams,_:i.rdb.XRead(ctx,redis.XReadArgs{Streams:[]string{i.stream,afterID},Count:1,Block:i.cfg.Block,}).Result()// 处理每条消息成功后推进游标for_,msg:rangest.Messages{iferr:process(ctx,d);err!nil{continue// 失败不推进重启后重新处理}afterIDmsg.ID}}}关键细节遥测数据高频攒批写入 ClickHouse 后批量XDEL避免逐条删除的性能开销故障、心跳等低频数据在同步落库成功后立即XDEL处理失败的消息不会被删除进程重启后自动重新消费Stream 设置MAXLEN ~10000近似裁剪防止内存无限增长3. 统一事件模型与分发器设计标准事件类型所有 MQTT 消息解码后转换为统一的标准事件消息类型事件结构下游分发目标realtimedataVehicleTelemetryEventstate storage ruletruckstatusVehicleStatusEventstate ruleheatbeatHeartbeatEventstate storagefault_eventFaultEventstate storage ruleeventRawEventstorage rule分发器接口通过接口解耦 collector 与下游模块typeEventDispatcherinterface{Dispatch(ctx context.Context,eventinterface{})errorDispatchTelemetry(ctx context.Context,event*TelemetryDispatch)errorDispatchFault(ctx context.Context,event*FaultDispatch)error// ...}ModuleDispatcher根据事件类型调用对应的下游处理器StateHandler / StorageHandler / RuleHandler每个处理器的错误独立记录互不影响。4. Protobuf / JSON 双模式解码车端协议存在 Protobuf 和 JSON 两种编码格式。解码策略优先尝试 Protobuf 解码通过注册表查找对应消息类型的解码器Protobuf 失败时降级为 JSON 解码配置项json_fallback: true解码失败记录到 ClickHouse 的dwd_vehicle_decode_error表方便回溯排查func(d*StandardDecoder)Decode(ctx context.Context,meta EventMeta,payload[]byte)(interface{},error){ifd.cfg.ProtoEnabled{ifdecoder,ok:d.protoDecoders[meta.MessageType];ok{event,err:decoder.Decode(ctx,meta,payload)iferrnil{returnevent,nil}if!d.cfg.JSONFallback{returnnil,err}}}returnd.jsonDecoder.Decode(ctx,meta,payload)}5. 消息去重基于时间窗口的滑动去重车辆在弱网环境下可能重发消息。去重逻辑基于VIN MessageType Payload哈希生成去重键在一个可配置的时间窗口内默认 5 秒判定重复func(c*Collector)processIncoming(ctx context.Context,msg RawMessage)error{ifc.config.DedupEnabled{key:buildDedupKey(meta,msg.Payload)dup,_:c.deduper.IsDuplicate(ctx,key,c.config.DedupWindow)ifdup{returnc.deleteStreamEntries(ctx,msg.RedisStreamID)}}// ... 解码和分发}去重器通过接口抽象支持内存实现MemoryDeduper适合小规模和 Redis 实现适合多实例共享状态。6. 遥测攒批写入与异步 Flush遥测数据是最高频的消息类型。每条实时写入 ClickHouse 会产生大量小 batch吞吐低下。方案内存缓冲区攒批达到阈值默认 40 条或空闲超时默认 10 秒时触发异步 flushflush 时浅拷贝缓冲区在后台协程执行批量写入不阻塞采集链路写入失败时将数据重新放回缓冲区配合重试机制指数退避最多 3 次func(s*StorageWriter)WriteTelemetry(ctx context.Context,telemetry*models.VehicleTelemetryEvent,streamIDstring)error{s.mu.Lock()s.telemetryBufferappend(s.telemetryBuffer,bufferedTelemetry{ev:telemetry,streamID:streamID})should:s.shouldFlush()// 条件buffer 40 或空闲 10ss.mu.Unlock()ifshould{s.flushTelemetryAsync()// 异步 flush不阻塞调用方}returnnil}7. 动态 Topic 订阅管理生产环境中需要支持新增或停用消息类型但不应重启服务。平台通过数据库管理订阅配置collector 定时刷新默认 60 秒func(c*Collector)refreshRoutes(ctx context.Context){routes,_:c.config.RouteStore.LoadEnabled(ctx)added,removed:c.config.RouteRegistry.Refresh(routes)// 动态取消已停用的 topiciflen(removed)0{c.mqtt.Unsubscribe(removed)}// 动态订阅新增的 topiciflen(added)0{c.mqtt.Subscribe(added,c.config.QoS,c.onMessage)}}降级策略数据库不可用时依次回退到注册表缓存 → 配置文件 → 硬编码默认值。可观测性全链路通过 Prometheus 指标监控指标用途tbox_collect_mqtt_messages_received_total按 topic 统计消息接收量tbox_collect_mqtt_decode_duration_seconds解码耗时分布直方图tbox_collect_mqtt_dispatch_duration_seconds分发耗时分布tbox_collect_mqtt_queue_length内存队列积压深度tbox_collect_state_vehicles_online在线车辆数tbox_collect_mqtt_redis_stream_enqueue_totalRedis Stream 入队次数配合 Grafana 面板可以实时观察消息处理瓶颈、队列积压和车辆在线状态。经验总结决策理由Redis Stream 而非纯内存队列进程重启不丢数据成本远低于引入 Kafka单协程 XREAD 顺序消费避免并发消费带来的顺序性问题当前规模下吞吐足够遥测攒批 40 条异步 flush平衡实时性与写入吞吐ClickHouse 批量写入性能远优于逐条Protobuf 优先 JSON 降级兼顾新终端Protobuf和老终端JSON平滑迁移接口抽象Decoder / Deduper / EventDispatcher为未来扩展预留空间如 Kafka 替换 Redis Stream后续演进当前架构支撑千辆级规模。当车辆规模和消息量持续增长时计划在 collector 与下游模块之间引入 Kafka 事件总线EMQX → collector → Kafka → [storage, rule, state]得益于统一事件模型和接口抽象这一演进只需替换消息分发层核心处理逻辑无需修改。