📚 课程目录第2章数据采集与接入

2. 数据采集与接入：车载终端数据上报方式、MQTT/HTTP接入、数据缓冲队列设计

在途追踪系统的第一道关卡是数据采集与接入层。车载终端（T-Box / OBD / 北斗定位终端）以固定频率（通常 1~30 秒）上报 GPS 坐标、速度、方向、海拔、点火状态等字段。接入层需要解决三个核心问题：终端异构协议适配、高并发写入、突发流量削峰。本章节围绕上报方式、协议选型、缓冲队列展开。

2.1 车载终端数据上报方式

根据终端硬件能力与网络环境，主流上报方式分为以下三类：

上报方式	传输协议	典型场景	优点	缺点
定时上报	TCP / MQTT	长途干线物流、冷链运输	数据连续性好，便于轨迹回放	流量消耗固定，空闲时段浪费带宽
事件触发上报	HTTP / MQTT	急加速、急刹车、电子围栏越界	减少无效数据，降低服务器压力	事件丢失可能造成轨迹断点
补传/离线缓存上报	HTTP / MQTT	隧道、山区、地下车库等弱网区域	保证数据完整性，不丢点	补传时产生突发流量，需队列缓冲

实践建议： 多数商用平台采用“定时上报 + 事件触发”混合模式。定时周期设为 10 秒，事件触发优先级更高，补传队列在终端本地最多缓存 500 条，防止内存溢出。

2.2 MQTT 与 HTTP 接入对比与选型

MQTT 和 HTTP 是车载终端最常用的两种应用层协议。MQTT 基于发布/订阅模型，适合长连接、低带宽、高并发的 IoT 场景；HTTP 基于请求/响应模型，适合短连接、低频上报或补传场景。下表从关键维度对比：

对比维度	MQTT	HTTP
连接方式	长连接（TCP + 心跳保活）	短连接（每次请求新建 TCP）
协议开销	最小 2 字节固定头，极低	请求头通常 200~800 字节
实时性	毫秒级推送，服务端主动下发	秒级轮询或回调，服务端被动响应
QoS 等级	支持 0/1/2，可保证至少一次送达	依赖 HTTP 状态码重试，无原生 QoS
并发能力	单端口支持数万连接	需大量连接池，高并发时资源消耗大
适用场景	高频实时轨迹、指令下发	低频补传、终端配置查询

  选型原则： 主数据流（实时轨迹）强制使用 MQTT + QoS 1；补传/离线数据使用 HTTP POST，单次最多 50 条打包，减少连接次数。

2.3 数据缓冲队列设计

当数万台终端同时上报或补传突发流量时，直接写入数据库会导致连接打满、写入延迟飙升甚至雪崩。缓冲队列作为接入层与处理层之间的“蓄水池”，是保证系统稳定性的关键组件。

2.3.1 队列架构

缓冲队列采用“生产者-消费者”模型，生产者是 MQTT/HTTP 接入服务，消费者是数据清洗与持久化服务。队列中间件选型对比：

中间件	吞吐量	持久化	延迟	推荐场景
Redis List	10 万+/s	支持 AOF/RDB	微秒级	轻量级、单机或哨兵模式
Kafka	百万+/s	磁盘顺序写，高可靠	毫秒级	大规模集群、需要回溯重放
RabbitMQ	数万/s	支持镜像队列	微秒级	需要灵活路由、死信队列

注意： 缓冲队列必须设置上限（如 Redis List 最大 10 万条），超出时触发降级策略：丢弃最早数据或直接写入临时文件，防止内存溢出导致整个接入层崩溃。

2.3.2 队列消费与背压控制

消费者从队列中批量拉取数据（建议每次 100~500 条），经过数据清洗后再批量写入数据库。当消费者处理速度跟不上生产者速度时，需要背压控制：

动态调整拉取批次大小： 根据队列长度动态调整 batch size，队列越长，批次越大。
限流降级： 当队列长度超过阈值（如 80% 容量），生产者侧主动降频，将上报间隔从 10 秒调整为 30 秒。
熔断保护： 如果数据库写入连续失败超过 5 次，暂停消费并告警，避免无效重试耗尽资源。

# 伪代码：缓冲队列消费者批量拉取与背压控制
import time
from redis import Redis

r = Redis(host='localhost', port=6379)
QUEUE_KEY = 'gps:raw:queue'
BATCH_SIZE = 200
MAX_QUEUE_LEN = 100000

def consume_batch():
    while True:
        queue_len = r.llen(QUEUE_KEY)
        if queue_len > MAX_QUEUE_LEN * 0.8:
            # 背压：降低拉取频率
            time.sleep(0.5)
        # 批量拉取
        batch = r.lpop_count(QUEUE_KEY, BATCH_SIZE)
        if not batch:
            time.sleep(0.1)
            continue
        # 清洗与写入（略）
        process_gps_batch(batch)

生产级优化： 使用 Kafka 时，建议将 GPS 数据按终端 ID 哈希分区，保证同一终端的轨迹顺序消费；同时开启压缩（snappy/lz4），减少网络带宽占用。

2.4 接入层高可用设计要点

MQTT 集群： 使用 EMQX / VerneMQ 搭建集群，至少 3 节点，支持自动故障转移。
HTTP 网关无状态化： 网关节点水平扩展，前置 Nginx/HAProxy 做负载均衡。
缓冲队列主从/副本： Redis 哨兵或 Kafka 副本机制，防止单点故障导致数据丢失。
监控告警： 对队列长度、消费延迟、终端离线率设置阈值，超过时触发钉钉/短信告警。

  关键指标： 接入层设计目标：单节点支持 5000 终端并发上报，端到端延迟 < 200ms（从终端发出到进入缓冲队列），数据丢失率 < 0.01%。