批次问题概述
我们每天跟数据打交道，跑任务、调度、传输……一切都按部就班。但总有那么几次，任务明明没报错，结果却不对；或者是生产环境偶发性卡死，重启又好了。这种“鬼故事”，十有八九是批次问题。
什么是批次问题？说白了，就是数据或请求被切分成多批处理时，由于批次间状态、时序、资源或数据分布不一致，导致的非预期行为。它不是单点故障，更像是一种系统性的“软崩溃”。
批次问题的定义与本质
批次处理是现代系统中的常见架构：数据被分成若干小份，依次或并行处理。假设每一份都独立，那按理说不会出问题。可现实是，批次之间经常共享状态、资源、甚至中间结果。
我遇到过最典型的一次：一个 ETL 任务每天凌晨跑，某天突然多输出了三行脏数据。查了三天日志，最后发现是因为前一天的某批次写了一张临时表，而当天批次读到了这张表里残留的半条记录。这种跨批次的状态污染，就是批次问题的根。
定义：批次问题是指因批次划分、批次顺序、批次间依赖或批次粒度不当引发的非确定性或非预期的系统行为。
批次问题的分类
我习惯把批次问题分成三个大类，这样排查时更容易定位方向：
| 分类 | 描述 | 典型场景 |
|---|---|---|
| 输入侧 | 批次划分时数据分布不均匀、边界重复或遗漏 | 分页偏移量计算错误、窗口函数 OVER() 边界问题 |
| 处理侧 | 批次内状态管理、资源竞争或事务隔离失效 | 共享状态未加锁、批次级缓存过期策略错误 |
| 输出侧 | 批次提交顺序错误、结果合并逻辑缺陷 | 多线程写入同一文件、资源清理接口未幂等 |
当然，实际项目中这三个层面经常交织在一起。你想想看，输入侧的分页问题，很可能导致处理侧的数据倾斜，最后输出侧的结果排序也是乱的——这就是套娃式故障。
典型表现：症状清单
下面这些症状，如果你在系统里见过两三条，那基本可以判定是批次问题在作妖：
- 偶发性失败：同一套代码，十次里有两次报错，剩下的八次正常。
- 数据质量抖动：同一算法，昨天输出100行，今天输出98行，但没报错。
- 资源竞争死锁：某个批次任务长时间占用连接，其他批次等待超时。
- 延迟逐批累积：第一个批次处理5秒，第二个8秒，第十个直接15分钟。
- 状态不一致：集群中两个节点看到同一个批次的状态不同，一个认为成功，一个认为失败。
我记得有一次线上告警，说某个实时聚合任务从每分钟输出一次变成了每三分钟一次。表面看是性能问题，但一查日志，发现是最后一批次的数据量是前一批次的50倍——数据倾斜，分批逻辑没扛住。
注意：批次问题往往不会直接报错，而是表现为“业务数据异常”或“监控曲线异常”。所以排查时不能只看错误日志，还要结合业务日志、状态快照、甚至脏数据样本。
为什么批次问题难以排查
这个问题我思考了很久，也吃过不少亏。总结下来有四个核心原因：
- 不确定性：同样的代码、同样的输入，批次问题不一定复现。因为依赖了时间、线程调度、网络延迟等随机因素。
- 复现成本高：生产环境需要全量数据、完整依赖链，才能触发出问题场景。本地单机跑小样本，往往一切正常。
- 日志断层：批次间的边界信息经常被忽略。比如任务 A 处理第10批和第11批的日志混杂在一起，你很难区分哪条日志属于哪一批。
- 副作用难以隔离：一个批次的错误可能污染后续所有批次，或者被后续批次覆盖。你看到的最终结果，可能是多个批次错误叠加后的产物。
我之前排查过一个微服务链路超时问题。服务 A 每批发送100个请求，服务 B 处理完后异步回调。线上偶发超时，本地压力测试正常。最后通过给每个请求打批次序号和时间戳，才发现是服务 B 在处理某一批时，中间有一个请求因为 GC 停顿被延迟了，导致整个批次等待超时。这种跨服务的批次依赖，没有全链路追踪，根本盯不住。
一个小技巧：我习惯在批次处理的每个关键环节都加上 batch_id 和 batch_index 字段，并输出到结构化日志。这样后续排查时，可以快速过滤出指定批次的完整执行轨迹。
批次问题分类与关联图谱
下面这张图梳理了批次问题的分类及其相互影响关系。你可以把它当作排查时的导航图：
从这张图可以看出来，输入侧、处理侧、输出侧的问题可以互相转化。比如输入侧的数据倾斜，如果处理侧没有做负载均衡，就会演变成处理侧的资源竞争；最后输出侧可能因批次索引错位，出现数据重复或遗漏。排查时，你可以沿着这条路径反向推导：看到输出异常，先检查输出侧逻辑；如果正常，再回看处理侧状态；最后再去验证输入侧的批次划分是否均匀。
一个真实的日志痕迹
分享一段我当年排查时的现场日志。这是两个并行批次的处理输出，看起来几乎一样，但仔细看 batch_id 和时间戳：
2025-03-10 02:15:01.234 [processor-01] INFO Batch-20250310-001: start, records=5000
2025-03-10 02:15:01.456 [processor-01] INFO Batch-20250310-001: end, success=true
2025-03-10 02:15:01.789 [processor-02] INFO Batch-20250310-002: start, records=5000
2025-03-10 02:15:02.012 [processor-02] INFO Batch-20250310-002: end, success=true
2025-03-10 02:15:02.234 [processor-01] INFO Batch-20250310-003: start, records=5000
2025-03-10 02:15:02.567 [processor-01] INFO Batch-20250310-003: end, success=true
2025-03-10 02:15:02.890 [processor-02] INFO Batch-20250310-004: start, records=5000
2025-03-10 02:15:03.123 [processor-02] INFO Batch-20250310-004: end, success=true表面看一切正常，对吧？但注意——Batch-20250310-001 和 Batch-20250310-002 处理的是同一个上游表的不同分片，而它们同时写入了目标表。因为没有批次级锁，001 先插入数据，002 也插入，最后目标表里出现了重复主键。程序没报错，但数据多了。这种问题只有当你把 batch_id 也记录到目标表时，才能事后定位。
所以我后来在日志格式里强制加了一条规则：每个批次写日志时，必须同时输出该批次处理的源数据时间窗口或分片键。这样就算当时没发现，事后翻日志也能追溯。别小看这一行，它能帮你省掉至少半天排查时间。
避坑指南：我曾经因为日志里没有批次 ID，需要从分布式链路追踪系统里逐个 request_id 反查。查了三个小时才找到问题批次。后来我直接给所有批次任务加上 batch_meta 字段，包含批次总数、当前批次序号、上游批次依赖。这个元数据随消息一起传递，排查时一把梭。
小结
批次问题的本质是“多份数据/请求在分割与合并过程中丢失了原本的整体约束”。它不像空指针那样一眼就能看穿，也不像死锁那样有明确报错。它更像慢性病：症状不明显，但累积到一定量级才爆发。
排查时记住三句话：先定位领域（输入/处理/输出），再找具体表现（倾斜/竞争/顺序）。如果复现不了，就用埋点和全链路日志来“钉住”每一批次的轨迹。别怕慢，批次问题的排查本来就慢，但只要你方法对了，总能水落石出。