行情系统面试专题：实时数据流、推拉模式、快照与增量、对延迟的极致要求
核心考点：实时数据流的可靠性设计 • 推拉模式选型 • 快照增量同步策略 • 延迟可观测与极致优化
面试回答框架图
下图展示在面试中回答“如何设计低延迟行情系统”时的结构路径，覆盖数据源、传输模式、快照增量、延迟优化与容错恢复五大模块。
面试问答卡片
Q1：请简述行情系统中“推模式”和“拉模式”的优劣，你在实际项目中如何选型？
| 考察点 | 是否理解两种模式的数据流差异、延迟与资源消耗的平衡、选型依据（场景+规模） |
| 回答框架 | ① 定义推模式（Push）与拉模式（Pull）的基本机制；② 对比延迟、带宽、服务端压力；③ 给出选型公式：高并发低延迟场景优先Push，低频/批量场景优先Pull；④ 结合项目案例说明混合方案 |
| 示例回答 | 推模式延迟低，适合实时行情，但流量不可控；拉模式节省带宽，但轮询延迟增加。在我们千亿级交易平台，深交所行情使用Push推送实时快照与增量，而回放历史行情时采用Pull拉取已压缩快照，平衡延迟与带宽。 |
可能追问：客户端大量断开时如何防止推模式风暴？——回答：增加背压机制、限流降级、使用多级缓冲。
避坑提醒：避免只讲概念不落地；必须给出具体场景下的权衡（如内存占用、GC影响）。
Q2：如何实现行情快照与增量数据的无缝合并？谈谈关键设计。
| 考察点 | 快照发布频率、增量序列号管理、合并原子性、断线重连后的一致性 |
| 回答框架 | ① 定义快照（全量市场状态）与增量（逐笔/逐Tick变化）；② 序列号对齐机制；③ 合并算法（基于时间戳或序号Map）；④ 重连时的快照请求+增量回放 |
| 示例回答 | 交易所每500ms推送一个全量快照，中间产生多条增量消息。客户端维护全局序号，每次增量按序号顺序写入ConcurrentSkipListMap，收到新快照时覆盖基础Map，再应用之前缓存的增量。重连时先拉取最新快照，再请求丢失的增量序列。 |
可能追问：如果增量比快照先到达怎么办？——回答：客户端需要先缓存增量，快照到达后再合并，防止乱序。
避坑提醒：不要忽略内存开销；快照频率过高会OOM，需根据业务调整。
Q3：行情系统对延迟要求极高（微秒级），你在哪些层面做过优化？
| 考察点 | 操作系统层（cpu绑核/大页/隔离）、网络层（内核bypass/DMA）、应用层（无锁队列/零拷贝/对象池）、GC调优 |
| 回答框架 | ① 硬件与OS：CPU隔离、网卡RSS、关闭irqbalance；② 网络传输：使用VMA/DPDK或Quic；③ 数据处理：RingBuffer无锁写入、直接内存操作减少拷贝；④ 序列化：Protobuf vs 手工紧凑编码 |
| 示例回答 | 我们使用DPDK绕过内核直接收发网络包，业务线程绑核隔离。内部用Disruptor无锁队列传递行情事件，对象预分配复用，避免GC。序列化使用定长二进制格式，单笔行情处理延迟控制在5μs以内。 |
可能追问：如何量化延迟？——回答：每笔行情打硬件时间戳，通过P95/P99直方图监控，使用大数据平台分析抖动。
避坑提醒：不要只罗列技术名词，必须给出实测数据对比；避免过度设计，要考虑成本。
项目案例：低延迟行情分发平台
| 项目名称 | 极星行情网关 v2.0 |
| 业务背景 | 为量化私募提供沪深交易所实时行情转发，支持500+客户并发订阅，要求端到端延迟低于50μs |
| 规模指标 | 日均处理50亿笔行情Tick；推模式单链路吞吐量80万笔/秒；快照大小2MB/次，每500ms推送一次 |
| 技术栈 | C++17、DPDK、NUMA绑核、Disruptor、共享内存、Redis Stream（落盘+重连）、Protobuf |
| 核心难点 | ① 离散行情源的时钟同步；② 快照合并时内存抖动；③ 客户断线重连时增量回放不丢不重 |
| 面试高频追问 | 1. 如何保证DPDK收包不丢？— 多队列RSS + 每个队列绑定独立core；2. 快照增量合并后如何校验一致性？— 维护Checksum链；3. 如何实现平滑扩缩容？— 无状态设计+配置中心动态路由 |
| 可迁移回答话术 | “本方案核心是推拉结合+快照增量对齐+硬编码延迟优化，可推广至任何需要低延迟数据分发的场景，如期货行情、外汇报价、实时风控。” |
💡 面试加分项：提及硬件时间戳（PTP）对齐上下游延迟、持久化快照用于故障恢复、灰度切换降低升级风险。