线程池满了，任务被拒绝，直接丢掉或者抛异常？这恐怕是很多线上系统最不愿看到的场景之一。业务数据丢失、用户体验中断，后果往往比想象中更严重。尤其是对于那些“可以晚点执行，但绝不能丢”的任务，比如订单的异步通知、用户行为的埋点上报，或者风控结果的落库，我们需要一个更稳妥的“后路”。
这个后路，就是把被拒绝的任务，暂时存到一个可靠的地方——数据库或者消息队列，等系统压力缓解了，再捞出来慢慢处理。这本质上是一种容灾兜底策略。
为什么选数据库或消息队列做容灾存储？
说到底，无论是数据库还是消息队列，它们在这里扮演的角色是一样的：提供一个既能持久化存储，又能支持异步重试的“中转站”。但两者的适用场景，其实各有侧重。
数据库，更像一个结构严谨的档案室。它适合那些任务格式固定、后续可能需要人工介入查看，或者对强一致性有要求的场景。比如，支付结果回调失败了，存进一张“待重试表”里，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），触发告警，通知人工介入。
这种层层递进的策略，既保证了在绝大多数情况下的自动化和高可用，也为那些极小概率的、叠加的故障场景，预留了最后的观测窗口和人工干预入口。说到底，容灾设计的艺术，就是在成本与可靠性之间，找到那个最优雅的平衡点。
