在一个 REST API 中，rate limiting 和 HTTP caching 如何工作？

Question

IT Interview Practice · Accepted Answer

Rate limiting 保护 server 免受太多请求；HTTP caching 避免为它已经回答过的请求重复工作。两者都在 HTTP 中被标准化，且对一个规模化的生产 API 都不可或缺。

## Rate limiting

server 给一个 client 在每个时间窗口内可发的请求数设上限，超过时返回 **`429 Too Many Requests`**。它通过 header 公布限额，让一个守规矩的 client 能自我节流：

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

`Retry-After` header 精确告诉 client 该等多久。常见算法：**token bucket**（允许突发到桶大小，稳定补充——通常的选择）、**sliding window** 和 **fixed window**（最简单但在窗口边缘会突发）。key 通常按 API key、user 或 IP，计数器放在 Redis 里以服务一个分布式集群。

## HTTP caching

两个互补的机制：

**1. 过期（`Cache-Control`）** —— server 说一个 response 保持新鲜多久，因此 client/CDN **完全不发请求**就重用它：
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. 验证（`ETag` / 条件请求）** —— 当新鲜度不确定时，client 廉价地重新验证。server 给一个 response 打上 **`ETag`**（一个版本指纹）；client 在 `If-None-Match` 中把它送回，如果未改变，server 返回 **`304 Not Modified`**、**没有 body**：

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← empty body, saves bandwidth
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

ETag 还为**乐观并发（optimistic concurrency）**提供动力：在一个 `PUT` 上发送 `If-Match: "a1b2c3"`，如果别人先改了资源，server 返回 `412 Precondition Failed`——防止丢失更新。

## 为什么这很重要

两者合起来，是一个 REST API 如何在规模下存活，因此 senior 面试官用它们来检查运营成熟度。对于 rate limiting，信号是你把它当作一份**合作契约**——暴露 `RateLimit-*` 和 `Retry-After` header，让 client 优雅退避，而不是一头撞墙——并且你能说出一个算法以及在分布式部署中计数器住在哪里（Redis，按 key）。对于 caching，关键洞见是**两层模型**：过期（`max-age`）完全消除请求，而验证（`ETag`/`304`）通过跳过 body 让无法避免的请求变廉价。提到 ETag 还兼职做**乐观并发**（`If-Match` → `412`），表明对 HTTP 语义有更深的掌握。理解这些机制的候选人，正是能构建出在真实流量下保持快速与稳定的 API 的人，而这正是这道题在考察的。

Rate limiting

HTTP caching

为什么这很重要

相关问题