在重度争用下，如何处理一个热点键或热点行？

Question

IT Interview Practice · Accepted Answer

**别再把所有流量都汇聚到一个键上：把热点键拆成 N 个子键（分片计数器，sharded counters），合并重复读取，从本地缓存提供服务，并批处理写入，使一行不必在每次请求时都被更新。**一个爆款帖子上的单个"点赞"计数器可能承受每秒 5 万次写入——当每个事务都争抢同一把锁时，一行就成了串行化瓶颈。

## 用扇出取代一个被争用的行

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## 技术手段

- **分片计数器 / 键拆分。**随机选择写入 `likes:123:{0..N}`；真实计数是它们的 `SUM`。这把一个热点行变成 N 个较凉的行，把锁争用削减约 N 倍。读取付出一点扇入（fan-in）成本。
- **请求合并（single-flight）。**如果 1 万个请求同时想要同一个键，让**一个**去命中 DB，其余的都等待那个进行中的结果。防止一次缓存未命中的踩踏压垮该行。
- **本地（进程内）缓存。**在每个应用节点上以一个短 TTL（例如 1 秒）缓存这个热点值。对一个读热点键，这会把每秒数千次读取压缩成一次刷新——以接受轻微陈旧为代价。
- **写批处理。**在内存中缓冲递增，每秒刷写一次 `+= 500`，而不是 500 次单独更新。每秒一次行更新而非 500 次，彻底消除了争用。

## 面试视角

面试官希望看到你诊断出**争用在哪里**，并把修复方案与读热点还是写热点相匹配。读热点 → 缓存 + 合并；写热点 → 分片计数器 + 批处理。好的回答会列出这些技术；出色的回答会指出分片是用**读成本换写的可扩展性**，而批处理/缓存是用**新鲜度换 throughput**。

**权衡与陷阱：**分片计数器让精确的实时总数更难（你要对 shard 求和），并使"递减到零以下"的逻辑复杂化。本地缓存会在各节点间漂移——对点赞数没问题，对银行余额则是错的。批处理有在节点于刷写前崩溃时丢失已缓冲写入的风险，因此它适合幂等/近似的计数器，而不适合金钱。选择数据的一致性需求所允许的缓解方案。

用扇出取代一个被争用的行

技术手段

面试视角

相关问题