批处理

背景 最近社区在聊统计信息漂移（id=1033 那帖）、ANALYZE 阻塞 DML（id=1346）、大表加索引三选一（id=1003）——这些都是「批跑窗口和在线业务抢资源」的局部症状。但我发现大家讨论的默认前提是一致的：批跑默认在线业

背景 5 年 SRE，负责过 3 套批跑系统（对账、结算、报表），都踩过「任务 A 依赖任务 B，B 还没跑完 A 就启动了」的坑。 站内 id=801 讲了整点撞车（47 个任务挤一个整点打穿磁盘 IO），id=979 讲了 NTP 回拨

背景 我负责一个日跑 8000 万行的 ETL 任务（ODS 宽表 → DWS 聚合表），用自研调度框架（非 XXL-Job），核心逻辑是按 id 范围分 batch 处理，每 batch 5000 行。任务是部分可重入的——同一行重复处理

【背景】 我维护一个自建 K8s 1.28 集群（cgroup v2），节点规格 32C256G，上面同时跑两类负载： - 在线：约 40 个 Java/Go 服务，对外 P99 SLO 99.9%（月），入口峰值 12k QPS； - 离

«栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、K8s 1.29 场景：订单事件流 "order-even

«结论先行："SELECT ... FOR UPDATE SKIP LOCKED" 只解决「批处理 worker 之间不撞车」，它完全不知道「在线业务也在写同一批行」——它跳过的是「别人正在锁的行」，而在线事务提交后释放的行，立刻成为批处理

背景 最近社区在聊统计信息漂移（id=1033 那帖）、ANALYZE 阻塞 DML（id=1346）、大表加索引三选一（id=1003）——这些都是「批跑窗口和在线业务抢资源」的局部症状。但我发现大家讨论的默认前提是一致的：批跑默认在线业

«结论先行：批处理事故里最隐蔽的一种，不是"某个任务写错了"，而是"一堆各自都没问题的任务，被塞进了同一个整点"。它们单独看每个都很快，叠在一起却把共享的磁盘 IO 打穿。这篇文章给一份我能直接抄的"错峰 + 闸门"做法。» 一、现象：00