Java请求队列中如何避免高并发下的任务丢失或重复执行？

Question

在高并发场景下，Java请求队列（如基于`BlockingQueue`、`ThreadPoolExecutor`或自研任务队列）常面临两大核心问题：**任务丢失**与**重复执行**。任务丢失多因队列满时拒绝策略（如`AbortPolicy`）直接丢弃，或消费者异常崩溃未及时重试；重复执行则源于消息幂等性缺失——例如RocketMQ/Kafka消费失败后自动重投、分布式环境下同一任务被多个节点争抢处理，或Redis分布式锁失效导致并发触发。此外，JVM意外退出、线程池`shutdown()`未等待任务完成、异步回调无状态跟踪等，均会加剧该问题。若缺乏持久化存储、ACK机制、全局唯一任务ID、状态机校验及补偿设计，仅靠内存队列或简单同步锁难以保障Exactly-Once语义。如何在性能、一致性与工程可维护性之间取得平衡，是高可靠任务调度系统的关键挑战。

Answer 1

```html

一、现象层：高并发下任务丢失与重复执行的典型表征

• 用户下单成功但库存未扣减（任务丢失）
• 支付回调触发两次，导致账户余额双倍扣款（重复执行）
• 线程池满后AbortPolicy静默丢弃Runnable，无告警日志
• RocketMQ消费端抛出Exception后自动重投3次，但业务未校验msgId或businessKey
• JVM因OOM被K8s强制kill，内存中LinkedBlockingQueue未持久化任务全部蒸发

二、机制层：核心问题的技术归因分析

问题类型	根本原因	对应Java组件
任务丢失	内存队列无落盘+拒绝策略无降级	ThreadPoolExecutor + AbortPolicy
重复执行	缺乏全局唯一ID + 状态机缺失 + ACK时机错位	RedissonLock过期/续期失败、Kafka enable.auto.commit=false但未手动commit

三、架构层：Exactly-Once语义的四大支柱设计

1. 持久化存储：任务元数据写入MySQL（含task_id、status、create_time、execute_count）
2. 幂等状态机：采用INSERT IGNORE或ON DUPLICATE KEY UPDATE保障状态首次变更原子性
3. 分布式协调：基于Redis的Lease Lock（带租约自动释放）替代简单SETNX
4. 补偿通道：独立定时扫描status='PROCESSING'超时任务，触发人工介入或自动回滚

四、工程层：可落地的代码级防护模式

以下为关键防护代码片段：

// 1. 全局唯一ID生成（Snowflake + 业务前缀）
String taskId = SnowflakeIdGenerator.nextId("ORDER_PAY_") + "_" + orderId;

// 2. 幂等写入（MySQL状态机）
int affected = jdbcTemplate.update(
  "INSERT INTO task_status (task_id, status, version) VALUES (?, 'INIT', 0) " +
  "ON DUPLICATE KEY UPDATE status = IF(status = 'INIT', 'INIT', status)",
  taskId
);
if (affected == 0) {
  throw new IdempotentRejectException("Task already processed: " + taskId);
}

五、演进层：从内存队列到可靠调度系统的演进路径

graph LR
  A[原始BlockingQueue] -->|丢弃风险| B[加监控+自定义RejectedExecutionHandler]
  B -->|仍存单点故障| C[本地磁盘队列+FileChannel原子写入]
  C -->|跨节点不一致| D[DB+Redis双写状态机]
  D -->|性能瓶颈| E[分库分表+TCC事务+异步ACK确认]
  E --> F[云原生Serverless任务编排：EventBridge + Step Functions]

六、治理层：可观测性与反脆弱能力构建

• 埋点指标：task_lost_total{reason="queue_full"}、task_duplicated_total{source="rocketmq_reconsume"}
• 链路追踪：在TraceId中注入taskId，实现全链路溯源
• 混沌工程：定期注入Kill -9、网络分区、Redis主从切换，验证补偿逻辑有效性
• 灰度发布：新任务类型按tenant_id % 100 < 5灰度放量，异常自动熔断

七、权衡层：性能、一致性、可维护性的三维取舍矩阵

方案	吞吐量	一致性保障	运维复杂度	适用场景
纯内存+ReentrantLock	★★★★★	★☆☆☆☆	★☆☆☆☆	单机非关键后台任务
MySQL状态机+Redis锁	★★★☆☆	★★★★☆	★★★☆☆	金融级订单履约

```