Java 批量任务平台怎么做多租户隔离：队列分片、并发配额与回压策略

凌晨跑批量对账刚十分钟，租户A一下塞进来18万条任务，租户B的几十条补单任务也跟着堵在队列里。很多团队遇到这种场景第一反应是调大工作线程数，最后往往把数据库连接、第三方接口调用额度、日志存储空间全吃紧。真正要做隔离的从来不是任务类型，而是不同租户对共享资源的占用路径。

先把慢租户从正常租户的路径里拿出去

单一FIFO队列写起来最省事，也最容易把系统搞到完全不公平。假设所有批量任务都进入 bulk:ready，租户A的长任务排在前面，租户B就算只有一条小的查询修复任务，也得跟着排队。把队列拆成 bulk:{tenantShard} 之后，调度层可以轮询多个分片，再通过租户配额控制单个分片在固定时间窗里能拿到的处理名额。

分片不等于给每个租户建一条物理队列。租户数不多、租户价值差异比较明显的场景可以一租户一队；动辄数万租户的场景更适合用固定数量的分片，比如 hash(tenantId) % 64。核心要求是任务消息始终带着 tenantId、jobId、attempt 和预估资源消耗，后面的配额校验、重试策略和审计链路才能全对上。

架构的瓶颈通常不在工作线程

把并发数从32调到256，整体吞吐未必会上涨。批量任务往往会同时占用连接池、远端API、文件句柄或者写入锁资源。如果单个任务平均占用一个数据库连接80ms，而连接池只预留了40个连接给这类批量业务，那系统能承载的最大可用并发数根本不是机器CPU核数，而是依赖资源总预算减去在线请求的安全余量之后的数值。

public final class TenantGate {
    private final Map tenantPermits = new ConcurrentHashMap();
    private final Semaphore globalPermits = new Semaphore(24);

    public Permit tryAcquire(String tenantId, int tenantLimit) {
        Semaphore tenant = tenantPermits.computeIfAbsent(
            tenantId, key -> new Semaphore(tenantLimit)
        );
        if (!globalPermits.tryAcquire()) return Permit.denied("global_busy");
        if (!tenant.tryAcquire()) {
            globalPermits.release();
            return Permit.denied("tenant_busy");
        }
        return new Permit(tenant, globalPermits);
    }
}

这个实现骨架只留了两道闸门：先申请全局资源预算，再申请租户对应的处理名额；租户配额校验失败时立刻把已经拿到的全局预算归还回去。实际项目里还要把 Permit 放在 finally 中释放，给每个任务设定最长处理截止时间。不用急着额外加第三层开关，先把两类资源的账算清楚，监控指标才不会变成一堆没法解释的无效数字。

回压不是拒绝一切，而是给任务一个可预期的去处

当分片长度超过预设阈值，任务入口层不该继续返回“已受理”的误导状态。可以把新任务标记为 WAITING，写入下一次允许拉取的时间点；对于不能重试的导出任务或者人工发起的定向任务，直接返回一个可查询的 jobId 和预计处理状态。调用方拿到明确状态后就能展示“排队中”提示，不会反复重提相同的任务。

延迟策略要按失败原因分开配置：租户配额不足可以设置短等待延迟，远端接口返回限速要按照对方提示的等待时间设置延迟，数据库持续超时的话就直接暂停该类任务并通知值班人员。把所有失败任务全部塞回队尾，只会引发重试风暴，反而挤占正常任务的处理资源。

if (gateResult.denied()) {
    jobStore.markWaiting(jobId, gateResult.reason(), Duration.ofSeconds(20));
    return SubmitResult.accepted(jobId, "WAITING");
}

try (Permit permit = gateResult.permit()) {
    taskHandler.handle(job);
    jobStore.markDone(jobId);
} catch (UpstreamRateLimited ex) {
    jobStore.defer(jobId, ex.retryAfter());
}

上线前先定四个能定位问题的核心指标

只盯着TPS很容易对系统状态产生误判。每个租户维度至少要统计 task_wait_seconds、in_flight 和 deferred_total；全局维度额外统计 dependency_latency_p95 与连接池使用率。告警规则不要直接绑定队列长度，不同资源消耗的任务占用队列长度的参考意义完全不同，更实用的告警组合是“队列里最老任务等待超过5分钟，且任务受理延迟比例连续10分钟持续升高”。

• 先用压测租户模拟10倍于平常的提交峰值，确认普通租户的任务等待时长不会同步出现不可控的上涨。
• 人为收紧全局资源名额，确认新任务会进入 WAITING 状态，不会出现任务丢失或者无限重试的问题。
• 模拟下游服务限速场景，确认延迟任务会按预设规则回流，租户占用的配额最终会正常归还。
• 留存一次分片产生热点时的完整日志样本，核对 tenantId、jobId 和任务状态流转记录是否完全匹配。

常见问题

租户数量很少时还需要做分片吗？

仍然需要遵循隔离思路。租户少的场景可以直接按租户单独建队列，重点是让调度顺序和配额完全可控，没必要硬套哈希分片的方案。

配额应该按任务数计算还是按资源成本计算？

如果任务耗时都差不多，按任务数统计就够用；导出、转码、批量写入这类资源消耗差异很大的场景，更适合在任务消息里带上成本等级，再换算成不同权重的占用名额。

队列满了是不是应该直接报错？

同步且要求立即返回结果的操作可以明确拒绝；可异步完成的批量任务更适合返回任务编号和排队状态，避免用户反复提交产生更大的流量峰值。

虚拟线程能替代这些控制逻辑吗？

不能。虚拟线程确实能降低阻塞等待场景下的调度成本，但是不会凭空增加数据库、第三方接口或者磁盘的实际承载容量；所有共享依赖仍然需要做资源预算和回压控制。

把容量保护逻辑放在任务进入系统的第一环节

多租户批量任务平台的核心不是追求单任务跑得有多快，而是在资源紧张的场景下，每个任务都能拿到明确的结果反馈：开始处理、排队等待、延迟重试或者转人工介入。队列分片负责租户资源隔离，双层配额闸门负责核心依赖保护，状态回转让调用方停止无意义的重试。把这三块逻辑跑通之后，再去调整工作线程数和批量拉取大小，调出来的参数才能真正起到作用。