配额是平台治理的基础设施
事件平台被多个业务线共享时，没有配额等于没有边界。一个出 bug 的消费者可能把 10MB/s 的 topic 拉到 100MB/s，影响其它所有业务线。配额的作用不是限制业务发展，而是防止单次事故扩散成平台级故障。
三种超限策略
配额超限时的处理策略分三种，从严格到宽松：
| 策略 | 行为 | 适用场景 | 风险 |
|---|---|---|---|
| HARD_REJECT | 直接拒绝写入 | 核心支付链路 | 业务峰值时误伤 |
| SOFT_WARN | 放行但标记告警 | 内部系统 | 放任导致实际超限 |
| DELAY | 延迟到下一窗口处理 | 批处理任务 | 延迟累积后雪崩 |
金融场景必须 HARD_REJECT。
QuotaManager Java 实验
import java.util.*;
public class QuotaManager {
enum Policy { HARD_REJECT, SOFT_WARN, DELAY }
record Quota(long maxStorage, long maxMsgs, long maxBw) {}
record Result(String tenant, boolean ok, String action, double pct) {}
static Map<String, Quota> quotas = new HashMap<>();
static Map<String, Long> storage = new HashMap<>();
static Map<String, Long> msgs = new HashMap<>();
static Map<String, List<Long>> bw = new HashMap<>();
static {
quotas.put("pay", new Quota(10L<<30, 1_000_000, 100<<20));
quotas.put("inv", new Quota(5L<<30, 500_000, 50<<20));
}
static Result check(String t, long sz, Policy p) {
Quota q = quotas.get(t);
if (q == null) return new Result(t, false, "UNKNOWN", 0);
long s = storage.getOrDefault(t, 0L) + sz;
long m = msgs.getOrDefault(t, 0L) + 1;
long now = System.currentTimeMillis();
bw.putIfAbsent(t, new ArrayList<>());
bw.get(t).removeIf(x -> now - x > 1000);
bw.get(t).add(now);
long bps = bw.get(t).size() * sz;
double maxPct = Math.max((double)s/q.maxStorage,
Math.max((double)m/q.maxMsgs, (double)bps/q.maxBw))*100;
boolean over = s > q.maxStorage || m > q.maxMsgs || bps > q.maxBw;
if (!over) { storage.put(t, s); msgs.put(t, m); return new Result(t, true, "OK", maxPct); }
return switch (p) {
case HARD_REJECT -> new Result(t, false, "REJECT", maxPct);
case SOFT_WARN -> { storage.put(t, s); msgs.put(t, m); yield new Result(t, true, "WARN", maxPct); }
case DELAY -> new Result(t, false, "DELAY", maxPct);
};
}
public static void main(String[] args) {
String[] ts = {"pay", "pay", "inv", "pay"};
long[] szs = {1024, 1024, 512, 1024};
for (Policy p : Policy.values()) {
System.out.println("=== " + p + " ===");
storage.clear(); msgs.clear(); bw.clear();
for (int i = 0; i < ts.length; i++) {
Result r = check(ts[i], szs[i], p);
System.out.printf("%-10s %-10s %.1f%%%n", ts[i], r.action(), r.pct());
}
}
}
}
预期输出：
=== HARD_REJECT ===
pay OK 50.0%
pay OK 100.0%
inv OK 100.0%
pay REJECT 150.0%
=== SOFT_WARN ===
pay OK 50.0%
pay OK 100.0%
inv OK 100.0%
pay WARN 150.0%
=== DELAY ===
pay OK 50.0%
pay OK 100.0%
inv OK 100.0%
pay DELAY 150.0%
成本分摊模型
配额和成本的关系不是一一对应的。存储成本容易计算，但带宽成本更难分摊，因为 Kafka 的 read amplification 意味着 5 个消费者读同一 topic，broker 出站带宽是单消费者的 5 倍。
成本分摊公式：
业务线成本 = 独占存储成本 + (共享带宽成本 × 该业务线消息量 / 总消息量)
更精确的做法是按「消息量 × 消费者数」为权重。如果业务线 A 有 10 个消费者而 B 只有 2 个，按消息量分摊对 A 不公平。
告警阈值与拒绝阈值
配额有两个阈值：
| 阈值 | 触发行为 | 设计要求 |
|---|---|---|
| 告警阈值（如 80%） | 通知业务线负责人 | 留出处理窗口 |
| 拒绝阈值（100%） | 触发拒绝 | 最终防线 |
告警阈值必须早于拒绝阈值。
配额的组织闭环
配额管理需要组织配合：
- 初始配额：按预估消息量申请，平台组审批。
- 季度 review：实际使用量 vs 配额，调整下季度配额。
- 紧急扩容：临时增加配额（如大促），事后回归基线。
- 超额计费：长期超额使用的业务线按实际成本分摊。
第 4 步是很多团队回避的。但回避会导致平台成本无限膨胀，最终影响所有业务线。
为什么配额告警经常被忽略
配额告警被忽略的原因通常是：告警阈值设得太低。如果存储配额 100GB，告警阈值设在 50GB，业务线会觉得"还有很多空间"，不着急处理。合理的做法是：告警阈值设在 80%，但通知文案写清楚"剩余 20GB，按当前增速将在 N 天内超限"。
另一个常见问题是告警渠道不对。配额告警发给技术团队，但技术团队没有预算调整权限。正确的做法是配额告警同时发给技术团队和业务线负责人，技术团队负责排查根因，业务线负责人负责决定是否扩容。
配额与性能的关系
配额管理不只是资源限制，也是性能隔离。一个没有配额的共享集群，一个业务线的突发流量可能导致整个集群的 GC 压力增加，影响其它所有业务线的延迟。
性能隔离的关键是：配额不仅要限制写入量，还要限制读取量——或者更准确地说，限制消费者组的消费速率。一个消费速率过高的消费者可能导致 broker 的 I/O 线程占用过多，拖慢其它 partition 的响应时间。
配额管理的技术实现
Kafka 原生支持配额（quota），通过 Kafka admin API 可以设置：
// 伪代码：设置消费者组配额
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
AdminClient admin = AdminClient.create(props);
Map<ClientQuotaEntity, ClientQuotaAlteration> quotas = new HashMap<>();
quotas.put(
new ClientQuotaEntity(Map.of("user", "team-a")),
new ClientQuotaAlteration(List.of(
new ClientQuotaAlteration.Op("consumer_byte_rate", 10000000.0)
))
);
admin.alterClientQuotas(quotas);
Kafka 的配额是 broker 级别的，粒度到用户或客户端 ID。更细粒度的配额（如 topic 级别、分区级别）需要额外开发。
配额管理的工具化
手动的配额管理在大规模下不现实。常见的辅助工具包括：
| 工具 | 作用 | 触发时机 |
|---|---|---|
| 配额计算器 | 输入消息量，输出推荐配额 | 初始申请时 |
| 使用率仪表板 | 实时监控各业务线配额使用率 | 持续 |
| 超限自动伸缩 | 使用率 > 90% 时自动申请扩容 | 持续 |
| 配额审计报告 | 每月生成各业务线配额使用效率 | 月末 |
这些工具不属于 Kafka 的标准发行版，需要团队自己维护。但配额管理的投入回报率很高——一次因超限导致的集群故障，修复成本可能就超过了所有配额工具的开发和维护成本。
配额超限的应急方案
即使有了配额管理，超限仍然可能发生。应急方案包括：
- 临时扩容：Kafka 的配额是动态调整的，可以在不停机的情况下增加配额。
- 流量降级：消费量大的业务线优先降级，保障核心业务的配额。
- 紧急扩容：如果集群资源不足，临时增加 broker 节点（自动化扩容脚本）。
应急方案必须在平时演练。如果在超限事件发生时才第一次执行应急方案，成功率不高。
配额与性能的关系
配额管理不只是资源限制，也是性能隔离。一个没有配额的共享集群，一个业务线的突发流量可能导致整个集群的 GC 压力增加，影响其它所有业务线的延迟。
性能隔离的关键是：配额不仅要限制写入量，还要限制读取量。一个消费速率过高的消费者可能导致 broker 的 I/O 线程占用过多，拖慢其它 partition 的响应时间。
配额管理的技术实现
Kafka 原生支持配额，通过 Kafka admin API 可以设置用户级别的配额。Kafka 的配额是 broker 级别的，粒度到用户或客户端 ID。更细粒度的配额（如 topic 级别、分区级别）需要额外开发。
为什么配额告警经常被忽略
配额告警被忽略的原因通常是：告警阈值设得太低。如果存储配额 100GB，告警阈值设在 50GB，业务线会觉得还有很多空间，不着急处理。合理的做法是：告警阈值设在 80%，但通知文案写清楚剩余空间和预计超限时间。
配额管理的工具化
手动的配额管理在大规模下不现实。常见的辅助工具包括：配额计算器、使用率仪表板、超限自动伸缩、配额审计报告。这些工具需要团队自己维护，但投入回报率很高。
为什么配额管理经常被轻视
很多团队认为「配额是运维的事，开发不用管」。这是一个危险的观点。开发者在写消费者时选择的 fetch.min.bytes、max.poll.records 直接决定了消费者的带宽使用量。如果开发者不理解配额，可能会写出「合法但贪婪」的消费者——代码没有 bug，但在共享集群上却是不负责任的邻居。
配额管理需要开发和运维共同参与。开发负责「知道自己用了多少资源」，运维负责「设定上限并监控」。两者缺一不可。
配额告警的文案设计
配额告警的文案决定了告警的响应率。好的文案包含三个要素：当前值、阈值、剩余时间。
| 告警文案 | 响应率 | 原因 |
|---|---|---|
| “库存业务线存储使用 82GB/100GB” | 低 | 没有紧迫感 |
| “库存业务线存储使用 82%，预计 3 天后超限” | 中 | 有紧迫感但无行动指引 |
| “库存业务线存储 82%，3 天后超限。建议：清理过期日志或申请扩容” | 高 | 紧迫感 + 行动指引 |
第三个文案的响应率最高，因为它不仅告知问题，还提供了可行的解决方案。告警不是通知，而是行动触发器。
本节判据
- 配额管理覆盖存储、消息数量和带宽三个维度。
- 三种超限策略：HARD_REJECT、SOFT_WARN、DELAY，按业务场景选择。
- 告警阈值早于拒绝阈值，留出与运维响应时间匹配的窗口期。
- 成本分摊按「消息量 × 消费者数」为权重，不是简单按消息量。
- 配额管理四步闭环：初始申请、季度 review、紧急扩容、超额计费。
- 配额告警必须发给有权限决定扩容的人，不只是技术团队。
- 配额管理是性能隔离的关键，不限速的共享集群等于性能上互相拖累。
- 应急方案必须在平时演练，不能在事故时第一次执行。
- 配额管理需要开发和运维共同参与，不是单方面的工作。
- 告警文案应包含当前值、阈值、剩余时间和行动建议，响应率才高。
配额管理的常见陷阱
配额管理最常见的三个陷阱：
- 静态配额：配额设定后从不调整。业务增长了，配额没动，最终必然超限。
- 单一维度：只监控存储配额，忽略带宽和消息数量。带宽超限同样会导致集群故障。
- 缺乏应急演练：超限发生时才第一次执行应急方案，成功率极低。
避免这些陷阱的方法是：把配额管理纳入季度 review，多维度监控，定期演练超限应急方案。
阅读导航：上一节 11.2 Topic 命名与生命周期 ｜ 下一节 12.1 事件风暴工作坊
配额管理的度量指标
配额管理的效果需要通过指标来度量：
| 指标 | 计算方法 | 健康值 |
|---|---|---|
| 配额使用率 | 实际使用 / 配额上限 | < 80% |
| 超限次数 | 月度统计 | 0 |
| 告警响应时间 | 告警到处理完成 | < 2小时 |
| 配额调整频率 | 季度调整次数 | 1-2次 |
这些指标应该在团队例会中 review，确保配额管理不是「设置后就忘记」的工作。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。