贫血王子做了多年社区类产品的后端，真正让我觉得“有点意思”的，不是那些日活千万的首页Feed流，而是评论盖楼。尤其当你的产品被要求做成“类抖音”那种形态：视频底下百万条评论，热评下面楼中楼能叠几百层，用户刷的时候还得秒开，同时评论发布、点赞、回复这些动作在热点事件来临时瞬间暴涨——这个项目表面上是“做个评论区”，本质上是在做一套高并发的树形结构化读写系统。
这篇内容我基于自己完整落地过的一套类抖音评论盖楼系统来写，会从整体架构拆分、数据模型设计、写入链路优化、读取链路优化、Kafka削峰与消息处理、以及实际踩坑排查这几个维度展开。无论是你在准备高并发系统设计的面试，还是真正要在业务里落地一套评论系统，这篇文章都能给你一套可以直接参考复现的完整方案。我会尽量少讲空话，多给具体参数、表结构、缓存策略和压测结论，希望你能直接拿去做技术方案，而不是看完只觉得“有道理”而已。
1. 项目概述与核心目标拆解
1.1 类抖音评论系统到底在解决什么问题
先说清楚一个概念：什么叫“盖楼”。在抖音这类产品里，评论不是平铺的列表，而是具有层级关系的。用户A发一条评论，是一楼；用户B回复A，是二楼，但二楼在界面上是挂在A下面的；用户C再回复B，就形成了嵌套，楼越盖越高。这个“楼中楼”结构，往浅了说是一棵多叉树的存储与展示，往深了说，它牵扯到分页、排序、缓存、计数、并发控制、热点防护等多个环节。
和普通博客评论的区别，最核心的三点：
- 数据量大。热点视频的评论数可以轻松达到百万级以上，楼中楼回复常常在一个热评下堆出几万条。
- 读写比例极端。评论区是典型的高读低写场景，但写操作的特征是“突发性强”，一个热点事件能让写入QPS在几十秒内翻几十倍。
- 实时性要求高。用户发评论后，希望立刻看到自己的内容出现在列表里；用户刷新时，希望看到最新的热评和楼中楼回复。这意味着写链路要短，读链路要更快。
这套系统解决的，就是这三件事的叠加。单纯做一个能用的评论区，PHP单机加MySQL就够；但要扛住“类抖音”级别的流量，必须把读写链路、存储结构、缓存策略都重新设计一遍。
1.2 核心目标与衡量指标
做任何系统设计，先定目标。我们当时立项时给自己定的核心指标是这样一组数字：
- 热点视频评论读取QPS：单视频峰值10万+，全站峰值50万+
- 评论写入峰值QPS：5000+，要求99线响应时间200ms以内
- 读取响应时间：P99 < 200ms，P50 < 50ms
- 数据一致性：评论发出后，读链路在1s内可见（最终一致即可）
- 可用性：核心链路可用性99.95%以上，评论功能不能拖垮主站
注意这些指标不是拍脑袋定的，而是基于当时业务预估来的。你在自己设计时也一样，先问清楚业务量级，再定架构方案。不用一上来就上全套分布式，5000 QPS写入和500 QPS写入的架构复杂度完全不是一个量级。
1.3 适用场景与选型边界
这套方案并非只适用于短视频App。凡是评论、弹幕、帖子回复、问答楼中楼这类“层级+列表+高并发”结合的场景，都可以复用这套设计。比如资讯App的评论、电商的商品评价回复、知识社区的回答评论区，本质上都是同一个模型。
但要注意，如果你的业务量级很小（比如日活几千的博客站），这套方案是完全过度的。我见过不少团队在早期就盲目上Kafka、Redis Cluster、分库分表，结果运维成本比业务成本还高。方案选型一定要匹配业务阶段，这是我说过很多次的话。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计与拆分思路
2.1 架构总览：读写分离是核心思想
整套系统的设计，我遵循了一个最朴素也最有效的原则：读写分离，异步化削峰，缓存兜底。
从请求入口看，评论服务被拆成了三个独立的子系统：
- 评论写服务（comment-write）：接收发布评论、删除评论、点赞等写请求。只做参数校验、用户风控、基础信息校验，然后把消息丢给Kafka，立刻返回“发送成功”。真正的落库和缓存更新在消费者里异步完成。
- 评论读服务（comment-read）：接收评论列表、楼中楼列表、评论详情等读请求。优先走Redis缓存，缓存不命中再查MySQL。通过多级缓存和本地缓存扛住峰值读流量。
- 评论管理服务（comment-admin）：面向运营和审核后台的检索、批量删除、统计功能。这一块流量低，但查询条件复杂，单独拆出来用Elasticsearch支撑，避免复杂的条件查询打到线上库。
三个服务独立部署、独立扩缩容。写服务的流量高峰和读服务的流量高峰可能不在同一时间点，拆开之后相互不影响。比如热点事件来的时候，写流量先暴涨，读流量稍后跟上，两者各自扩容就行。
从部署结构看，整体链路是这样的：
code复制客户端
↓（HTTPS）
API网关（鉴权、限流、灰度）
↓
评论写服务 → Kafka（评论事件）
↓（消费）
评论落库、索引构建、计数更新、缓存重建
↓
评论读服务 → Redis（热评缓存、楼中楼缓存）→ MySQL（全量数据）
2.2 为什么选择Java技术栈而不是PHP
热搜词里有一组是“高并发web服务器选择 java php”，我在这个项目里也认真对比过。结论很直接：核心服务用Java（Spring Boot），周边脚本用PHP，不做二选一。
Java的优势在于：成熟的线程池模型、Netty/Reactor异步网络框架、Spring生态对分布式组件的支持（Kafka、Redis、ShardingSphere都有非常成熟的接入方案）、以及JVM强大的调优空间。评论这种对稳定性和性能都有要求的核心服务，用Java是最稳妥的选择。
PHP则更适合业务迭代极快的场景，比如活动页、后台工具、运营配置系统。当年很多社交产品的评论都是一台PHP直接写完，但并发一上来就瓶颈了——PHP-FPM的进程模型决定了单机扛不了太高的长连接和IO密集型负载。
如果你是在面试里被问到“高并发下选Java还是PHP”，我的答案是：单看语言没有意义，看团队、看业务、看运维能力。但评论这种高并发读写核心链路，Java路线更成熟，参考案例也多。
2.3 模块拆分与团队协作
从开发协作角度，我把系统拆成了7个核心模块：
- 用户校验模块：登录态、黑名单、频率限制，直接调用主站用户服务
- 内容安全模块：敏感词过滤、图片审核、灌水识别，异步执行
- 评论存储模块：负责MySQL分库分表、Kafka消费落库
- 评论缓存模块：负责Redis多级缓存、本地缓存、缓存重建
- 计数服务模块：评论总数、回复数、点赞数，用Redis + 异步批处理
- 查询聚合模块：组装列表数据、用户信息、点赞状态
- 消息通知模块：评论内容推送给作者、@用户的站内信
模块之间通过接口或消息队列解耦，两个团队可以并行开发。这里最重要的经验是：评论存储和评论缓存必须分开设计和部署，因为缓存模块对Redis的运维要求、对内存的容量规划，和存储模块对MySQL的连接管理完全不同，耦合在一起只会互相拖累。
3. 数据模型与存储方案设计
3.1 盖楼的数据结构：从树到表
“楼中楼”本质上是一棵多叉树。最直观的存储方式是邻接表：每条评论记录自己的parent_id，查询时递归取出所有子节点。但这个方案在数据量大了之后是灾难——MySQL的递归查询性能极差，而且盖楼到几十层时，一次查询要拆成几十次SQL，延迟根本压不住。
我们最终用的方案是：“根评论 + 父评论 + 回复路径”三层结构。
具体到表设计，核心是这一张：
code复制CREATE TABLE `comment` (
`comment_id` bigint(20) NOT NULL COMMENT '评论ID，全局唯一',
`target_id` varchar(64) NOT NULL COMMENT '目标ID，如视频ID/文章ID',
`root_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '根评论ID，0表示本身是根评论',
`parent_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '父评论ID，0表示无',
`replied_user_id` bigint(20) NOT NULL DEFAULT 0 COMMENT '被回复的用户ID',
`user_id` bigint(20) NOT NULL COMMENT '评论用户ID',
`content` text NOT NULL COMMENT '评论文本',
`like_count` int(11) NOT NULL DEFAULT 0 COMMENT '点赞数',
`reply_count` int(11) NOT NULL DEFAULT 0 COMMENT '回复数',
`status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '状态：1正常 0删除 2审核',
`create_time` bigint(20) NOT NULL COMMENT '评论时间，存毫秒时间戳',
`update_time` bigint(20) NOT NULL COMMENT '更新时间',
PRIMARY KEY (`comment_id`),
KEY `idx_target_create` (`target_id`, `create_time`),
KEY `idx_root_create` (`root_id`, `create_time`),
KEY `idx_parent` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论主表';
这个表设计里的几个关键点：
- root_id字段是核心。它记录了这条评论所属的根评论ID。这样查询“某条热评下面的所有楼中楼回复”时，只需要一次索引查询：
WHERE root_id = ? ORDER BY create_time，不需要任何递归。这是盖楼系统性能的第一块基石。 - target_id与create_time的联合索引，支撑“查目标下所有根评论”的列表场景。排序用create_time而不是自增ID，因为分布式环境下自增ID不保证时间顺序一致。
- reply_count做冗余。虽然它可以用COUNT()算出来，但高并发下COUNT()是极其昂贵的操作。所以平时通过计数服务异步维护，展示时直接读这个字段。代价是轻微的不一致，通过最终一致性来兜底。
3.2 分表策略：评论应该怎么分
单表存储百万级评论，在MySQL里其实没问题，但存储千万级、亿级评论时，必须分表。我见过很多团队纠结“怎么分表”，其实结合业务访问模式就很容易定。
结论先行：按照target_id哈希分表，而不是range分表。
原因是评论的访问呈明显的“热点聚集”特征：少数热点视频承担了绝大多数评论读写流量。如果按时间range分表，热点视频的评论全部砸在一张表里，根本扛不住。按照target_id取模分表，可以把热点视频的评论分散到多个分片上，流量自然分摊。
举例来说，如果预估单表上限2000万行，线上视频总量很大，那么分64张表：
code复制分表键：target_id
分表规则：target_id.hashCode() % 64
这里有个细节：hashCode()在Java里是均匀分布的，但如果你想让确定性更强，可以自己实现一个CRC32取模或者MurmurHash取模。另外，在分表后，评论ID不能再用数据库自增ID了，需要引入分布式ID生成器。我们用了一段Snowflake的变体，把机器ID和序列号放进去，同时保证生成的ID大致趋势递增，方便排序。
3.3 每层楼怎么查：热评列表与楼中楼列表
在实际业务中，“查评论列表”需要区分两种场景：
- 根评论列表：某个视频下第一层评论，默认按热度排序或按时间排序，分页展示。
- 楼中楼列表：某条热评下的所有回复，默认按时间排序，分页展示。
这两种查询的SQL分别是：
sql复制-- 根评论列表，按时间倒序（或按热度分数倒序）
SELECT * FROM comment
WHERE target_id = ? AND root_id = 0
ORDER BY create_time DESC
LIMIT 0, 20;
-- 楼中楼列表，按时间正序
SELECT * FROM comment
WHERE root_id = ? AND root_id != 0
ORDER BY create_time ASC
LIMIT 0, 20;
楼中楼用正序是因为用户习惯从上往下读对话，像层楼一样一层层往下盖，老的在上新的在下。而根评论列表用倒序，是为了让新评论能第一时间浮上来。这两种顺序取向在实际UI中是固定的，所以查询索引设计也围绕这两个方向来，不需要额外做通用方案。
3.4 热度排序的实现思路
抖音的评论默认排序其实不是纯时间序，而是“热度优先”。那热度怎么算？我们用了最经典的一种权重公式：
code复制score = like_count * 1
+ reply_count * 3
+ time_decay(create_time, 时间衰减系数)
时间衰减的核心逻辑是：带时间维度的权重，让老评论自然沉降，新评论有机会浮现。举个具体例子，一条评论发布时，time_decay给一个基础分，比如1000分，然后每小时衰减一次。衰减用对数函数：
code复制score = like_count + reply_count * 3 + 1000 * pow(0.5, (now - create_time) / 3600000 / 12)
这个公式表示：每过12小时，时间带来的基础分衰减一半。所以一条很老的评论即使点赞很高，也必须靠真实互动才能维持热度。具体系数可以根据产品调性调整，关键是这个思路：热度 = 互动量 + 时间衰减。
排序的实现上，根评论列表在Redis里维护一个ZSET，member是comment_id，score是热度分数。每次有人点赞或回复，通过异步服务更新这个分数。查询时直接ZREVRANGE取前20条热评，性能极好。
4. 高并发写入链路：Kafka削峰与最终一致性
4.1 写入请求的完整链路
用户点“发布评论”后，请求经过网关进入评论写服务，发生的事按顺序是这样的：
- 参数校验与用户校验：评论内容长度、用户登录态、是否黑名单、是否频控。这个阶段必须快，不能在业务逻辑里做重操作。
- 内容安全前置过滤：同步查一次敏感词库，用布隆过滤器先挡一层。如果命中高危词直接拒绝，中危词则打标进审核队列。这一步放在同步阶段只做“拦截明显违规”，不做过重的模型推断。
- 生成全局唯一评论ID：通过Snowflake生成。
- 组装消息体，发送到Kafka。
- 返回前端“评论发送成功”。
注意，评论内容没有直接写进MySQL，而是先进入了Kafka。这就是削峰的关键。
4.2 为什么必须用Kafka而不是直接落库
如果直接在写服务里落库，高并发峰值到来时，MySQL的写入连接会被瞬间打满，后面所有请求都会排队超时，甚至拖垮数据库。而Kafka的本质是一个高性能的缓冲队列，它可以瞬间接收大量消息，然后由消费者按照数据库能承受的速度慢慢落库。
这就是所谓的“削峰填谷”——峰值流量被Kafka这个水库拦住了，下游的MySQL按自己的节奏放水，不会一下被冲垮。
具体到Kafka配置，我们当时的Topic设计是这样：
code复制Topic: comment_write
Partitions: 16
Replication: 3
Retention: 72小时
分区数的选择是16，这个数字不是随便拍的。它要同时满足两个约束：
- 下游消费者的并发度要跟分区数匹配，消费者组内每个实例消费一个分区，所以分区数等于最大的消费者并行度，16个分区意味着可以开16个消费者实例同时消费。
- 单分区写入顺序是保序的，同一个分区内的消息按序消费，而我们要保证“同一个评论下的回复”和“同一用户的操作”按顺序处理。通过指定key将相同root_id或user_id的消息路由到同一个分区，可以保证这部分消息的有序性。
实际压测下来，单分区写入能力在kafka默认配置下可以到每秒几千条，16个分区扛住每秒几万条写入完全没问题。
4.3 消费者侧：落库、索引、缓存更新
Kafka消费端是这个系统里逻辑最重的一块。一条评论写进来，消费端要同时做四件事：
- 组装评论表记录，写入MySQL。按target_id分表后，
INSERT INTO comment_XX ...。 - 更新计数：目标视频的评论总数+1，根评论的reply_count+1（如果是楼中楼评论）。
- 构建热评缓存：如果是根评论，把comment_id和初始热度分数写入Redis ZSET。
- 通知下游：把评论事件推给通知服务，给评论作者和被回复的用户发站内提醒。
这四件事里，第1件是必须同步完成的（为了保证数据不丢），后面三件可以用单独的异步任务池处理。我当时的做法是：在主消费逻辑里完成1和3，2和4丢到另一个线程池去执行。这样可以降低主消费链路的耗时，提高消费者的吞吐。
4.4 Kafka高并发消息处理的核心参数实践
热搜词里有“kafka高并发消息处理办法”，这块我直接给配置和解释，面试和实操都适用。
生产者端核心配置：
properties复制# 批量发送，攒一批再发，降低网络IO次数
batch.size=32768
linger.ms=20
# 异步发送，不阻塞主线程
enable.idempotence=true
acks=all
retries=3
max.in.flight.requests.per.connection=5
# 压缩，降低网络带宽
compression.type=lz4
这里的重点是 enable.idempotence=true 和 acks=all。前者保证消息不会因为重试而重复写入，后者保证消息不会因为leader宕机而丢失。代价是延迟上升，但在评论这个场景里，几十毫秒的延迟完全可接受，数据可靠性和不重复才是第一位。
消费者端核心配置：
properties复制# 手动提交offset，避免数据处理失败但offset已提交的问题
enable.auto.commit=false
# 批量拉取，一次最多处理500条
max.poll.records=500
# 处理超时时间，防止消费者假死
max.poll.interval.ms=300000
# 消费线程池大小，配合分区数
concurrency=16
消费者端最大的坑是处理速度跟不上拉取速度。Kafka的消费模型是：consumer拉取到一批消息后，必须先处理完再拉下一批。如果处理耗时太长，超过了 max.poll.interval.ms，consumer会被判定为假死，触发rebalance，整个消费组要重新规划分区，这期间消费是暂停的。这是线上最容易出问题的地方。
我们的做法是：消费端不直接写MySQL，而是把要落库的评论记录先写入一个内存队列，然后用独立的JDBC批量线程池去执行批量INSERT。这样Kafka的消费者线程只需要做“解析+入内存队列”的轻量操作，拉取效率不受数据库慢查询影响。数据库批量插入用 INSERT INTO ... VALUES (...), (...), (...) 一次插100条，效率是单条插入的十倍以上。
4.5 消息重复消费与幂等设计
Kafka“至少一次”的投递语义，意味着消费者可能会重复处理同一条消息，尤其是在消费者宕机重启后。评论场景下重复消费的后果是：同一条评论落库两次、计数重复增加。这是绝对不能接受的。
解决办法是消费幂等：
- 评论ID的唯一索引。我们在分表后的每张表里都对
comment_id建了唯一索引。INSERT时如果碰到重复ID，直接报主键冲突，catch住这个异常忽略即可，数据不会重复插入。 - 计数更新的幂等：用Redis的
SADD记录已经处理过的comment_id，如果SET里已经有了，说明处理过了，跳过计数逻辑。 - 落库后再提交offset：确保只有MySQL写入成功才提交offset，避免“没写库但offset已经提交”导致的数据丢失。
这三层组合下来，消息重复的概率几乎降到了零。即使偶发异常，也有主键冲突挡住最坏情况。
5. 高并发读取链路：缓存架构与热点防护
5.1 三级缓存设计：本地缓存 → Redis → MySQL
读取链路是整个系统里最考验设计能力的部分。评论区有个特点：读流量高度集中在少量热点内容上。一个视频火了，它底下的评论被疯狂读取；一个热评被顶到前面，它的楼中楼被疯狂展开。这种情况下，如果所有读请求都穿透到MySQL，数据库必然被打爆。
我们用了三级缓存：
- 第一级：JVM本地缓存（Caffeine），每个读服务实例维护。缓存时间极短，一般15秒到30秒。用于挡住最猛的那一波瞬时流量，因为热点视频的流量高峰往往只持续几秒到几十秒。
- 第二级：Redis分布式缓存，保存热评列表、楼中楼列表和评论详情。缓存时间适中，5分钟到10分钟。
- 第三级：MySQL，缓存不命中才查到数据库。
读取路径是：先查本地缓存，没命中再查Redis，还没命中再查MySQL，查到后回填两级缓存。这个路径上需要特别注意“缓存击穿”问题——如果热点key刚好过期，而这时候大量请求同时穿透，会瞬间把压力打到MySQL上。后面第6章我会专门讲这个问题。
5.2 热评列表的缓存结构
对于“某个视频下的根评论列表”，我们给每个视频缓存了前100条热评，用Redis ZSET存储：
code复制Key: hot_comment_list:{target_id}
Value: ZSET，member是comment_id，score是热度分数
TTL: 10分钟（每次访问续期）
当评论写入消费者处理时，新评论的comment_id会以初始分数加入这个ZSET。当有人点赞时，通过 ZINCRBY 给对应member加分。这样前100条热评永远是最新的热度排序。
查询时，直接 ZREVRANGE hot_comment_list:{target_id} 0 19 WITHSCORES 拿到前20条热评ID，然后批量查评论详情（先从本地缓存查、再从Redis查、MySQL兜底），最后用用户服务和点赞服务的接口把头像、昵称、是否已赞补全。
这里要注意一个细节：分页查询第2页、第3页时，不要继续从ZSET取。ZSET只缓存前100条，超过100条的部分直接走MySQL。因为第21页的热评，热度本来就低，访问量也低，不需要走缓存，节省Redis内存。用“冷热分离”的思路：热数据放缓存、冷数据落库，永远不给缓存堆垃圾。
5.3 楼中楼列表的缓存与分页策略
楼中楼比根评论列表更复杂，因为它是嵌套结构。我们采用的方案是：
- 每条根评论，在Redis里维护一个List，存它的楼中楼comment_id，按时间正序排列。
- 默认只缓存前50条（List结构），超过50条的楼中楼回复走MySQL查
root_id = ?。 - 展开楼中楼时，默认展示前3条，用户点击“查看全部回复”时才加载全部。
这个“默认展示前3条”的策略是产品层面强需求。打开抖音，一个热评下面你能看到“等X条回复”，但只展开显示最高赞的几条。对于产品来说，99%的用户只看前3条；对于技术来说，这意味着99%的楼中楼读取流量只需要命中前50条缓存就够了，后端压力骤减。
5.4 评论详情批量查询与空值缓存
评论列表接口返回的不只是commend_id，还需要把每一条评论的详情组装起来。如果逐条去查MySQL，N条评论就是N次查询。我们采用“批量查询 + 批量回填”的方式：
code复制1）从缓存/MySQL批量查到评论记录列表
2）用 comment_id 批量查点赞状态（Redis的SISMEMBER批量版）
3）用 user_id 批量查用户详情（走用户服务批量接口）
4）组装返回
这里的批量都走管道（pipeline）或批量接口实现，单次RPC就能拿回所有数据，把RT降下来。
另外，缓存中有一个特别容易踩的坑：对不存在的评论，也要缓存空值。如果没有空值缓存，攻击者或者异常调用，反复请求不存在的comment_id，每次都会穿透到MySQL，造成“缓存穿透”。我们的做法是：如果查DB发现comment_id不存在，就在Redis里写一个空标记，TTL设为60秒，避免恶意流量把DB打崩。
5.5 本地缓存为什么能大幅提升读取性能
我用一个实际压测数据来说明本地缓存的价值。线上配置了8台8核16G的评论读服务，在Redis稳定运行的前提下：
- 如果只走Redis读取，单机QPS大概在3000左右，P99延迟约30ms。
- 加上Caffeine本地缓存后，热点视频的读请求命中率达到85%以上，单机QPS提升到8000+，P99延迟降到15ms以内。
为什么差距这么大？因为走Redis还要经过一次网络RPC，即使Redis本身延迟只有1ms，加上网络开销、线程调度、序列化，整体P99会高不少。而本地缓存直接从进程内存里取，几乎没有网络开销。
本地缓存需要特别关注一致性问题。因为每个实例的本地缓存是独立的，A实例更新了缓存，B实例的缓存还是旧的。我们的取舍是：对强一致要求高的数据（比如用户刚发布的评论），本地缓存不缓存或缓存时间极短；对一致性要求没那么高的数据（比如热评排序），可以放心缓存10到30秒。评论列表允许30秒内的延迟可见，对用户影响不大。
6. 写链路与读链路的一致性保障方案
6.1 用户发评论后为什么能秒回
用户提交评论时，写服务只是把消息丢进Kafka就返回了。这时候MySQL里还没有这条评论，Redis里也没有。那用户刷新列表时，为什么能看到自己的评论？
答案是：在前端本地做了一次“乐观展示”。用户提交评论后，前端先生成一个临时评论对象，用本地时间初始一个ID，插入到评论列表的最前面，同时发起接口请求。接口返回成功后，再用真正的comment_id替换临时ID。如果接口失败，前端回滚删除这条临时评论。
这套交互逻辑是头条系产品的标准做法，用户体验极好。后端配合它，只需要保证：评论在Kafka消费落库后，能尽快出现在读取缓存中。正常情况，这个时间窗口在500ms以内，用户基本感知不到。
6.2 最终一致性：从写入到可见的完整路径
数据从写入到各端可见，存在一条明确的路径：
- 写服务收到请求，发Kafka，返回成功。
- Kafka消费者拉取消息，写入MySQL，执行INSERT。
- 消费者更新计数和热评ZSET缓存。
- 本地缓存和Redis缓存中的评论列表，因为TTL过期，或者被主动失效，重新从MySQL加载并回填，这时新评论就出现在列表里了。
这条链路里没有分布式事务，用的是“最终一致性”——从用户提交到数据全链路可见，正常情况约1秒，最慢不超过10秒（本地缓存过期时间）。对于评论场景，这个一致性级别完全够用。如果你强行引入分布式事务追求强一致，不仅性能扛不住，架构复杂度也是灾难，这是没有必要的。
6.3 缓存失效策略：先更新DB还是先删缓存
评论的点赞数更新、回复数更新，都会涉及缓存与数据库的一致性。经典问题是：先更新DB，再删缓存；还是先删缓存，再更新DB？
我们采用的方案是：先更新DB，再异步删除或更新缓存。原因是：先更新DB能保证持久层数据一定正确，缓存即使暂时不一致，后续通过删缓存或TTL过期也能恢复“最终一致”。而反过来先删缓存、再更新DB，在更新DB期间一旦有读请求命中旧缓存回填，就会把旧数据写回缓存，导致缓存长期不一致。
具体操作上，点赞服务流程是这样的：
- 调用MySQL执行
UPDATE comment SET like_count = like_count + 1 WHERE comment_id = ? - 更新成功后，异步删掉Redis里的评论详情缓存
- 同时用
ZINCRBY给热评分数加1 - 下次查询时缓存未命中，从MySQL查最新数据回填
这套流程有一个兜底：即使异步删缓存失败，Redis里的评论详情缓存TTL是10分钟，10分钟后也会自动过期重新加载。所以最坏情况是10分钟内的点赞数显示延迟，不会造成长期脏数据。
6.4 计数服务的独立设计
评论数、回复数、点赞数这三个数值，看起来简单，高并发下却很容易成为瓶颈。因为它们是高频修改、高频读取的字段，放在MySQL里每一次自增都要锁行，实测在并发过万时，行锁竞争会严重拖慢写入。
我们的方案是：
- 写入侧：计数不直接UPDATE MySQL，而是先更新Redis，比如
INCR comment_count:{target_id}。 - Redis定期快照：每30分钟，把Redis中的计数值异步批量刷到MySQL，覆盖更新。
- 读取侧：优先读Redis，Redis没有再从MySQL加载。
这套方案有个需要接受的现实：极端情况下（比如Redis持久化失败），计数可能丢失最多30分钟内的一部分增量。但评论计数本身就是软指标，对展示影响微乎其微。如果你对计数准确性有更高要求，可以通过“启动时从MySQL加载初始值 + Redis增量保存 + 周期性全量校准”来弥补。
7. 高并发核心机制：限流、降级、热点防护
7.1 限流策略：全局限流 + 单用户频控 + 单目标限流
高并发系统必须有限流，否则流量洪峰能直接打崩整个集群。评论场景下，我们做了三层限流：
- 全局限流：基于网关层做全站QPS限流，防止单接口把整个后端拖垮。评论服务单独设置一个配额，比如单机500 QPS，超过部分直接返回“系统繁忙，请稍后再试”。
- 单用户频控：每个用户每秒最多发1条评论，每分钟最多5条，每天最多50条。基于Redis计数器实现，key是
user_freq:{user_id}，用固定窗口或滑动窗口算法计数。这条主要防灌水机器人。 - 单目标限流：针对某个视频ID的评论频率做限制。如果一个视频的评论在一个小时内超过了合理阈值（比如10万条），触发保护，多余评论直接进入审核队列，不实时展示。
这三层限流组合，既保证了正常用户的体验，又能在恶意流量涌入时保住系统的命。限流最怕的是“一刀切”——把所有用户都限了。所以我们的策略是，三级限流按顺序放开，单目标限流优先级最低，只有真出现异常热点时才触发。
7.2 热点Key防护：本地缓存如何扛住瞬时峰值
热点视频的评论是典型的“热点Key”。一个几百万粉丝的大V发了一条视频，瞬间几十万人涌入评论区，如果全部打到一个Redis key上，Redis单线程处理压力会非常大，极端情况下会拖慢Redis上所有其他业务。
应对热点Key的方案，我们做了三层：
- 本地缓存前置：每个读服务实例的Caffeine本地缓存能吸收至少85%的读请求，让它根本到不了Redis层。
- 热点Key探测：在Redis客户端层做统计，如果发现某个key的访问频率超过阈值（比如每秒1000次），就把这个key的缓存时长临时拉长，同时把数据复制到几个备用key（比如key_1、key_2），查询时随机读其中的一个，分散单key的压力。
- 数据预加载：运营后台可以针对“预期会成为爆款”的视频提前触发缓存预热，把评论列表提前加载到Redis里。
7.3 热点评论的缓存击穿防护
“缓存击穿”是指：某个热点key的缓存在同一时刻过期，导致大量请求同时打到MySQL。这个场景在评论系统里很常见，比如热评ZSET的TTL是10分钟，到期后如果正好有流量高峰，所有请求都穿透到DB，DB瞬间爆掉。
防护方案是加锁回填，也就是业界常说的“互斥锁重建缓存”：
code复制获取缓存
→ 命中：直接返回
→ 未命中：
→ 获取分布式锁（SETNX lock_key）
→ 获取成功：查MySQL，回填Redis，释放锁
→ 获取失败：线程先sleep 50ms，再尝试从Redis读缓存（此时其他线程可能已经回填完成）
这个方法的核心思想是：同一时刻只有一个线程去查DB回填缓存，其他线程等待并复用最新缓存。用SLEEP+自旋读的“乐观等待”方式，比直接抛异常或返回空数据体验好得多。
7.4 热点评论的缓存穿透防护
“缓存穿透”是指查询一个不存在的key，每次都会打到DB。比如攻击者手工构造大量不存在的comment_id去请求评论详情，Redis每次都查不到，DB被白白打爆。
防护手段，我前面提过：空值缓存。具体做法是：
- 查询Redis，如果key不存在，继续查MySQL。
- MySQL也查不到，往Redis写一个特殊约定值的空缓存，TTL设为30到60秒。
- 后续相同参数的请求直接命中空缓存，返回“评论不存在”。
空值缓存还有一层隔离设计：不与真实数据缓存共用前缀。真实缓存key是comment:detail:{comment_id}，空值缓存key是comment:null:{comment_id}，避免读侧逻辑把空值误判为真实数据。布隆过滤器也值得一说。我们在查询评论详情前，会先检查布隆过滤器，如果里面没有这个ID，直接返回不存在，查询都不需要发起。布隆过滤器初始化时加载全量comment_id，虽然会有极低概率误判，但对“不存在的评论”这种场景使用是足够的。
8. 常见问题与排查技巧实录
8.1 问题一：Kafka消费积压，评论延迟涨到分钟级
某次大促期间，我们监测到用户发评论后，过了很久才出现在列表里。排查发现Kafka的comment_write Topic消费积压了几十万条，消费者组Lag从几百涨到了几十万。
排查过程：
- 看消费者监控，发现消费者所在的机器CPU有波动，但不算高；消费者线程池的活跃线程数正常。
- 深入看消费者日志，发现大量“Batch INSERT timeout”异常——批量写入MySQL超时。
- 进一步查MySQL，发现
comment_01表所在的一个分片主库的慢查询特别多，大都是全表扫描的查询。再仔细一看，有一个后台统计任务在跑SELECT COUNT(*) FROM comment_01 WHERE create_time > ...，把主库IO打满了。
解决方案：
- 立刻杀掉后台统计任务，写入恢复。
- 给评论区加读写分离，统计类查询走从库。
- 在Kafka消费者侧加上动态扩分区：临时将消费者实例从4个扩到8个，快速把积压消费掉。
复盘结论：Kafka消费积压90%不是Kafka的问题，是下游DB或依赖服务变慢了。排查时优先检查下游组件是否健康，而不是盲目调消费者线程数。
8.2 问题二：热点视频的缓存击穿把DB打崩
视频平台经常会出现“突发热点”，某个视频在半小时内评论量暴涨。第一次遇到时，我们没有准备，视频的热评ZSET刚好过期，在下一波请求高峰穿透到MySQL，数据库连接池被打满，导致评论服务整体不可用。
当时的处理：
- 临时把热点视频的缓存TTL从10分钟调到2小时，通过运营后台配置。
- 开启锁回填机制，确保同一时刻只有一个请求在重建缓存。
- 重启评论读服务，清空本地缓存，重新预热。
事后我们做了两件事固化方案：
- 在Redis客户端层实现了热点Key自动探测，访问频率超过阈值时自动延长TTL。
- 给所有热点缓存重建路径加了互斥锁，统一封装成工具类，从代码层面杜绝击穿。
8.3 问题三：数据库连接池被打满
一次压测时发现，4台评论读服务的连接池全部打满，MySQL的max_connections阈值被顶到上限，大量SQL排队等待。
排查下来，发现两个问题：
- 评论详情接口在批量查询时，如果本地缓存没命中，会逐条去查Redis，再逐条查MySQL。虽然做了批量优化，但有一个历史接口没改，仍在循环调用单条查询。
- 空值缓存没生效，大量不存在的评论ID穿透到了DB。
修复思路：
- 把所有评论详情查询都改成批量接口，单次RPC拿到所有数据。
- 修复空值缓存的坑，加上布隆过滤器前置。
- 给MySQL配置一个连接池告警，当连接使用率超过80%时自动告警，避免被动发现。
8.4 问题四：内网跨机房时延导致P99飙升
有一次机房迁移，评论读服务部署在A机房，Redis和MySQL还在B机房，跨机房调用延迟一次RPC就多出3到5ms。对于单次接口调用来说无所谓，但我们评论列表接口要批量查评论详情、批量查用户信息，整体多出了20到30ms的额外耗时，P99直接翻倍。
后来把全部评论相关组件搬到同一个机房，跨机房调用延迟降下来，P99回到正常水平。这个问题的经验是：高并发系统的性能优化，网络拓扑的影响往往比代码优化更大。在设计阶段就要把评论读服务、Redis、MySQL尽量部署在同一网络可用区内，降低调用延迟。
8.5 常见问题速查表
| 问题现象 | 可能原因 | 排查手段 | 解决方案 |
|---|---|---|---|
| 评论发出后不可见 | Kafka消费积压 | 看消费者Lag | 扩消费者实例/查下游DB瓶颈 |
| 评论列表接口超时 | 热点Key缓存失效 | 看Redis命中率 | 锁回填+热点探测+本地缓存 |
| 点赞数不更新 | 缓存与实际不一致 | 对比Redis与DB值 | 修复删缓存失败路径+TTL兜底 |
| DB连接池打满 | 缓存穿透/慢SQL | 看慢查询日志 | 空值缓存+布隆过滤器+批量查询 |
| 楼中楼楼层乱序 | 分页并发插入 | 检查消息时序 | 按root_id key路由到同一分区 |
| 用户频繁发送评论 | 频控失效 | 看Redis频控key | 完善频控策略+网关层限流 |
8.6 避坑经验：本地缓存更新不及时引发的“幽灵评论”
还有一个印象很深的坑。当时我们给评论列表做了本地缓存，但有用户反馈“我删了评论，刷新几次又出现了”。
排查后发现：用户删除评论时，写服务只删了MySQL的数据，同时发了Kafka消息让读服务删Redis缓存，但本地Caffeine缓存没有被主动清除，还在服务本地缓存了最多30秒。用户刷新时请求打到有旧本地缓存的实例，就看到了“幽灵评论”。
解决方案：
- 删除评论的时候，除了清Redis，还要通过Redis Pub/Sub广播一个“本地缓存失效”事件，让所有实例监听到后清掉本地缓存。
- 同时，在评论详情的本地缓存中增加一个校验位：如果评论状态是已删除，就不做本地缓存或缓存极短。
- 本地缓存TTL从30秒降到15秒，降低不一致窗口。
这个踩坑经历提醒我：任何一级缓存都有可能成为数据不一致的源头，本地缓存虽然性能好，但一致性管理的复杂度反而更高，设计时必须把“主动失效链路”考虑进去。
8.7 经验沉淀：从“能扛住”到“优雅地扛住”
做完这个系统，我个人最深的体会是，高并发评论系统最难的不是某一个单点技术，而是整条链路的节奏感。Kafka负责削峰，Redis负责挡读流量，MySQL负责最终落地，本地缓存负责挡最后那一层瞬时冲击。每层都有自己的位置和职责，协同起来才能形成一个完整的防护体系。
另外，做这类系统，监控和告警必须比功能上线更早。我们当时靠一套简单的Grafana看板，把Kafka的Lag、Redis命中率、MySQL慢查询数、接口P99全部统一展示在一张页面上。没有这套监控，第8章里那些问题每一个都可能需要半天才能定位。给所有读服务埋好Metrics，给所有关键路径打上Trace，这件事不能省。
如果你正在设计自己的高并发系统，我的建议是：先把数据模型定好，把root_id和分表策略想清楚，这决定了你的天花板；再把Kafka的生产者和消费者参数吃透，这决定了你能否平稳应对峰值；最后把缓存的分级和失效机制做扎实，这决定了你的实际体验。按这个顺序来，不说一遍成功，但至少不会走太多弯路。