如何为爆款帖子构建实时的浏览量/点赞计数器？

Question

IT Interview Practice · Accepted Answer

绝不要对一个热门帖子的每个事件执行 `UPDATE posts SET views = views + 1`——那一行会成为锁瓶颈。**在 Redis 中递增，每隔几秒批量刷写（batch-flush）到 DB**，并从 Redis 读取计数。DB 存储持久的总量，而非实时流量。

## 架构

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## 组件与流程

- **Redis INCR** 吸收写入风暴。单个 `INCR views:{post}` 是原子的，在一个键上能处理 10 万+ ops/s——比一个 Postgres 行高出数个数量级。这个计数器是*读取*的真实来源，因此观众能即时看到数字变动。
- **点赞/独立浏览的去重**：原始计数器会把刷新重复计数。使用 `SADD seen:{post} {userId}`，仅在新增成功时才 `INCR`；在海量规模下若需要低成本的近似去重，使用 **HyperLogLog**（`PFADD`/`PFCOUNT`）——几 KB 就能在约 2% 误差内估算数百万独立数。
- **批量刷写器（Batched flusher）**周期性地把增量刷入 DB：`UPDATE posts SET views = views + delta`。每 5 秒或每 N 次递增刷写一次，能把一百万次写入变成寥寥几次——DB 为冷门帖子和分析保存持久总量。
- **读取路径**从 Redis 提供服务；缓存未命中（cache miss）时读取 DB 总量并重新预热 Redis。点赞需要按用户的状态（*我*点过赞吗），因此要存储集合，而不仅是一个数字。

## 面试视角

面试官测试你是否接受**计数的最终一致性（eventual consistency）**。"好"是"缓存计数"；"出色"是缓冲*写入*——认识到瓶颈是热点行上的写争用，而非读负载。他们会考察这个权衡：近似计数可以接受吗？对于浏览量，可以——没人会注意到 1,203,428 与 1,203,450 的区别。陷阱是纠结于精确计数而求助于事务，重新引入了你本要避免的锁。

## 权衡与故障

- **准确性与 throughput**：精确计数需要去重集合（占内存）；近似的 HyperLogLog 又小又快。按功能选择——点赞要精确，浏览量可以近似。
- **持久性（Durability）**：Redis 是内存型的。如果它在刷写前宕机，你会丢失未刷写的增量。启用 AOF 并保持刷写窗口短（秒级）以限定损失；对浏览计数器来说，DB 总量加上一个小缺口是可以接受的。
- **热点键（Hot key）**：爆款帖子会把所有流量集中在一个 Redis 键上。把它分片成 `views:{post}:{0..9}` 并在读取时求和，或把热点键路由到专用节点，使一个帖子无法占满整个 shard。

架构

组件与流程

面试视角

权衡与故障

相关问题