自定义线程池拒绝策略如何将任务暂存数据库或消息队列

线程池满了，任务被拒绝，直接丢掉或者抛异常？这恐怕是很多线上系统最不愿看到的场景之一。业务数据丢失、用户体验中断，后果往往比想象中更严重。尤其是对于那些“可以晚点执行，但绝不能丢”的任务，比如订单的异步通知、用户行为的埋点上报，或者风控结果的落库，我们需要一个更稳妥的“后路”。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

这个后路，就是把被拒绝的任务，暂时存到一个可靠的地方——数据库或者消息队列，等系统压力缓解了，再捞出来慢慢处理。这本质上是一种容灾兜底策略。

为什么选数据库或消息队列做容灾存储？

说到底，无论是数据库还是消息队列，它们在这里扮演的角色是一样的：提供一个既能持久化存储，又能支持异步重试的“中转站”。但两者的适用场景，其实各有侧重。

数据库，更像一个结构严谨的档案室。它适合那些任务格式固定、后续可能需要人工介入查看，或者对强一致性有要求的场景。比如，支付结果回调失败了，存进一张“待重试表”里，DBA或者运维同学可以直接查库，手动触发，心里有底。它的优势是写入可控，事务支持好，但高并发下直接写库，得小心连接池和索引优化，别把数据库也拖垮了。

消息队列（比如Kafka、RocketMQ），则像一个高效运转的传送带。天生为高吞吐、削峰填谷而生，特别适合任务量大、且可能有多个消费者服务需要协同处理的场景。它自带的死信队列、重试机制，用起来很顺手。当然，代价是引入了额外的中间件依赖和网络开销，系统复杂度会上去一点。

如何实现一个带数据库落库的自定义拒绝策略？

思路很直接：在线程池的拒绝回调方法里，把任务信息序列化一下，插进数据库。关键点在于，这个写库操作不能阻塞调用线程，得快速完成，所以通常建议异步操作，或者至少确保数据库连接池有保障、设置合理的超时时间。

public class DbFallbackPolicy implements RejectedExecutionHandler {
    private final JdbcTemplate jdbcTemplate; // Spring JDBC 模板
    private final String insertSql = "INSERT INTO task_fallback (task_class, task_data, create_time) VALUES (?, ?, ?)";

    public DbFallbackPolicy(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        if (executor.isShutdown()) return;
        try {
            // 简单序列化：仅记录类名和 toString()（生产中建议用 JSON 或 Protobuf）
            String taskClass = r.getClass().getName();
            String taskData = r.toString(); // 或使用 Jackson.writeValueAsString(r)
            jdbcTemplate.update(insertSql, taskClass, taskData, new Date());
            System.out.println("任务已降级落库：" + taskClass);
        } catch (Exception e) {
            // 落库失败也不应影响主流程，可降级为日志告警
            System.err.println("任务落库失败，将尝试本地日志备份：" + e.getMessage());
            // 可选：写入本地文件或发告警
        }
    }
}

光有写入策略还不够，配套的设计也得跟上：

• 表结构设计：至少得包含这几个字段：id（主键）、task_class（任务类名）、task_data（任务数据，建议用TEXT类型）、status（状态，如 ‘pending’/‘failed’/‘success’）、retry_count（重试次数）、create_time（创建时间）、next_retry_time（下次重试时间）。
• 消费机制：需要另起一个定时任务，或者一个独立的消费者服务，定期去扫描表中状态为 ‘pending’ 的记录，反序列化后，重新提交到线程池或者直接执行业务逻辑。
• 存储优化：对 task_data 字段的长度要保持警惕，必要时做压缩，避免大字段把数据库撑爆。

如何实现发送到消息队列的拒绝策略？（以RocketMQ为例）

用消息队列来做兜底，其实更符合“解耦”和“弹性”的设计理念。利用MQ自带的可靠投递和重试能力，实现起来也很清晰。

public class MqFallbackPolicy implements RejectedExecutionHandler {
    private final DefaultMQProducer producer;
    private final String topic = "TASK_FALLBACK_TOPIC";

    public MqFallbackPolicy(DefaultMQProducer producer) {
        this.producer = producer;
    }

    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        if (executor.isShutdown()) return;
        try {
            // 构造消息体（JSON 格式更通用）
            String json = new ObjectMapper().writeValueAsString(Map.of(
                "taskClass", r.getClass().getName(),
                "taskData", r.toString(),
                "timestamp", System.currentTimeMillis()
            ));
            Message msg = new Message(topic, json.getBytes(StandardCharsets.UTF_8));
            producer.send(msg); // 生产者需已启动且有重试配置
            System.out.println("任务已发送至MQ容灾队列");
        } catch (Exception e) {
            System.err.println("MQ发送失败，触发本地降级处理：" + e.getMessage());
            // 降级方案：写日志、发企业微信告警、或 fallback 到 DB 表
        }
    }
}

这里有几个细节需要特别注意：

• 生产者准备：确保 DefaultMQProducer 已经正确初始化并启动，像 setRetryTimesWhenSendFailed(2) 这类提升可靠性的参数要提前设好。
• Topic与消费：对应的MQ Topic需要提前创建好。消费者端必须具备幂等处理的能力，因为消息队列通常是“至少投递一次”（at-least-once）的语义，消息可能会重复。
• 性能底线：拒绝策略的执行必须快，不能拖慢调用线程。所以，要避免在策略里做同步等待发送结果这类耗时操作。

更健壮的组合策略：优先MQ，失败转DB，最后日志告警

真正追求高可用的系统，很少会把宝全押在一个组件上。一个更稳健的思路，是设计一个分层兜底的链路：

• 第一层，优先消息队列：尝试将任务快速发送到MQ。这是首选，因为速度快、扩展性好，对主流程影响最小。
• 第二层，降级到数据库：如果MQ发送失败（比如网络瞬时故障、MQ集群异常），则异步将任务写入数据库。这一步更稳定，数据可追溯，为后续处理留了后手。
• 第三层，终极保底日志：如果连数据库写入都失败了（这已经是极端情况），那么至少要将错误信息记录到ERROR日志中，并同步上报到监控系统（如Prometheus AlertManager），触发告警，通知人工介入。

这种层层递进的策略，既保证了在绝大多数情况下的自动化和高可用，也为那些极小概率的、叠加的故障场景，预留了最后的观测窗口和人工干预入口。说到底，容灾设计的艺术，就是在成本与可靠性之间，找到那个最优雅的平衡点。