如何在规模化下处理 10 分钟内的 500 万次投票？

Question

IT Interview Practice · Accepted Answer

不要把每一票直接写入一个数据库行——**缓冲写入、对计数器分片，并接受最终计票（eventual tally）**。10 分钟内 500 万票平均约为每秒 8,300 票，峰值远高于此（电视直播的某个瞬间可能是其 10 倍）。诀窍是把一个热点单行更新变成许多独立、并行的递增。

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## 为什么要缓冲写入

像 **Kafka** 这样的队列把摄取（ingestion）与计票解耦。客户端写入是一次廉价的追加（append）；如果消费者在峰值期间落后，事件会在日志中等待，而不会压垮 DB。Kafka 还提供**重放（replay）**——如果消费者崩溃，你可以从最后提交的 offset 重新处理，不会丢票。

## 分片计数器消除热点

如果对"Option A"的每一票都执行 `UPDATE counter SET n=n+1 WHERE id='A'`，那一行会成为锁争用瓶颈——数千个事务在一行上串行化。相反，把每个选项拆成 **N 个分片行**（`A:0 … A:63`）。每次递增命中一个随机 shard，因此写入分散到 N 行上并行运行。显示的总数是 `SUM(shards)`，由聚合器每一两秒计算一次。在 Redis 中这只是 N 个 `INCR` 键；在 DynamoDB 中则是 N 个 partition key。

## 一人一票去重

用幂等键强制执行"每个用户一票"：`SADD voted:{pollId} {userId}`（或条件写入）。如果用户已存在，在递增前丢弃该事件。在消费者端做这件事，而不是客户端——客户端会说谎并重试。

## 面试视角

面试官在考察你是否识别出**单一热点键问题**，并求助于缓冲 + 分片，而不是"加更多 DB replica"（replica 扩展的是读，而非这种写）。好："用一个队列和一个 cache。"出色：你指出**最终一致性权衡**——实时数字比现实滞后一秒——并论证这对票数没问题，但*不适用于*最终认证结果，后者要在投票结束后权威地重新计算。

**常见陷阱：**为了"准确"而对每一票使用数据库事务。在这种规模下，这正是会崩溃的东西。

## 权衡与故障模式

- **最终计票：**分片求和有滞后；对实时计数器可接受，结束时对账。
- **At-least-once 投递：**Kafka 可能重投——去重让递增幂等，否则你会重复计数。
- **热点分片倾斜：**shard 太少你仍会争用；太多则求和变得昂贵。典型为 32–128 个 shard。
- **公平性/舞弊：**按 IP/设备限流；一人一票的 SET 是你的完整性边界。失去它意味着灌票（ballot stuffing），而非崩溃——可以说更糟。

为什么要缓冲写入

分片计数器消除热点

一人一票去重

面试视角

权衡与故障模式

相关问题