ElasticJob 生产检查清单

适用 ElasticJob 3.x（正文以 3.0.5 为例），协调存储为 ZooKeeper 3.5+。3.x 与 2.x 的包名、接口和 Spring Boot 配置键不同，不能混用。 只列不做会丢数据、会不可用、会查不出故障的动作；机制解释见本目录正文。

上线前

• [ ] ZooKeeper 至少 3 节点，不和业务抢盘：ElasticJob 强依赖 ZK。客户端默认请求 60s 会话超时，服务端按 2×tickTime ~ 20×tickTime 协商，tickTime=2000ms 时上限 40s；要更长会话先把 tickTime 调大。ZK 不可用时实例会停跑，这是设计行为。
• [ ] shardingTotalCount 按峰值实例数和单分片数据量定死：建议取峰值实例数的 2–4 倍（经验值，需压测）。实例数变化只换宿主；改分片总数会改变数据路由，必须配合迁移或全量重跑。取数用 MOD(id, shardingTotalCount)，不要用在线实例数。
• [ ] 幂等键和进度表先落地：ElasticJob 没有 checkpoint，DataflowJob 也不保存 offset。每批处理完更新业务状态或 offset 表；流式模式 props.streaming.process=true（默认 false）才会反复拉取，fetchData 返回空才停止。没有幂等和进度，故障接管必然重跑。
• [ ] 三个开关按业务定：failover(false)（默认关闭，打开后失败分片换实例但不续点）、monitorExecution(true)（默认写 running 节点）、misfire(true)（默认只补最近一次）。misfire 不是补数系统，逐日任务要自己做日期补跑。
• [ ] 接受并监控 ZK 不可用时的停跑：连不上 ZK 的实例停止执行，避免失联实例继续跑旧分片造成双写；恢复连接后自动继续。ZK 连接数、会话过期、instances 节点数要有告警。
• [ ] 分片策略和分片参数分清：内置只有平均（默认）、奇偶、轮询三种；shardingItemParameters("0=shanghai,...") 只传业务字符串，不改变分配结果。按地域/标签分配要自己实现 JobShardingStrategy。

运行中

• [ ] 实例抖动：ls /<namespace>/<job>/instances、stat /<namespace>/<job>/leader/election/instance；分片反复重分配先查 ZK 会话过期、GC、网络，不要先改分片策略。
• [ ] 分片归属完整：ls /<namespace>/<job>/sharding，逐个 get .../sharding/<n>/instance；实例数少于分片数属正常，但每个分片都应有宿主，缺失说明重新分片未完成。
• [ ] 倾斜看每分片处理量：对比各分片的处理条数和耗时，不只看实例间分片数是否平均；数据分布不均要靠改取数/切分规则，框架只均分编号。
• [ ] running 节点和调和：get .../sharding/<n>/running；崩溃遗留标记可能挡住后续执行，reconcileIntervalMinutes=10（默认）会做一次调和，但不要把它当实时恢复。

故障时

• [ ] 作业不触发 → 查 get .../config 的 disabled、ls .../sharding/<n>/disabled、应用与 ZK 的连接日志 → 作业或分片被禁用先恢复；cron 正常但不跑，查实例是否在线和本地时钟。
• [ ] 故障接管后重复处理 → 对比接管前后各分片处理条数、查业务进度表 → 没有 checkpoint，新宿主从分片起点重扫；failover(true) 或人工重跑会放大重复。修复靠幂等键和状态机，不是关掉接管。
• [ ] ZK 不可用导致全量停跑 → 应用日志搜连接丢失/SessionExpired，echo srvr | nc <zk> 2181 看 Mode，echo mntr | nc <zk> 2181 看 quorum → 先恢复 ZK 多数派；实例会自动继续，不要绕过 ZK 手工触发分片。
• [ ] 单分片长期跑不完 → 看该分片数据量、执行耗时、是否热点 key → 调整取数规则或增加分片总数（需迁移/重跑），不要只加实例——热点分片仍只归一个宿主。
• [ ] 漏跑或补跑时间不对 → 查本地 cron、misfire 配置、实例时钟；maxTimeDiffSeconds=-1（默认不检查） → 多机必须配 NTP，逐日任务用业务日期表补跑，不要依赖 misfire 追多个窗口。