1. 题目与适用场景
SaaS 平台向多个租户提供 API 请求、并发任务和存储空间。每个租户可能有项目级、组织级和资源级配额，部分限制按分钟重置，部分限制按账期累计。业务方希望在请求进入后快速判断是否可用量，同时把真实用量用于告警、审计和计费。请设计配额检查与用量计量服务，说明硬限制、软阈值、超额策略和多区域故障下的行为。
2. 面试官考察点
- 是否能区分 allocation、rate、concurrent 三类限制，并明确作用域和重置语义。
- 是否将同步准入路径与异步用量事件、账单聚合和对账拆开，避免把计量延迟误当成准入事实。
- 是否处理原子预留、幂等键、重复或乱序事件、热点租户和配额配置版本。
- 是否说明跨区域一致性、降级、审计追踪、告警和人工调整的安全边界。
3. 回答前需要澄清的问题
- 要限制的是请求速率、同时运行数量、存储容量，还是账期内累计用量？
- 配额作用域是组织、租户、项目、用户还是资源实例，是否需要层级继承？
- 超过配额时必须拒绝、排队、降级，还是允许超额并在账单中计费？
- 多区域是否要求强一致，事件延迟和最终对账允许多长时间？
4. 30 秒回答框架
我会把系统拆成配额目录、同步准入引擎、预留账本、异步用量事件管道、聚合查询和审计告警。请求携带租户、项目、资源类型和幂等请求 ID，准入引擎按配置版本检查速率、并发和累计配额，并在需要时原子预留；完成或取消时释放预留并产生用量事件。事件带唯一 ID、发生时间和维度，消费者幂等聚合，账期结束后与账本和下游账单对账。多区域按资源选择强一致或有界超卖策略，故障时优先保护硬上限并返回可重试信号。
5. 分步骤深入解答
第一步：建立配额模型和作用域
配额目录保存资源类型、作用域、单位、窗口、上限、是否可调和配置版本。速率配额限制一段时间内的消耗，concurrent 配额限制同时运行操作，allocation 配额限制已分配资源。组织配额可以作为上限，租户和项目配额只能在父级剩余范围内预留，避免每层独立放行导致总量超卖。
第二步：设计同步检查和原子预留
同步路径只处理能影响准入的事实：当前窗口计数、活动预留和配置版本。对单个租户热点键使用分片计数器或按租户分区的强一致存储；预留操作必须检查剩余量并一次性增加预留，避免两个并发请求同时读取同一余额。长任务返回 reservation ID，完成、取消和超时都必须是幂等的。
checkAndReserve(tenant, dimensions, amount, requestId, configVersion)
verify configVersion is active
if requestId already committed: return previous decision
atomically check remaining quota and add reservation
persist reservation with expiry and requestId
return reservationId and retryAfter第三步：把用量事件与计量聚合解耦
请求成功、失败、取消和过期都应产生事件，事件包含租户、项目、资源、数量、单位、发生时间和唯一事件 ID。消息系统至少一次投递时，消费者以事件 ID 去重；乱序事件用事件时间窗口或可重放账本处理。聚合结果用于查询、阈值告警和账单输入，但不能直接覆盖同步预留账本。
第四步：处理超额、配额变更与公平性
硬配额达到上限时拒绝或排队，软阈值只触发告警；是否允许超额必须是产品配置，并记录授权主体和价格规则。降低配额前先检查现有预留，不能让已接受的工作突然失去额度。热点租户不能占满共享分片，可采用租户级并发上限、令牌桶和公平队列。配额增加请求应经过审批或自动规则，并保留旧版本以支持审计。
第五步：多区域、故障恢复与对账
若硬上限必须全球准确，可把关键资源路由到单一权威区域或使用共识存储；若更看重可用性，可按区域分配额度并明确最大超卖量。区域失联时拒绝无法安全判断的硬限制，软限制可以短暂降级为告警。恢复后从不可变事件和预留账本重放，比较准入记录、聚合用量和账单结果，修复差异时保留补偿事件而不是直接改历史。
6. 高质量示范回答
我会把配额目录、同步准入引擎、预留账本、异步计量管道和审计查询分开。目录定义组织、租户和项目作用域，以及 rate、concurrent、allocation 三类限制。准入请求用租户、资源维度和幂等 ID 做原子检查与预留；长任务返回 reservation ID，完成、取消和超时均幂等。成功和失败事件进入至少一次消息管道，消费者按事件 ID 去重并用事件时间聚合，聚合结果供告警和账单使用，但不覆盖准入账本。多区域按资源选择权威写入或有界超卖，故障时保护硬配额；恢复后从事件重放并对账，所有配额变更和补偿都可审计。
7. 常见错误
- 只做一个共享计数器 → 热点租户拖慢所有请求 → 按租户分片并设置公平上限。
- 用异步聚合结果决定同步准入 → 事件延迟造成超卖 → 用原子预留账本维护准入事实。
- 只讨论 rate limit → 长任务和存储无限占用 → 同时建模 rate、concurrent、allocation。
- 用请求 ID 去重却不记录事件 ID → 重试事件重复计量 → 请求预留和用量事件分别建立幂等键。
- 降低配额时直接覆盖余额 → 已接受任务被突然拒绝 → 使用版本化配置并检查现有预留。
8. 追问及应对
追问一：为什么不能只依赖 Redis 计数器？
计数器适合低延迟窗口统计，但跨资源原子预留、长任务过期、配置版本和审计需要更完整的账本。可以用计数器做快路径，但必须有权威记录和重建机制。
追问二：如何保证重复用量事件不重复计费？
为每个事件分配稳定唯一 ID，消费者先写去重记录再更新聚合，或在同一事务中完成。聚合结果可重算，账单只消费已确认的聚合版本，并保留补偿事件。
追问三：多区域网络分区时是否继续放行？
对不可超卖的硬配额暂停或把资源路由到权威区域；对允许有界超卖的软配额按预分配额度放行，并记录最大风险上限。选择必须由业务损失和一致性目标决定。
追问四：如何测试配额服务？
压测同一租户热点、并发预留、重复和乱序事件、配置降级、区域分区、消费者重放和账期切换。断言硬上限不被突破，幂等操作结果稳定，恢复后账本、聚合和账单最终一致。