题目重点：把多篇 Netflix Ads onsite 的 frequency cap 题型拆为请求判定、曝光事件、原子计数、跨分片扩容与可观测性取舍；数值规则明确标作训练假设。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练情境设单用户对同一 campaign 在滚动 24 小时最多 3 次已确认曝光，同时可以扩展到 creative、advertiser 或全站级；题目没有固定这些维度和阈值。
- 请求阶段做 reservation，曝光确认才消耗正式次数；reservation 超时释放。若业务以返回广告即计数，则状态机不同，需先确认。
- 示例要求对同一 key 严格不超限、跨 key 可并发；跨区域是否容许短暂误放是产品/商业决策。
解题路线
- 先定事件口径：请求、预占、确认曝光、取消/超时、退款或回补。按 (user,campaign) 建限流键，明确 user 跨设备识别、匿名用户及 campaign 层级。
- 单 key 的检查与预占须原子化，使用有序事件时间戳或带 TTL 的计数结构；每次清掉窗口外确认事件和过期预占，然后判断 `confirmed+reserved < cap`。用幂等 impression id 防重复确认。
- 对高 QPS 按用户或 user+campaign 分片，热点广告/共享总 cap 要另做聚合或近实时分配额度。若跨区域强一致昂贵，可在区域间分配子额度并给出误放上界，不能同时保证零误放和无协调低延迟。
- 曝光事件经持久队列异步入审计与报表，检查在线计数和离线实绩差异；监控拒绝率、误放率、预占超时、计数存储延迟与重试率。存储故障时选择 fail-open 或 fail-closed，并按广告商业风险说明。
手动走一遍
训练例某用户 24 小时内已确认 2 次，两个并发请求都读到 2。若各自先判断再写，会双双放行而达到 4；原子预占使第一个把总占用变 3，第二个拒绝。若第一请求没有真正曝光，其预占到期释放，后续请求可以重试。
规模与取舍
若每 key 窗口内保存至多 C 个已确认曝光与预占，单 key 清理均摊 O(1) 每事件，空间约 O(活跃 key×C)；分布式存储、跨区域同步与事件审计带来额外延迟/容量。近似桶计数更省空间，但边界会产生误放或误拒，需量化。
易错点与追问
容易失分的边界
- 把广告请求次数直接等于用户看到的曝光次数。
- 检查和写入分两步，最后一个名额发生竞态。
- 一个 campaign 的所有用户用同一热点计数键。
- 设备 id 当稳定用户 id，跨设备 cap 失效。
- 仅存 TTL 计数，没定义滚动窗口边界、迟到事件和曝光撤销。
- 把训练数值 24 小时 3 次写成 Netflix 实际业务规则。
继续深挖
- 多层级 cap（creative、campaign、advertiser）如何一次判定与预占？
- 跨区域投放时如何限制最坏超额？
- 曝光事件迟到数小时后是否回溯影响已放行请求？
- 广告主查询频控效果时，线上计数与离线账本不一致如何解释？
