2. 行情数据特点：高频、实时、一致性与分层结构
行情数据是金融交易系统的核心血液，其技术特性决定了灰度发布与API升级的设计边界。理解这些特性，是后续制定平滑升级策略的前提。
2.1 四大核心特性
| 特性 | 描述 | 对灰度发布的影响 |
|---|---|---|
| 高频特性 | 单只股票每秒产生数十笔Tick级行情，全市场峰值可达每秒百万级消息 | 灰度流量复制与路由必须零额外延迟，避免成为瓶颈 |
| 实时性要求 | 行情从交易所到终端用户的端到端延迟通常要求 < 10ms | 升级期间不能引入明显抖动，需支持热切换 |
| 数据一致性挑战 | 同一时刻不同数据源（Level-1/Level-2）的行情必须逻辑对齐 | 灰度期间新旧API返回的行情快照必须保证时间戳与价格序列一致 |
| 分层结构 | 行情数据按使用场景分为快照、逐笔成交、逐笔委托、衍生指标等层级 | 不同层级可独立灰度，降低升级风险面 |
关键认知： 行情数据的高频与实时性，决定了灰度发布不能采用"先切一部分流量到新版本"的简单策略，而必须设计"双写+校验+渐进切换"的架构。
2.2 行情数据的分层结构
行情数据并非单一数据流，而是按业务粒度与更新频率分为多个层次。每一层对API的稳定性要求不同，灰度策略也应分层设计。
2.3 高频特性带来的技术挑战
- 吞吐量压力： 单节点需处理 10万+ msg/s，灰度期间新旧两套API同时运行，吞吐量翻倍。
- 序列化开销： Protobuf/FlatBuffers 等二进制协议在灰度对比时需要额外解码，增加CPU消耗。
- GC 抖动： Java/Go 等语言在百万级对象创建时容易触发 GC，导致延迟毛刺。
实战建议： 灰度期间使用"采样对比"而非"全量对比"。例如每100笔行情中抽取1笔进行新旧API结果校验，其余流量直接透传，可大幅降低性能开销。
2.4 实时性要求与一致性挑战的平衡
实时性与一致性在行情系统中存在天然矛盾。以下表格展示了不同场景下的取舍策略：
| 场景 | 实时性要求 | 一致性要求 | 灰度策略 |
|---|---|---|---|
| Level-1 快照 | < 5ms | 最终一致（允许1-2ms偏差） | 全量灰度，快速切换 |
| Level-2 逐笔成交 | < 1ms | 强一致（序列号对齐） | 双写 + 逐笔校验，逐步放量 |
| 衍生指标 | < 50ms | 最终一致（允许批次延迟） | 先灰度指标层，再灰度底层 |
2.5 分层灰度发布策略
基于行情数据的分层结构，推荐采用"自顶向下"的灰度顺序：
- L4 衍生指标层： 风险最低，先灰度验证API兼容性。
- L3 逐笔层： 数据量最大，需重点测试吞吐与延迟。
- L2 快照层： 用户感知最强，需保证快照时间戳一致。
- L1 原始行情层： 最后灰度，确保底层通道稳定。
避坑提醒： 不要同时灰度多层行情数据。某券商曾因同时升级L2和L3层API，导致逐笔成交与快照的时间戳偏差超过50ms，引发量化交易策略误判。分层灰度、逐层验证是必须遵守的原则。
2.6 本章小结
行情数据的高频、实时、一致性与分层结构，决定了灰度发布不能采用通用方案。核心要点：
- 高频场景下优先使用采样对比降低性能开销。
- 实时性与一致性需根据层级差异化设计灰度策略。
- 分层结构天然支持逐层灰度，降低升级风险。