请求式 API
由应用按需发起查询，适合详情读取、状态核对、历史检索与低频更新。
关键关注
限流、缓存、分页与幂等重试
Delivery overview
四种模式，对应不同的数据消费场景
交付方式不应只按“是否实时”选择，还应同时评估调用模型、数据容量、恢复复杂度与持续运维成本。
事件推送
数据变化时主动通知消费端，适合赛事事件、状态变化与异步工作流触发。
关键关注
签名验证、重复事件与回调重试
流式连接
保持长连接持续接收数据，适合高频变化、低延迟消费与实时应用界面。
关键关注
心跳、顺序、背压与断线恢复
批量文件
按周期生成完整或增量数据文件，适合初始化、归档、离线分析与批量同步。
关键关注
命名、校验、增量范围与重取
Mode comparison
用统一指标比较交付模式
先明确业务允许的延迟与数据缺口，再评估团队是否具备维护长连接、重试队列和恢复状态的能力。
组合模式通常更稳健
实时通道负责快速更新，请求式 API 或批量文件负责初始化、补偿和周期性校准。
请求式 API
控制简单，适合按需读取与恢复查询
实时性
取决于轮询频率
实施复杂度
较低
容量特征
受限流与并发影响
恢复方式
重新查询指定范围
事件推送
以变化驱动处理，减少无效查询
实时性
高
实施复杂度
中等
容量特征
随事件密度波动
恢复方式
事件重投与范围补查
流式连接
持续传输高频事件，降低消费延迟
实时性
最高
实施复杂度
较高
容量特征
适合连续高吞吐
恢复方式
游标续传与缺口补偿
批量文件
适合大范围同步、归档与离线处理
实时性
低至中等
实施复杂度
中等
容量特征
适合大数据集
恢复方式
重新下载或补发文件
运维成本还取决于监控覆盖、告警响应、数据保留期和消费端水平扩展策略。
Realtime pipeline
实时数据从接收到消费的完整链路
每个阶段都应保留可观测信号，并明确失败后的重试、隔离和补偿边界。
接收
建立连接并验证消息结构与来源。
排序
依据序列号或业务时间组织事件。
去重
使用稳定事件标识过滤重复投递。
处理
执行校验、映射、聚合与状态转换。
持久化
保存事件日志与可恢复消费位置。
消费
向应用、分析系统与缓存层分发。
Event semantics
先定义事件语义，再编写消费逻辑
实时系统无法只依赖到达时间判断数据状态。稳定的事件标识、顺序规则和修正机制是确保结果一致的基础。
稳定事件标识
同一业务事件在重试和重放时应保持可识别，支持幂等消费。
明确顺序范围
说明顺序是在全局、赛事、资源还是连接范围内得到保证。
迟到与修正数据
应用应区分新事件、延迟事件与对既有状态的修正事件。
Consumer checklist
消费端实现检查项
- 使用事件 ID 或业务复合键实现重复检测。
- 分别记录接收时间、事件时间和处理时间。
- 将无法处理的消息隔离到可追踪的异常队列。
- 为修正事件设计覆盖、合并或撤销规则。
- 持续监控处理延迟、积压量、重复率与失败率。
Batch delivery
批量文件交付要求
文件命名
包含数据类型、范围、版本、生成时间与批次标识。
格式约定
明确编码、压缩方式、字段类型、空值和转义规则。
完整性校验
提供文件大小、记录数与校验摘要以发现传输损坏。
失败重取
定义保留期、重取入口、批次状态和重复导入策略。
增量文件必须说明起止边界是否包含端点，并提供处理重叠区间的方法。
Recovery strategy
恢复策略分层设计
-
1
短暂断线：自动重连
使用指数退避与随机抖动，避免多个客户端同时密集重连。
-
2
连接恢复：游标续传
从最后确认的安全位置继续读取，并容忍边界事件重复。
-
3
发现缺口：范围补偿
通过查询接口或补偿文件重新获取缺失时间段的数据。
-
4
状态偏差：全量校准
按计划与权威快照对比，修正长期积累的数据状态偏差。