你会如何为 10 亿用户对数据库进行分片（shard）？

Question

IT Interview Practice · Accepted Answer

按一个**几乎出现在每次查询中且能均匀分散负载**的键分片——通常是哈希后的 `user_id`——然后从第一天起就为重新分片（resharding）和跨 shard 查询做规划。10 亿用户在单个节点上装不下也跑不动；你把行拆分到许多数据库上，并把每次查询路由到拥有它的 shard。

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Shard key 选择——难以撤销的决策

选一个**高基数（high cardinality）、分布均匀、且出现在大多数查询中**的键。`user_id` 通常胜出：以用户为范围的查询（"我的资料、我的订单"）恰好命中一个 shard。糟糕的键（例如 `country`）会造成热点——一个 shard 装下整个印度，而另一个闲置。

## Hash 与 range

- **Hash 分片**（`shard = hash(user_id) % N`）：分布均匀，消除热点——但范围查询（"上周创建的用户"）必须跨所有 shard 做 scatter-gather。
- **Range 分片**（`user_id 0–1M → shard 0`）：让范围保持在本地，也让 resharding 更容易，但有热点风险（最新用户都落在最后一个 shard）。
- 常见答案：**用 hash 实现均匀负载**，配一张 **lookup/目录表（directory table）**，使你能在不重哈希全部数据的情况下移动范围。

## Resharding——在需要之前先规划

`% N` 是个陷阱：增加一个 shard 会重映射几乎每个键。使用**一致性哈希（consistent hashing）**或**虚拟桶（virtual buckets）**（把键 → 4096 个逻辑桶 → 物理 shard）。这样拆分一个 shard 只移动桶，而非整个键空间。像 **Vitess**（YouTube/Slack 使用）这样的工具能自动完成带切换（cutover）的在线 resharding。

## 跨 shard 查询

任何不以 shard key 为键的查询都很痛苦：一个全局的"热门帖子"查询会扇出到每个 shard 再合并。通过**反范式化（denormalizing）**或为横切读取维护一个单独的 index/搜索存储（Elasticsearch）来缓解。

## 面试视角

面试官考察你是否理解 shard key 的选择是**半永久的**，以及你是否考虑过 **resharding 和跨 shard join**——这是在生产中会咬人的两件事。好："按 user_id 分片。"出色：你提出一致性哈希、热点 shard 缓解，以及跨 shard 的分布式事务最好完全避免这一事实。

**常见陷阱：**固定 N 的 `hash % N`——它让未来的增长变成一次全量数据迁移。

## 权衡与故障模式

- **失去跨 shard 的 ACID：**跨 shard 没有廉价的 join/事务；使用 saga 或反范式化。
- **热点 shard：**一个爆红用户；对该实体再分片（sub-shard）或缓存。
- **再平衡风险：**在线迁移必须双写，并在切换前验证。
- **运维成本：**N 个 shard × replica = 需要监控、备份和故障切换的大量数据库。

Shard key 选择——难以撤销的决策

Hash 与 range

Resharding——在需要之前先规划

跨 shard 查询

面试视角

权衡与故障模式

相关问题