不靠谱的糖饼前阵子团队招人，十份简历里有七份写着“精通高并发”。我通常会在电话面里先抛一道看似人畜无害的场景题：给你一个点赞功能，让你设计背后的计数系统，你准备怎么设计？这道题有意思的地方在于，它问倒过不少写了三年以上业务代码的候选人。有人上来就聊 Redis 的 INCR，有人直接丢出 Kafka 异步落库方案，还有人不假思索地说“不就是 update 一张表嘛”。这三种回答在我这里都只能算刚刚起步。
这么说吧，点赞计数系统表面上是一个数字的增减，可它背后牵扯的是数据一致性、热点数据并发瓶颈、存储成本、防刷风控以及架构演进节奏，每一环都能单独拆出来聊半天。我在电商、社区、视频这三类产品里都亲手搭过计数模块，踩过的坑比看到过的方案多得多。这篇文章不打算给你一个“标准答案”，而是把从需求澄清到最终落地的完整思路拆开揉碎，讲清楚每一步为什么这么设计，以及哪些地方最容易翻车。无论你是准备面试，还是正在给自家产品设计计数服务，应该都能用得上。
1. 一个点赞数背后藏着多少层复杂度
先想一个问题：一个数字，加一减一，能有多难？真正动手做的时候你会发现，难点从来不在“会数数”，而在“数在什么上下文里被数”。
1.1 计数系统不是一个系统，而是一族系统
“计数系统”这四个字在不同产品里有完全不同的形态。视频播放量、文章阅读量、点赞数、收藏数、粉丝数、评论数、购物车商品数、库存数，全都叫计数，可它们在一致性要求上差着十万八千里。
拿播放量来说，它天生允许误差。视频平台展示“10.8万次播放”，真实是 10 万 7999 还是 10 万 8003，没有人care。客户端上报可以合并、可以批量、可以本地攒几秒再发，甚至服务端可以把同一个用户的重复上报按策略过滤掉一部分。
但点赞不是这样。点赞有三个特征直接改变了设计：
- 有状态：一个用户对一个内容只有“赞过 / 没赞过”两种状态，而且可以取消；
- 需要精确：用户看到的“点赞数”必须是一个确定值，不允许我看到的和隔壁同事看到的不一样；
- 身份相关：接口必须同时回答“这个内容有几个赞”和“我有没有点过赞”两个问题。
这就让点赞计数和浏览计数走了一条完全不同的技术路线。很多人一上来就套用“Redis + MQ 异步落库”的万能模板，却不先问清楚自己到底在计什么数，这就是为什么我特别爱问这道题——它能把一个人对系统的理解深度照得明明白白。
1.2 难点的真正来源：热点
抛开播放量那种可以模糊处理的场景，点赞计数真正的难点是热点。一个普通帖子一天几百个赞，任何方案都轻轻松松；但你的爆款内容上线十分钟来了 50 万赞，所有写请求都聚集到同一行数据、同一个缓存 key 上，这时候你会亲眼看到数据库连接池是怎么被拖垮的。
热点问题在业内有个通俗的类比：普通场景是每个收银台各排一队，爆款场景是所有人都涌向同一个收银台，后面还排着几千个柜台闲置。计数系统的架构设计，很大程度就是在跟“单点热点”做斗争。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先别急着写代码：这道题的需求边界在哪里
我面试时最看重的一个能力，是动手之前先问问题。很多候选人拿起笔就想画架构图，但连“这个计数允不允许有误差”都没问过，这就露怯了。真实项目里也一样，产品经理说“做个点赞”，背后有一堆隐藏决策等着你去澄清。
2.1 动手前必须问清的五个问题
我整理了一下，设计计数系统前至少要澄清这么几件事：
| 问题 | 为什么关键 |
|---|---|
| 计数对象是什么？帖子、评论、用户主页，还是混合多类型 | 决定表结构、缓存 key 设计、路由策略 |
| 计数值必须精确，还是允许近似 | 精确则依赖数据库事实，近似则可以用采样、HLL 等手段 |
| 用户能否对同一目标重复操作？能否取消 | 有状态计数要处理状态流转，无状态计数只需叠加 |
| 估算的日增量、峰值 QPS、读写在什么量级 | 决定要不要分库分表、要不要引入 MQ 和缓存 |
| 历史明细要保留多久 | 明细表是最大的存储成本，可能要做冷热归档 |
拿点赞举例，澄清完通常是这样的需求：用户可以对内容点赞和取消赞，一人一票，点赞数全站精确展示，允许秒级延迟，日新增点赞明细可能上亿条，历史明细需要保留。有了这个基线，选型才不会走偏。
2.2 点赞和浏览量在一致性上是两种物种
很多人会把浏览量和点赞量混在一起设计，这是个隐蔽的坑。我把两者放在一起对比一下：
| 维度 | 点赞数 | 浏览/播放量 |
|---|---|---|
| 精确度 | 必须精确 | 可近似、允许误差 |
| 状态性 | 有状态，支持取消 | 基本无状态，只要去重策略 |
| 数据来源 | 服务端写接口 | 客户端上报 |
| 展示一致性 | 所有用户看到同一值 | 接受分批和延迟 |
| 单用户行为 | 一用户一票 | 一用户可多次触发 |
因为点赞有“我到底点没点过”这个状态位，系统不能只维护一个全局数字。你既需要回答“总数是多少”，又需要回答“某个用户对某个目标的状态是什么”。这一下就衍生出两类数据：明细数据和聚合数据。这也是整篇文章接下来所有设计的地基。
2.3 用五分钟做一次量级估算
面试官不指望你把 QPS 算到个位，但你要能快速估算量级。这里给一个通用的手算思路。
假设 DAU 1000 万，平均每个用户每天点 5 个赞，那么日新增点赞明细量是：
5000 万条/天，平均每秒约 580 条。
再按“晚高峰是均值 5~10 倍”的经验系数放大，写 QPS 大约在 3000~6000。这个量级对 Redis 来说完全不是事，但如果你设计成“每次点赞都 update 数据库里同一行”，几百的并发就能把那一行锁排队排到爆炸。
读侧通常更夸张。信息流场景里，用户每刷新一次，接口要一次性返回 20 条内容的点赞数，算上取消赞、重复刷新、多端同步，读 QPS 常常是写 QPS 的几十倍。这个“读多写少”的基调决定了缓存必然是核心手段。
至于存储，5000 万条 / 天意味着一年就是 18 亿条明细，单表肯定扛不住，分表方案从一开始就要想清楚。
3. 数据模型：计数表与明细表的分工才是地基
不管上层用多少 Redis、多少 MQ，底层最后的靠山一定是数据库里的两张表：一张记事实，一张记聚合。很多系统烂就烂在只建了一张表。
3.1 明细表存“事实”，计数表存“聚合”
先看建表。这是我最常用的一套结构，你可以直接抄。
明细表记录“谁在什么时候对什么目标做了什么”：
sql复制CREATE TABLE like_record (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
target_type TINYINT NOT NULL COMMENT '1-帖子 2-评论 3-用户主页',
target_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
status TINYINT NOT NULL DEFAULT 1 COMMENT '1-点赞 0-取消',
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE KEY uk_target_user (target_type, target_id, user_id),
KEY idx_user_target (user_id, target_type, target_id)
) ENGINE=InnoDB;
聚合表只存一个数字，为了查询而生：
sql复制CREATE TABLE content_counter (
target_type TINYINT NOT NULL,
target_id BIGINT NOT NULL,
like_count BIGINT NOT NULL DEFAULT 0,
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (target_type, target_id)
) ENGINE=InnoDB;
为什么非要两张表？如果你只有聚合表，某个用户来问“我点过这个帖子吗”，你完全答不上来；如果你只有明细表，每次展示点赞数都要执行一次 SELECT COUNT(*) FROM like_record WHERE target_type=1 AND target_id=...，这种全表扫描级别的统计在千万级明细下跑一次就要几百毫秒，完全不可用。
所以常规做法是：明细表是唯一事实来源，聚合表是明细表的缓存投影。数据对不上时，以明细表为准重新计算。
3.2 唯一键和状态字段是并发下的两堵墙
注意 uk_target_target (target_type, target_id, user_id) 这个联合唯一键，它是数据库层面防止重复点赞的最终防线。哪怕两个一模一样的点赞请求同时到达，数据库也只会插入一条记录。在业务代码里配合 INSERT ... ON DUPLICATE KEY UPDATE status = 1 就能把“重复点赞”变成“状态重置”，天然幂等。
取消赞我建议用状态位，而不是物理删除：
sql复制UPDATE like_record SET status = 0
WHERE target_type = 1 AND target_id = ? AND user_id = ?;
删除简单直接，但有两个问题：一是用户反复点赞取消时会产生大量删除和插入，主键和索引碎片化严重；二是历史行为痕迹没了，将来做风控、做用户画像回看记录时无据可查。用 status 字段则既保留了历史，又可以用 COUNT(*) WHERE status=1 拿到当前真实点赞数。
索引方面也要留个心眼。uk_target_user 是给“某内容某用户的状态查询”用的；如果你还要做“我赞过的列表”，得额外建 idx_user_target (user_id, target_type, target_id)，否则这条高频查询会把明细表扫穿。
3.3 什么时候分表、按什么键分表
18 亿条明细不用全塞一张表，这是必须提前规划的事。分表路由有两种主流选择：
- 按 user_id 分表：方便“我赞过哪些内容”的查询，对单用户视角友好；
- 按 target_id 分表：方便“某个内容有哪些人赞过”的统计和风控查询。
实际落地常常没法两头兼顾。我的经验是按 user_id 分表做主链路，因为用户服务端延时最敏感的场景是“我赞过没有”“我的点赞列表”，而单内容的整体统计反正要靠聚合表，明细表的全量统计任务可以放到离线数仓跑，没必要让在线库扛。如果你同时需要两种在线查询，那就得接受双写或者引入搜索引擎，复杂度会明显上台阶。
聚合表因为“一物一行”，天然没有分表压力，但它才是热点问题的源头，解决它要靠缓存和后面讲的子桶化。
4. 写路径：点赞约等于一次转账，状态流转才是核心
点赞有一个经常被低估的复杂点：它不是一个简单的 +1，而是一种状态变更。一个用户点赞时，系统必须知道“用户当前是否已赞”；取消时，必须知道“他之前是否点过赞”，然后相应地加一或减一。这就像转账——你不能只关心账户余额，你还得校验状态是否允许这笔操作。
4.1 直接操作数据库为什么会在热点上翻车
最朴素的方案长这样：
sql复制UPDATE content_counter SET like_count = like_count + 1 WHERE target_id = ?;
这条 SQL 本身原子、安全、正确。问题是当所有流量都集中到同一行时，InnoDB 的行锁让所有 update 请求串行排队。一个爆款帖子高峰每秒来 5000 次点赞，数据库行锁队列瞬间堆积，单条更新 RT 从 1ms 膨胀到几百毫秒，连接池被打满，然后整个服务雪崩。
你可以给这种场景一个很直观的画面：就像河上只有一座独木桥，河那边 5000 个人等着过河，桥本身再结实也没用，瓶颈在“单点通行能力”。数据库一行记录的极限也就每秒几百到一千次更新，扛不住热点流量。
4.2 把读写先扛进 Redis：原子计数与 Lua
既然数据库是独木桥，那就先别让流量直接过桥。Redis 单线程执行指令，单 key 每秒能扛十万级操作，拿来做热点计数再合适不过。
写路径的实时部分我会这样设计：
- 计数：
INCR like_count:{target_id}； - 去重：
SADD like_users:{target_id} {user_id}； - 查询用户是否已赞：
SISMEMBER like_users:{target_id} {user_id}。
但“先查再加入”不是原子的。假设用户刚好点了两次赞，两个请求都执行到“查”这一步，发现都没赞过，然后都执行“加”，计数就被加了两遍。要解决这个问题，得把“判断 + 写入 + 计数”塞进一个 Lua 脚本，Redis 单线程执行脚本时天然隔离并发：
lua复制-- KEYS[1]: like_users:{target_id}
-- KEYS[2]: like_count:{target_id}
-- ARGV[1]: user_id
if redis.call('SISMEMBER', KEYS[1], ARGV[1]) == 0 then
redis.call('SADD', KEYS[1], ARGV[1])
redis.call('INCR', KEYS[2])
return 1
end
return 0
取消赞就是另一条类似脚本：SREM 加 DECR。注意这个设计里，Redis 里的集合和计数是一起更新的，不会出现“数加了但人没记上”或者反过来。
这里有个前提要交代清楚：Redis 里的 liked 集合不可能无限存。如果一个爆款帖子有 1000 万人点赞，SADD 存 1000 万个 64 位整数，内存能吃掉几百 MB。所以实际工程中，这个集合只对“近期热点内容”开启，冷内容的“是否已赞”查询直接回源 MySQL 明细表，再配合本地缓存做短时间加速。判断“热不热”可以看计数阈值，比如点赞数超过 1 万就升级为热点内容。
4.3 异步落库：MQ、批处理与乱序问题
Redis 是把实时流量接住了，但内存终究会丢数据。点赞的持久化事实必须落到 MySQL，这时候就到了大家最熟悉的“异步落库”环节。
完整链路是：客户端 → 计数服务 → Redis 原子更新 → 发送 MQ 消息 → 消费者写 like_record，并更新 content_counter。
为什么不直接在点赞请求里写库？因为热点场景下数据库扛不住，而 MQ 把“实时计数”和“持久化”解耦开，请求在 Redis 层就完成了主要工作，数据库只承担异步的、可批量的写压力。消费者攒一批消息批量执行 SQL，比如每 200ms flush 一次，同一目标的 count 变化还可以合并成一条 update，数据库压力能降一个数量级。
这里有两个必须处理的细节，处理不好就是线上事故：
第一个是消息乱序。用户连点“赞、取消、赞”，三条消息如果乱序变成“赞、赞、取消”，最终认为用户是取消状态，计数也错了。解决办法是让同一 target 的消息进同一个 MQ 分区，Kafka 保证分区内有序。只要你用 target_id 当分区键，并且生产者不启用会导致重排的重试机制，顺序就能保住。
第二个是重复消费。MQ 的投递语义通常是 at-least-once，消费者挂了重启，同一条消息可能被消费两遍。明细表那边有唯一键兜底，重复插入会变成更新，不会产生两条；但聚合表的 like_count + 1 操作本身不是幂等的，执行两遍就是加两次。所以消费者侧要加一张消息去重表，用消息 ID 做唯一键，处理过就跳过：
sql复制CREATE TABLE mq_consume_log (
msg_id VARCHAR(64) PRIMARY KEY,
target_type TINYINT,
target_id BIGINT,
user_id BIGINT,
action TINYINT,
create_time DATETIME
);
先是事务里插入 consume_log，再执行明细表更新和聚合表更新，用 msg_id 防重。这套“分区有序 + 消息幂等”的组合，是异步落库不出乱子的底线。
5. 读路径：把“看到数字”这件事做到毫秒级
写路径解决了，读路径同样不能掉链子。一个 C 端信息流页面要展示几千个内容的点赞数，还得同时告诉每个用户“你有没有赞过”，这个读压力比写压力大得多。
5.1 缓存分级：本地缓存兜热，Redis 兜底
点赞数读取的常规做法是三级缓存，从快到慢：
- 本地缓存（Caffeine/Guava）：每台机器各自缓存一份，TTL 1~3 秒；
- Redis：所有机器共享的计数缓存，TTL 5~15 分钟；
- MySQL 聚合表：兜底数据源。
为什么要把本地缓存放最前？因为爆款内容的点赞数被几百万用户同时刷，这些请求如果全部打到 Redis 上，就算 Redis 扛得住，网络带宽和连接数也会先报警。本地缓存每台机器只回源一次，一秒钟内所有同机请求都走内存，成本几乎为零。
点赞数延迟一两秒用户完全无感，所以便宜的最终一致在这里完全够用。我经常跟团队说一句话：不是所有数据都需要强一致，把钱花在刀刃上。
批量场景也要独立设计。信息流接口一次返回 20 条内容，不可能发 20 次 Redis 请求，正确的姿势是 Pipeline 或 MGET 一把梭：
bash复制MGET like_count:1001 like_count:1002 ... like_count:1020
同样的，用户是否已赞也可以批量查：SISMEMBER 不适合批量，那就换 SMISMEMBER like_users:{target_id} uid1 uid2 ...，或者干脆用 Hash 结构存储用户状态，HMGET 一把取回。
5.2 热点 key 怎么防止缓存击穿
缓存有一个经典事故场景：某个爆款帖子的计数缓存刚好过期，结果同一瞬间来了 10 万个查询，全部穿透到 MySQL，数据库直接被打挂。这叫缓存击穿，在计数系统里尤其常见，因为爆款内容天然就是热点 key。
三种主流应对手段：
- 逻辑过期：缓存永不过期，但 value 里带一个过期时间戳。读到过期值时，只允许一个线程去重建缓存，其它线程先返回旧值。用户看到的多是几秒前的旧数字，完全无感；
- Singleflight：同一时刻对同一 key 的回源请求合并成一个，其他请求等待这个请求的结果。这是击穿的标准解法；
- 预置空值：对所有可能被查询的 target_id，提前写入
like_count:xxx = 0的缓存占位，TTL 短一点。这样可以挡掉对“不存在内容”的恶意穿透。
我自己的偏好是“逻辑过期 + 单飞”组合，因为点赞数的旧值对用户没有伤害，宁可用旧值也不让数据库受罪。
5.3 点赞数和“我赞了吗”必须成对返回
前文反复强调过：点赞接口不能只返回数字。用户进入一个内容页，UI 需要同时展示两个信息——总点赞数、我有没有点过赞。设计与实现要将这两个数据打包返回：
json复制{
"like_count": 128405,
"liked": true
}
liked 的读取如果每次都查 MySQL 明细表，十来万 QPS 下明细表很快就会被打穿。所以用户点赞状态也要走缓存。推荐方案：user_like:{user_id}:{target_id} 存一个 0/1，或者复用热点内容的 like_users 集合。点赞时在写路径里同步写这个状态缓存，不用等 MQ；取消赞时同步删掉。缓存缺失时回源 MySQL，再回填缓存。
这里要留意一个一致性问题：用户刚刚点了赞，如果读过期的 liked=false，他可能会再点一次，系统再走一遍去重逻辑，最终不会重复计数，但用户体验差。所以 liked 状态缓存 TTL 要非常短，或者干脆对当前用户实时写、实时读，不做延迟。
6. 数据打架怎么办：幂等、对账、补偿三板斧
分布式系统里最不缺的就是“数据打架”。Redis 坏了、MQ 丢了、消费者重复跑、上线发了个有 bug 的版本，任何一个环节出问题，都可能让 Redis 里的计数和 MySQL 里的真实值对不上。我在生产环境里见过太多数字对不上的事故，所以这块必须单独聊。
6.1 幂等设计：靠唯一键挡住重复请求
重复点赞最常见的来源有三个：网络超时重试、用户连点、网关或客户端框架的自动重试。防住它们的思路是分层幂等。
第一层是 Redis 的 SADD，它天然幂等，同一个人加两次集合只算一次；配合 Lua 脚本里的“先判断后写入”，实时计数就不会被重复加。
第二层是数据库唯一键。即使 Redis 挂了或者消息重复投递，INSERT ... ON DUPLICATE KEY UPDATE 也能保证明细不重复。注意，把取消赞也设计成“UPDATE status=0”，同一个请求重放两次，状态还是 0，幂等成立。真正的难点在于“点赞消息重放两次会不会把 count 加两次”这个问题，我前面说的 mq_consume_log 去重表就是为此准备的，这层不能省。
6.2 对账任务：让 Redis 与 MySQL 最终握手言和
幂等挡住重复，但挡不住故障。Redis 重启丢数据、中间件消费堆积、代码逻辑 bug，都会造成计数不一致。这时候就需要对账机制来做最后一道防线。
我的建议是从第一天就埋一个最简单的对账任务，哪怕开始只是每小时全量扫一遍。对账的逻辑不复杂：
- 扫描 content_counter 聚合表；
- 每一行回源明细表执行
COUNT(*) WHERE status=1得到真实值； - 和聚合表当前值、Redis 里的值三方对比；
- 不一致时以明细表为准回写。
全量扫太慢的话，可以对账“最近有变更的目标”。具体做法是维护一张 update_log 表，任何点赞/取消都往里面记一笔带 target_id 的变更记录，对账任务就扫这个表识别出“今天动过的目标”，再逐个核对。这样每天凌晨跑一次小时级任务，就能把绝大部分脏数据修回来。
讲个真实教训：早期我们复用公司的 Redis，实例配的淘汰策略是 allkeys-lru，结果内存压力一大，计数 key 就被当冷数据淘汰了。缓存淘汰后不仅读要走 MySQL，计数还短暂对不上。后来单独划了一个 Redis 实例给计数服务，淘汰策略改成 noeviction，问题彻底消失。热门计数数据不应该被当普通缓存淘汰，这个经验写在这里，希望能帮你少踩一次。
6.3 刷赞检测：别让数字骗了你自己
技术做到位了，还得防人。点赞数一旦被刷，影响的不只是面子上难看，还会污染推荐权重、榜单排名、运营决策，属于“数字失真的连锁反应”。
写路径上加几个基础风控规则，成本很低，效果立竿见影：
- 用户维度：单用户每分钟点赞次数限制，比如 60 次，超限直接拒绝；
- 设备维度：同设备、同 IP 短时间大量操作同一目标，标记异常；
- 内容维度：单内容点赞速率突变，比如 1 分钟内增加 5 万，触发人工复核；
- 账号维度：新注册用户、低活跃账号的点赞可以降权或进入延迟计数的灰名单。
真正复杂的行为风控可以交给独立的风控系统，计数服务只需要留好“事件流”输出和“封禁名单”接入的口子。对账单、对阈值、对异常，这些能力一开始不一定要全做，但数据模型上要留出扩展空间。
7. 演进路线：从单库到百亿计数的三阶段
很多读者看完上面的方案可能会问：我是不是一上来就得把 Redis、MQ、对账全上了？我的答案很明确：不是。计数的架构一定要跟随业务体量走，过度设计比不设计更可怕。
7.1 阶段一：单体应用硬扛
产品验证期，DAU 不到一百万，一天点赞量几十万，这时候连 Redis 都不一定需要。一张 like_record、一张 content_counter，加上前面建的那些索引，完全够用。
接口里查计数就走聚合表，查“是否已赞”就走明细表唯一键。SQL 写简单点，业务逻辑直白点，出了 bug 也容易排查。这个阶段最重要的任务是验证产品形态，不是秀架构。硬撑着上 MQ 反而会把简单问题搞复杂。
7.2 阶段二：缓存加速 + 异步落库
当 DAU 涨到几百万，爆款内容开始隔三差五出现，就该上“Redis 实时计数 + MQ 异步落库 + 对账任务”这套完整架构了。这也是本文前面几节描述的方案。
这套架构能扛住的量级大概是：日点赞几千万到几亿，单内容高峰每秒几千次点赞，读侧毫秒级响应。它也是目前绝大多数中大型社区产品的标配。风险点主要在 Redis 故障时的数据丢失，以及最终一致性窗口内的展示偏差。所以对账任务和幂等机制在这个阶段就不是可选项，而是必选项。
7.3 阶段三：计数分片与子桶化
如果有一天你的产品里真的出现了“单个内容几千万赞”的超级爆款，前面这套方案会再撞一次南墙：无论 Redis 还是 MySQL，单 key、单行的极限就在那里，再怎么优化也就几千 QPS 级别的写能力。
这时候要用的招是计数分片，也叫子桶化。把一个热点的计数器拆成 N 个子桶，比如 100 个：
- 写请求根据 user_id 哈希取模，落到某个子桶，只往那个子桶
INCR； - 读请求把 100 个子桶的值一次性
MGET回来求和。
MySQL 侧的聚合表也做同样的拆分，加一个 bucket_id 维度：
sql复制CREATE TABLE content_counter_shard (
target_type TINYINT NOT NULL,
target_id BIGINT NOT NULL,
bucket_id TINYINT NOT NULL,
like_count BIGINT NOT NULL DEFAULT 0,
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (target_type, target_id, bucket_id)
);
这样“100 个收银台同时开”，每个子桶的写压力就降到了原来的百分之一。读的代价是 100 次取值和求和，耗时从 1ms 变成几毫秒，完全可接受。这就是把不可消除的热点拆成可并行部件的基本思路。
顺带提一句，浏览量这类允许近似的计数，到超大流量阶段可以直接上 HyperLogLog 做去重统计，因为它只需要估算 UV，不要求逐个记录；点赞不行，点赞必须精确到“谁点了”，所以只能走“明细 + 分片计数”这条路。这个差异，同样值得在面试里主动讲出来。
最后说点题外话。我见过太多团队一上来就上全套 Redis、Kafka、分库分表，结果产品连首个爆款都没出现过，架构倒是先把自己压垮了。计数系统的演进，本质上是跟着业务热度走的。你如果问我个人最看重什么，我会说两件事：一是把“明细”和“计数”彻底分清楚，永远留一个能从事实重新计算出正确数字的接口；二是对账任务要从第一天就埋好，哪怕只是最朴素的定时任务。计数系统不怕慢，就怕错，更怕错了你浑然不知。