1. 逐笔数据丢包补录排障全景

逐笔数据是行情链路中粒度最细、价值也最高的一类数据：它记录每一笔成交或委托的明细，包含时间戳、证券代码、价格、数量、买卖方向、成交编号等字段。与快照行情相比，逐笔数据没有"周期性全量刷新"这一层兜底，一旦中间某一笔丢失，下游看到的就是一段不连续的历史。因此，逐笔数据的丢包排障，核心不是"数据有没有到"，而是"序号是否连续、缺口能否被定位并补齐"。

本节作为全课程的开篇，先建立一张全景图：逐笔数据流有哪些特征决定了它容易丢、丢了难查；实际生产中丢包补录会以哪些典型场景出现；以及面对一次丢包事件，排障的主干流程和工具链应当如何组织。后续 29 个案例，都是在这张全景图上落到具体环节的展开。

一、逐笔数据流的三个关键特征

理解丢包排障，先要理解逐笔数据流本身的"物理形态"。它有三个特征直接决定了排障方式。

第一，序号连续性是唯一可靠的完整性判据。逐笔数据在交易所侧通常按通道（Channel）或按证券维度分配递增序号，例如某通道的逐笔成交序号从 1000001 开始逐笔加一。下游判断是否丢包，最直接的方法就是检查序号是否严格连续：出现 1000231 之后直接跳到 1000233，就说明 1000232 缺失。这里要注意参照约定——序号是"发送侧递增"，缺口位置以缺失序号本身标识，而不是以接收时间标识。

第二，多路并行、按通道独立编号。真实行情链路上，逐笔数据往往按通道分片并行传输，每个通道有独立的序号空间。这意味着"全局看起来连续"并不代表完整，必须逐通道校验。排障时第一件事往往是确认缺口落在哪个通道、该通道的序号区间是多少。

第三，链路环节多、每一跳都可能丢。一笔逐笔数据从交易所发出，经过行情网关、消息中间件、落库服务、补录服务，最后到达下游消费方。任何一个环节的缓冲溢出、连接闪断、消费位点回退或写库失败，都会表现为"下游少了一笔"。因此排障不能只盯末端，而要沿链路逐跳比对。

二、丢包补录的典型场景

把链路图落到生产现场，丢包补录通常以四类场景出现，它们的现象相似但根因不同，排障切入点也不同。

• 网关接收丢包。行情网关在高峰时段接收缓冲不足，或与交易所的连接发生短暂闪断，导致某通道序号出现连续缺口。特征是缺口成段出现，且往往集中在开盘、收盘等流量尖峰时段。
• 中间件消费滞后与位点回退。消息中间件分区积压后，消费端重启时位点提交异常，可能出现"重复消费"或"跳过一段"。特征是缺口位置与消费端重启时间高度吻合。
• 落库失败与主键冲突。解析入库阶段因字段异常、主键重复或事务回滚导致个别记录未落库。特征是缺口零散、单笔为主，且日志中常有对应的写入异常。
• 补录本身引入的新问题。补录时回源区间取错、重复回填或补录数据与原始数据字段口径不一致，造成"补了但补错"。这类场景最隐蔽，必须靠补录后的校验环节兜住。

三、排障主干流程与工具链

面对一次丢包事件，建议按"定位缺口—判定环节—回源补录—校验闭合"四步推进，每一步都有明确的输入和判据。

定位缺口。先从下游或落库表中按通道提取序号序列，与期望的连续区间比对，输出缺口清单。示例判据：某通道当日序号范围为 1000001～1280000，实际入库 1279997 条，缺口 3 笔，缺口序号为 1043215、1043216、1108872。这一步的产出是"缺口序号 + 所属通道 + 时间范围"。

判定环节。拿缺口序号去各环节日志中反查：网关接收日志里有没有这三笔？中间件对应分区在该时段的位点是否连续？落库服务在该时刻是否有写入异常？哪一跳开始"查不到"，丢包点就在它的上一跳与它之间。

回源补录。确认缺口后，通过补录服务按通道和序号区间向源头重新拉取。关键参数是回源区间要略大于缺口区间（例如缺口前后各多取 5 笔作为边界校验），避免区间边界取错导致补不全或补重复。

校验闭合。补录完成后重新做序号连续性校验，确认缺口清零；同时抽样比对补录记录与原始记录的字段一致性，并检查是否产生重复主键。只有"序号闭合 + 字段一致 + 无重复"三项同时满足，才算补录成功。

工具链方面，日常排障主要依赖四类能力：序号比对脚本（按通道输出缺口清单）、链路日志检索（网关、中间件、落库三段日志按序号关联）、补录服务（按通道与区间回源重放）、以及补录后的校验工具（序号闭合与字段比对）。这四类能力构成了后续 29 个案例反复使用的基础设施，也是把"凭经验猜"变成"按证据查"的关键。

掌握这张全景图后，遇到任何一次逐笔丢包，都可以先问三个问题：缺口在哪个通道、从哪一跳开始查不到、补录后三项校验是否全部通过。把这三个问题答清楚，排障就从漫无目的的翻日志，变成了沿链路逐跳收敛的过程。