多线程批量处理记录时的事件状态维护方案咨询

我需要从数据库读取100万条记录推送到第三方服务，受服务限制，每200条记录打包成1个event，用Executor Framework创建10个线程并行处理（同时跑10个event，一次处理2000条记录）。现在得维护这些event和记录的处理状态，统计成功、失败的数量。目前我想到两种方案：

现有方案 #

方案1 #

执行前，把每个event id + record id的初始状态写入文件：

event1 + record1 -> start

执行完成后更新状态：

event1 + record1 -> end

后续通过统计同时存在start和end的条目，以及缺少end的条目来判断处理状态。

方案2 #

把所有record id写入标记为pending的文件，把成功处理的record id单独写入另一个文件，后续通过对比两个文件找出未成功的记录。

更优的状态维护方式 #

1. 内存计数器+分片日志（轻量高效） #

• 用线程安全的计数器（比如Java的AtomicInteger）实时统计全局成功、失败数，每个线程单独维护自己负责的event状态。
• 每个event处理完后，直接把该event的结果写入分片日志文件（比如event_123.log），格式可以简化成：

  event_id:123, status:success, records:[1,2,...,200]
  

  或者失败时明确标记失败的记录ID：

  event_id:123, status:failed, failed_records:[5,18,...]
  

• 任务中断重启时，先扫描所有分片日志，汇总已处理的记录数，再从数据库读取未处理的记录（可以通过记录ID范围或数据库标记位筛选）。

2. 数据库状态表（持久化+易追溯） #

• 建一张状态表，字段至少包括：record_id（主键）、event_id、status（可选值：pending/success/failed）、update_time。
• 读取记录后，批量把所有记录的状态设为pending；每个线程处理完event里的记录后，批量更新对应record_id的状态为success或failed（失败的可以额外加个fail_reason字段存原因）。
• 统计时直接查数据库：

  SELECT COUNT(*) FROM task_status WHERE status = 'success';
  SELECT COUNT(*) FROM task_status WHERE status = 'failed';
  

• 优点：不用手动对比文件，状态查询快，支持断点续传（重启时直接拉status='pending'的记录重跑）。

3. 本地KV存储（轻量持久化） #

• 用LevelDB、RocksDB这类本地KV存储，key设为record_id，value存event_id|status。
• 处理前批量写入pending状态，处理完成后更新为success或failed。
• 统计时可以直接遍历KV存储，或者额外维护全局计数器并持久化到KV里，比文件读写快，又比数据库轻量。

现有方案的问题 #

原来的两个方案都依赖文件对比，100万条记录的文件体积不小，对比起来效率低，还容易出现文件读写冲突、损坏的情况，后续排查问题也麻烦。上面的几种方案在可靠性、效率和可维护性上都更优。

内容的提问来源于stack exchange，提问作者sweety