当流量增长 100 倍时，如何扩展 MySQL？

Question

IT Interview Practice · Accepted Answer

分阶段扩展：**先用 read replica + 缓存扩展读，然后用分片（Vitess）扩展写**——并且在做任何事之前先加入连接池（connection pooling），因为它是最便宜的 10 倍提升。读和写的扩展方式不同，所以别在第一天就求助于分片。

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## 第 0 步：连接池

每个 MySQL 连接都消耗内存和一个线程。在 100 倍流量下，你会在耗尽 CPU 之前很久就先耗尽 `max_connections`。像 **ProxySQL** 或 **PgBouncer** 这样的连接池，把数千个应用连接复用到几百个 DB 连接上。这是一次配置变更，而非重构——先做它。

## 第 1 步：缓存读取

大多数工作负载都是读密集的（常常 90%+）。为热点行前置 **Redis**——用户资料、商品页。缓存命中绝不触及 MySQL。使用 cache-aside：读缓存 → 未命中 → 读 DB → 填充缓存。仅这一项就能吸收 100 倍中的大部分。

## 第 2 步：read replica

增加**异步 read replica**，把 SELECT 路由到它们，把写路由到 primary。这在水平方向上扩展读：N 个 replica ≈ N 倍读容量。问题在于 **replication lag**——replica 可能滞后毫秒到秒级，因此"读己之写（read-your-own-writes）"需要小心处理（把该用户的读路由到 primary，或从缓存读取）。

## 第 3 步：分片写入

replica 对写没有帮助——每次写仍然命中单个 primary。当写 throughput 让一台机器饱和时，就**分片**。**Vitess**（在 YouTube 打造）位于 MySQL 前面，负责分片、查询路由和在线 resharding，无需重写应用。按 `user_id` 分片，使大多数查询保持单 shard。

## 面试视角

面试官关注**顺序（ordering）**：立刻分片的候选人暴露出他们不知道 replica/缓存能以低得多的成本解决读扩展。好："加 replica 和 cache。"出色：你把读路径与写路径分开，指出 replication lag 是 replica 的代价，并且只在*写*——而非读——成为瓶颈时才引入分片。

**常见陷阱：**当实际瓶颈是写 throughput 时却"只加 read replica"。replica 会让情况*更糟*（对 primary 增加更多复制负载）。

## 权衡与故障模式

- **Replication lag：**陈旧读；把关键读固定到 primary，或使用半同步复制（semi-sync replication）。
- **缓存踩踏（stampede）：**过期时大量未命中同时冲击 DB——使用锁或错开的 TTL。
- **分片复杂度：**失去跨 shard 的 join 和事务；只在写入迫使你时才付这个代价。
- **Failover：**primary 死亡需要自动提升（Orchestrator）；一个陈旧的被提升 replica 可能丢失最近的写入。

第 0 步：连接池

第 1 步：缓存读取

第 2 步：read replica

第 3 步：分片写入

面试视角

权衡与故障模式

相关问题