系统设计面试中如何讨论延迟问题

“另一方面，我们面向用户的数据平面有 30 毫秒的 p99 写入预算。因为从旧金山到纽约的光纤往返至少需要 55 毫秒，我们物理上不可能等待跨洲的 quorum。我们需要在用户最近的区域本地确认写入，并在后台异步复制到其他区域，牺牲全球强一致性来满足我们的延迟 SLO。”

关于移动客户端的一点说明：4G 或 5G 上的移动用户在数据包到达互联网骨干网之前，就要付出不可避免的无线延迟税。从空闲状态唤醒移动无线电会给第一个数据包增加 50-100 毫秒。如果你在设计移动应用，把后端服务从 15 毫秒压缩到 5 毫秒并不会让应用感觉更快。你需要的是客户端乐观 UI 更新和更少的往返。

在 100 毫秒到 10 秒的尺度上，跨洋电缆、加密握手、重计算和人类感知会发生碰撞。

当物理规律或繁重的第三方 API 阻止你让操作更快时，你无法通过优化代码来解决问题。相反，改变架构，把慢工作移出关键路径：

人类心理也影响 API 设计的规则。任何低于 100 毫秒的操作感觉是瞬时的。一旦请求超过 1 秒，用户就会注意到他们在等计算机。超过 10 秒后，用户会关闭标签页或再次猛击提交按钮。

每当操作需要重计算（如视频编码）、外部银行通道或广泛的下游扇出时，保持同步 HTTP 连接打开会使延迟目标难以实现。相反，考虑解耦请求：让客户端发送幂等键，任务被接受到队列后返回带有 job ID 的 HTTP 202 Accepted，并在完成时通过 WebSockets、Server-Sent Events (SSE) 或轮询通知客户端。

即使你用队列解耦了工作，你的延迟需求也应该决定你在板上放哪个 broker：

当生产者写入延迟和吞吐量是瓶颈时：

“为了让我们的点击流摄取 API 在每秒 100,000 个事件下保持 25 毫秒 p99 以下，生产者不能等待下游分析服务或每消息 broker 记账。Kafka 将批次追加到 page cache，并通过复制而非每消息 fsync 获得持久性，所以即使等待副本确认，我们也能远在预算内确认写入，并让独立的消费者组按自己的节奏读取日志。”

当复杂路由比摄取速度更重要时：

“对于我们的文档转换流水线，摄取量低，用户已经在等待多秒的异步任务，所以低于 10 毫秒的生产者延迟对我们没有任何好处。我在这里会用 RabbitMQ 而不是 Kafka，因为我们需要优先级队列、灵活的路由键和每消息 worker 确认，以及针对长时间运行任务的死信重试。”

超过 10 秒，你就完全脱离了请求-响应生命周期。这是批处理流水线和人工事件响应的世界。

这在系统设计面试中出现在哪里？最常见的是当你设计监控、遥测或告警流水线时，包括云成本异常或 IoT 传感器监控等用例。

如果你的流水线最终是向人工操作员发出告警，那么它的规模应该按照人的反应时间来定，而不是按照流式基础设施能做到什么来定。想想谁在那个通知的接收端。一个睡着的 on-call 工程师需要 10 分钟才能被 PagerDuty 告警唤醒、抓起笔记本电脑、登录 VPN、打开 Grafana，并弄清楚哪里坏了。即使在工作日中间，工程师乐观地也需要 2-5 分钟来切换上下文并分诊问题。

当 webhook 末端的人需要 5 分钟读页面时，从指标摄取流水线中削减 500 毫秒毫无意义。如果你系统的输出是人的行动，30-60 秒的批处理和评估窗口实际上就是实时：

“由于这些告警会呼叫 on-call 工程师，而他们至少需要几分钟来分诊问题，亚秒级流式检测不会给我们带来任何现实世界的速度。与其维护复杂的有状态流处理器来毫秒级评估规则，我们可以每 15 秒检查一次告警阈值，对照最近 30 秒的指标，并且只有在问题持续跨越两次检查时才呼叫。这降低了计算成本，并防止短暂网络抖动呼叫任何人。”

反过来，如果某种故障模式会在几秒内摧毁你的集群（如级联重试风暴或数据库主节点死亡），你不能把向人告警设计为你的缓解策略。如果你的系统处理每秒 50,000 个请求，10 分钟的人工响应窗口意味着在任何人运行一条命令之前就会丢弃 30,000,000 个请求。需要亚秒或个位数秒反应时间的动作（限流、减载、熔断和故障转移）必须在软件中自动化。把分钟级告警流水线留给真正需要人类判断的问题。

候选人有时试图通过直接问面试官来设定延迟目标：“延迟目标应该是什么？”

几乎在每次面试中，面试官要么耸耸肩说“相当快”，要么把问题直接抛回给你：“你认为应该是什么？”

不要等他们把问题弹回来。强有力的候选人在需求阶段主动提出一个基于用户体验的具体延迟目标，然后问面试官是否同意。