统计每个接口每分钟调用次数

日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #场景题

一句话答案

在网关或统一拦截器采集接口标签，按分钟窗口聚合计数，实时监控用指标系统，精确分析用日志或事件流落地到 OLAP。

面试口语版

小规模可以在网关用 接口 + 分钟 作为 Key，在 Redis INCR 并设置过期；生产上更推荐由网关或应用埋点暴露 Counter，Prometheus 抓取后用 rate/increase 统计。若要求长期、精确和多维分析，就把访问事件写入 Kafka，再由 Flink 按事件时间做一分钟窗口聚合，结果写入 ClickHouse。要避免把完整 URL 当标签，否则用户 ID 等路径参数会造成高基数。

关键细节

• 指标标签使用路由模板 /users/{id}，而不是实际 URL。
• 分布式实例本地计数最终汇总，比每次请求同步写 Redis 成本低。
• 明确自然分钟还是滑动窗口、是否允许迟到数据、精确还是近似。
• 同时记录调用量、错误率和延迟分位数，单看次数无法判断服务质量。

面试官追问

1. Prometheus Counter 重启归零如何处理？
2. 高基数标签有什么危害？
3. Flink 如何处理迟到事件？

面试官追问参考答案

1. Prometheus Counter 重启归零如何处理？

Counter 允许进程重启后归零，PromQL 的 rate() 和 increase() 会识别时间序列下降并按重置处理。查询时按实例和标签聚合即可；若实例标签变化，需要通过稳定的服务标签聚合，长期精确计费则不能只依赖 Prometheus Counter。

2. 高基数标签有什么危害？

每种标签组合都会生成独立时间序列，用户 ID、完整 URL 或订单号会导致序列爆炸，消耗大量内存、磁盘和查询 CPU，甚至拖垮监控系统。应使用路由模板和有限枚举，明细分析写日志或 OLAP。

3. Flink 如何处理迟到事件？

使用事件时间和 Watermark 判断窗口何时可计算，并配置允许迟到时间。Watermark 后到达但仍在允许范围内的事件可更新窗口结果，过晚事件进入 Side Output 或补偿流；最终可用离线任务校准。