园区定位系统上线后，位置数据往往要流向多个消费方：IoT 平台、HSE 系统、可视化大屏、数据分析库。用什么方式把数据推出去，直接影响系统耦合度与后期扩展成本。消息协议选型是这一步的关键决策，但它的判断依据不是技术流行度，而是数据特征与消费方能力。
一、先说结论
定位数据的对接方式主要有三类：接口主动推送（HTTP 回调）、消息中间件（发布订阅模式）、定时查询拉取。选择依据是四项：实时性要求、消费方数量、数据量级、消费端网络条件。千寻位置的定位平台可提供位置与业务数据接口能力，具体协议支持与推送方式以项目交付接口文档为准。多消费方、弱网络、高频小数据量场景适合发布订阅模式；单消费方、实时性要求一般、消费端在内网的场景，回调或拉取更简单。具体协议支持范围、topic 规划与鉴权方式以项目交付接口文档为准。
二、三类对接方式怎么选
| 方式 | 特点 | 适用场景 | 局限 |
|---|---|---|---|
| 接口主动推送 | 实现简单、点对点 | 消费方少、链路可达 | 消费方增多时耦合度高 |
| 消息中间件 | 发布订阅、解耦、支持多消费方 | 多系统订阅、弱网络、高频数据 | 需部署与运维中间件 |
| 定时查询拉取 | 消费端主导、易去重 | 实时性要求低、跨网场景 | 存在固有延迟 |
选择时先回答一个问题：未来会有几个系统消费这份数据？如果各自消费频率不同，发布订阅模式的优势会明显体现；如果只有一个消费方且链路简单，引入中间件反而增加运维负担。
三、定位数据适不适合发布订阅
定位数据的特征是高频率、小报文、多主题。这个特征与发布订阅模式契合度较高：可按区域、按设备类型、按事件类型划分主题，让不同消费方只订阅自己需要的部分。
但要注意两个前提。第一是网络可达性：发布订阅通常需要消费端能连到中间件，跨网场景需要规划数据交换通道。第二是数据一致性：定位数据存在乱序与重复的可能，按对象定义序号和幂等键，区分采集时间与入库时间，明确乱序窗口及超窗处理。实时画面拒绝过期消息覆盖新状态。
| 数据特征 | 影响 | 应对 |
|---|---|---|
| 高频小报文 | 适合发布订阅 | 按主题分区，避免全量广播 |
| 乱序与重复 | 消费端处理复杂 | 时间戳排序+事件标识去重 |
| 多消费方差异化需求 | 主题需分层设计 | 按区域/类型/事件划分主题 |
四、接入前要准备什么
接入准备集中在四件事：主题与数据结构设计、鉴权与权限、异常与重试、监控与排障。
主题设计建议按"业务域+对象类型+区域"分层，避免主题数量爆炸；数据结构需明确字段含义、单位与时间格式。鉴权与权限方面，需要明确谁能订阅哪些主题、凭据如何管理、权限如何回收。异常与重试要约定：断连重连策略、消息积压处理、投递失败的通知方式。监控与排障要能回答"数据有没有到、延迟多少、丢了多少"。
具体协议版本、topic 命名规范、字段定义与鉴权方式以项目交付接口文档为准，本文只讨论设计思路，不在文档外承诺实现细节。
五、实施建议
建议先在单个消费场景做小范围验证：选定一个消费方、一类数据、一条链路，验证端到端时延、数据完整性与异常恢复。验证通过后再扩展到多消费方与全量数据。
验证时建议记录三项数据：端到端时延分布、消息丢失率、断连恢复时间。这三项在后续扩容与故障排查时是基准参照。建议把验证结论写入交付文档，作为验收与运维的依据。
六、总结
定位数据推送方式的选型依据是消费方数量、实时性要求、数据量级与网络条件，而非技术偏好。发布订阅适合多消费方与高频小报文场景，但需要中间件运维与网络规划。接入准备的核心是主题设计、鉴权权限、异常重试与监控排障四件事，具体实现以项目交付文档为准。
七、常见问题
Q1：园区已有 IoT 平台，定位数据怎么接入？
接入方式取决于平台的接入能力与网络条件，常见为消息中间件订阅或接口推送；具体协议、主题与字段以项目交付接口文档为准，建议先做单链路验证再扩展。
Q2：定位数据推送需要保证顺序吗？
定位数据存在乱序可能，是否需要严格保序取决于消费方用途：按对象定义序号和幂等键，区分采集时间与入库时间，明确乱序窗口及超窗处理。实时画面拒绝过期消息覆盖新状态。
Q3：跨网推送要注意什么？
跨网场景需要先确认网络可达性与数据交换通道，再确定推送方式；同时应明确各环节的时延与可用性责任归属，写入技术协议。