高性能评论盖楼系统架构设计：从数据模型到缓存策略的实战拆解

做评论系统做了好几轮，从最早单库单表撑几千条评论的小社区，到后来峰值 QPS 几万、单条爆款内容能盖几万楼的内容平台，这个“评论盖楼”系统算是我踩坑最多、也收获最大的一套架构设计。这些年关于评论系统的架构方案网上讨论很多，但大多停在概念层面，真正把数据模型、树形结构组装、缓存策略、热点防护串起来讲的很少。这篇就把整套高性能评论盖楼系统的架构设计从头拆一遍，讲清楚每个环节为什么这么设计、怎么落地、以及那些常规文档里不会写的问题。不管你是刚接手评论模块的后端开发，还是准备从零搭建类似互动功能，这篇都能给你一份可以直接抄作业的参考。

1. 先搞清楚：评论盖楼系统到底难在哪

1.1 “盖楼”的业务形态，远比你想象的分叉多

先统一一下概念。所谓“盖楼”，指的是评论的嵌套回复结构——用户 A 评论了文章，用户 B 回复 A，用户 C 又回复 B，形成一条父子链；同时用户 D 直接评论文章，和 A 是兄弟节点。这种结构在业务上天然是一棵多叉树，而不是平铺的列表。

这里有个容易踩坑的点：不同产品对“盖楼”的定义差很多。朋友圈那种只有一级评论、回复只是把 @ 的人串在一行里的，属于“伪盖楼”，数据模型一个 parent_id 就能搞定。而知乎、微博超话这种无限嵌套的，才是真正意义上的树。我们当时做的是后者，用户可以在任意一层继续回复，界面要展示出完整的树形缩进关系。

业务形态直接决定数据模型。如果你在项目一开始没想清楚产品要“盖”到第几层，后面改起来极其痛苦——我从一层改到无限层的时候，重构了整整两周，还留了好几个历史数据的坑。所以做架构设计第一件事，不是选技术栈，而是跟产品确认清楚：是只支持两级，还是无限级？有没有楼层号的概念？要不要显示“第 X 楼”？

1.2 高性能评论系统的三个核心矛盾

把评论系统单拎出来做架构设计，是因为它有三个跟普通业务系统很不一样的特点。

第一个是“写多读多且写读比例失衡”。文章内容基本是写一次读万次，但评论是每时每刻都在产生新写入，同时老评论又在被大量读取。爆款内容发布后几小时内就可能涌入上万条评论，这期间写入压力一点不比读取压力小。

第二个是“热点极度集中”。一个平台每天产生的评论，绝大部分流量都打在最头部那几条内容上。比如一场直播、一条明星八卦、一个引发争议的公告，单条内容的评论 QPS 可能占到全站评论流量的 80% 以上。这种热点意味着缓存和存储的设计必须围绕“极少数超级热点”来做，而不是均匀地分散负载。

第三个是“树形结构天然难分页”。平铺列表分页很简单，LIMIT offset 就完事。但评论盖楼是要在分页的同时保持父子层级关系的完整性——你翻到第 3 页，看到的必须是一个完整的树（或者是若干棵完整子树），不能把树拦腰截断。这就让评论的分页方案跟普通列表完全不同。这三个矛盾叠加在一起，就决定了评论系统不能照着普通 CRUD 的思路做。

2. 架构整体设计：每一层都在解决具体问题

2.1 分层设计：接入层、应用层、存储层各司其职

我们的整体架构分成三层：接入层、应用层、存储层。

接入层主要做三件事：鉴权、限流、风控。评论是 UGC（用户生成内容），恶意刷评、灌水、人身攻击是常态，所以接入层必须前置校验。限流要区分场景——对普通用户限制评论频率（比如 10 秒内只能发一条），但对读接口要放宽，因为读多写少是常态，误伤正常浏览用户代价很高。

应用层是核心，负责评论的写入、查询、树形组装、计数、点赞等全部业务逻辑。这里要特别注意无状态设计，应用层节点不保存任何本地状态，所有共享状态全部放缓存和存储里，这样才能水平扩容。我们曾经栽过跟头：早期为了性能把热点帖的评论树缓存在应用节点本地内存里，结果流量一上来，不同节点缓存不一致，用户看到的楼层顺序都是乱的。

存储层我们用的是 MySQL + Redis 的组合，MySQL 负责最终数据落地，Redis 负责读加速和计数器。后面会详细说为什么这么选，以及踩过的那些存储相关的坑。

2.2 存储选型：MySQL 兜底，Redis 加速，选型逻辑讲清楚

存储选型是评论系统架构设计里争议最大的部分。我见过"MongoDB 一把梭"的，也见过"全量放 Redis"的。聊聊我最终选择 MySQL + Redis 组合的原因，以及各方案的适用场景。

先看下各方案对比：

评论数据有几个特点：单条记录小（几百字节）、总量大（上亿级）、强一致要求高（用户发出去就必须能查到）。MySQL 在这种场景下其实是被低估的——只要设计好表结构和索引，单表几千万条评论完全撑得住，配合归档和分表可以平滑扩展到上亿。关键是不要把 MySQL 当成万能存储，它的定位就是“可靠的数据底座”。

Redis 在评论系统里承担三个角色：热评论列表缓存、计数器（点赞数、回复数）、分布式锁。这三个角色都要求 Redis 必须高可用，我们用了一主多从 + 哨兵的模式，容量告警阈值设得很保守，因为 Redis 一旦 OOM 或主从切换，影响的是全站评论的读链路。

为什么不选 MongoDB？我们早期一个项目用过，写入确实快，但树形结构查询和分页支持都比较弱，遇到“查某条评论下的全部子评论并按楼层排序”这类需求，写起来非常别扭，最后又迁回了 MySQL。如果你团队对 Mongo 很熟、业务形态恰好是文档型的，也不是不能用，但评论盖楼这种强树形结构，关系型数据库的模型表达能力明显更合适。

2.3 写入路径设计：先写缓存还是先落库，我为什么选先落库

评论写入的路径设计，是评论系统里一个非常核心的权衡点。市面上有两派做法：先写 Redis 再异步落库（“缓存优先”），以及先写 MySQL 再更新缓存（“存储优先”）。

我最终选择的是“存储优先 + 异步化削峰”的组合方案：用户提交评论，请求先打到应用层，应用层做基础校验和风控，然后直接写 MySQL，MySQL 写入成功后再主动失效相关缓存（不是更新缓存），同时通过消息队列异步更新评论计数和楼层号等聚合数据。

为什么不用缓存优先？原因很实在：评论是强一致业务。用户发完评论如果在自己刷新时看到评论消失了，这个体验问题比性能问题严重得多。缓存优先方案虽然读性能好，但一旦缓存和数据库之间出现短暂不一致，用户就会感知到“评论发出去但列表里没有”或者“评论重复出现”。MySQL 单条写入的性能其实足够支撑常规情况——一条 INSERT 在普通 SSD 上也就 1ms 左右，极端热点的时候再通过应用层的分段限流和 MQ 削峰来兜底。

这里有个细节容易被忽略：写 MySQL 的时候，事务范围要尽量小。评论写入只需要保证单条 INSERT 成功，不需要也不应该把“更新评论数”“更新楼层号”这些操作放进同一个事务里——它们可以用消息队列异步去做。把事务拉长，等于把简单问题的性能上限锁死了。我们在压测时试过把计数更新放进同一事务，TPS 直接掉了 40%，后来拆成异步，写入链路立刻宽敞了。

3. 核心环节的落地实现：从表结构到树组装

3.1 评论表结构设计：楼层号、根评论、父评论一个都不能少

评论表设计是整个系统的地基，直接决定后面所有查询的性能。我用了多版设计后沉淀下来一套相对稳定的结构：

CREATE TABLE `comment` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '评论ID', `content_id` BIGINT UNSIGNED NOT NULL COMMENT '内容ID（文章/视频ID）', `root_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '根评论ID，0表示自己是根评论', `parent_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '父评论ID', `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID', `content` TEXT NOT NULL COMMENT '评论内容', `floor_no` INT UNSIGNED NOT NULL COMMENT '楼层号（内容维度全局递增）', `reply_count` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '直接子评论数', `like_count` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '点赞数', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0正常 1删除 2审核中', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY `idx_content_status_floor` (`content_id`, `status`, `floor_no`), KEY `idx_root_id` (`root_id`, `floor_no`), KEY `idx_parent_id` (`parent_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个关键设计点展开说说。

root_id是最重要的一列。它记录这条评论属于哪棵评论树，也就是属于哪个根评论。查询“某篇文章第 3 页的根评论 + 每个根评论下的完整子树”时，只需要一次范围查询拿到该页根评论的 id 集合，再用WHERE root_id IN (...)把子树一次性捞出来。如果没有root_id，只能用parent_id递归，那性能就是灾难。

floor_no楼层号我选择在内容维度全局递增，而不是树内递增。原因是产品上“X 楼”的展示是内容级别的，用户会说“第 100 楼炸了”，不会说“某个根评论的第 5 楼”。楼层号的生成用 Redis INCR 实现，key 是content_floor:{content_id}，这样避免了数据库自增在并发下的瓶颈，同时因为不放进事务，生成失败最多是楼层号缺号，业务上可接受。

reply_count存的是“直接子评论数”，不是整棵子树的评论数。这里要跟产品确认展示口径——如果你的产品在根评论旁边显示的是“共 xx 条回复”，那需要的是整棵子树的计数，那就得在回复发生时顺着root_id做整树计数更新，成本高很多。我们采用的是折中方案：列表页展示直接回复数，点进详情再实时统计完整子树，压测下来性能完全能接受。

关于软删除要特意提醒一句：评论系统的删除和普通业务不一样，不能物理 DELETE。因为盖楼结构里，一旦删掉父评论，它的所有子评论就悬空了。我们的做法是逻辑删除——把status置为 1，内容置为占位符（比如“该评论已删除”），但保留其在树中的位置。这样子树结构不会断，用户看到的楼层也不会跳号。

3.2 盖楼树组装：一条 SQL 查全量，内存里建树

评论盖楼最核心的性能瓶颈在树形结构的组装。最直观但也是最错的做法是：先查根评论列表，再对每条根评论递归查询子评论——这就是经典的“N+1 查询问题”，一个根评论一次数据库查询，第 3 页如果有 20 个根评论，就是 20 次额外查询，每条评论又有自己的子评论，整体查询次数轻松上百，接口响应时间直接爆掉。

我采用的方案是“一次性查全量 + 内存建树”。思路如下：

1. 根据分页参数，查出当前页的根评论 ID 集合（比如第 3 页的 20 个根评论）。
2. 用SELECT * FROM comment WHERE root_id IN (20个根评论ID) AND status >= 0 ORDER BY floor_no ASC一次性把这一页涉及的所有评论（根 + 子孙）全部查出来。
3. 在应用层用 HashMap 缓存这一批评论，遍历两次：第一次建立id -> Comment映射，第二次把每条评论挂到其parent_id对应的子列表下。
4. 从每个根评论出发，深度优先遍历输出树形结构。

这个方案对数据库的查询次数固定为 2 次（一次查根评论 ID，一次查全量子树），跟楼层有多深、子评论有多少完全无关。性能瓶颈只是单次查询返回的数据量——如果某个根评论的子树有几千条，一次查出来确实多，但分摊到单条评论的组装成本极低。代码逻辑大概是这样的伪代码：

// 1. 查询第3页根评论 List<Comment> roots = commentDao.selectRootsByPage(contentId, pageSize, offset); List<Long> rootIds = roots.stream().map(Comment::getId).toList(); // 2. 一次性查出这页根评论的所有子树评论 List<Comment> allComments = commentDao.selectByRootIds(rootIds); // 3. 内存建树 Map<Long, Comment> idMap = new HashMap<>(); allComments.forEach(c -> idMap.put(c.getId(), c)); List<Comment> treeList = new ArrayList<>(); allComments.forEach(c -> { if (c.getParentId() == 0) { treeList.add(c); } else { Comment parent = idMap.get(c.getParentId()); if (parent != null) parent.getChildren().add(c); } });

有几个细节要注意。idMap必须用HashMap而不是TreeMap，因为建树过程不要求有序，排序在数据库层用ORDER BY floor_no已经做掉了，应用层只要保持插入顺序即可。另外，如果存在“父评论被删导致父节点不在结果集”的情况，内存建树时会出现悬空节点，需要做一次兜底：查不到parent_id对应的父节点时，把这条评论挂到根评论下。我在线上真实遇到过这种情况——历史数据里残留的脏数据，查不到父节点直接丢掉了，用户那边就反馈“回复不见了”，加了这个兜底后才彻底解决。

3.3 分页方案：为什么说 LIMIT OFFSET 是评论系统的坑

普通列表的LIMIT offset, size分页，在评论这一场景下有两个致命问题。

第一个是深分页慢。MySQL 里LIMIT 100000, 20需要扫描 100020 行再丢弃前 100000 行，offset 越大越慢。爆款评论轻松几万楼，用户翻到 500 页是常态，到那时一次分页查询可能耗时几百毫秒。

第二个是数据不一致。LIMIT OFFSET 分页是“位置偏移”，如果在用户翻页期间有新评论插入，楼层顺序会错位，用户会看到评论重复或遗漏。

解决方案是用“游标分页”替代偏移分页。游标分页的核心是：不告诉数据库“给我第 500 页”，而是告诉它“从上次看到的最后一条评论继续往后取”。对于评论系统，天然可以用楼层号floor_no作为游标：

-- 第一页：取 content_id=123 的前20条根评论 SELECT * FROM comment WHERE content_id = 123 AND root_id = 0 AND status >= 0 ORDER BY floor_no ASC LIMIT 20; -- 第二页：拿到第一页最后一条的 floor_no = 567，然后 SELECT * FROM comment WHERE content_id = 123 AND root_id = 0 AND status >= 0 AND floor_no > 567 ORDER BY floor_no ASC LIMIT 20;

这种方案有两个显著优势：翻页深度不受影响，无论翻到几千页，查询都走(content_id, status, floor_no)这个联合索引，速度恒定；同时新插入的评论只会出现在游标之后，不会导致已翻过的页面错乱。

但要承认游标分页有一个产品层面的缺点：不支持“跳页”。用户没法直接点“第 500 页”，只能一页页往下翻。这在大多数评论场景是可以接受的——产品上本来也极少有人去跳页，更多是“倒序查看最新”“往下滚”。如果产品必须支持跳页，那就得接受深分页的性能代价，并用“前 N 页走游标、后续页走缓存列表”这种混合方案来做妥协。我们在设计时跟产品确认过，最终全站都用了游标分页，上线后翻页最深到 800 多页，接口耗时稳定在 30ms 以内。

3.4 缓存设计：什么该缓存，什么不该缓存，要分清楚

评论系统的缓存设计是读性能的胜负手。但缓存不是越多越好，我见过团队把整棵树序列化后放进 Redis，key 巨大、更新频繁、Redis 内存告警，最后被迫拆掉。我的原则是：缓存热点数据，而且是“按页缓存 + 版本控制”，不是缓存整棵树。

具体缓存策略是这样：

• 热评论列表缓存：key 设计为comment_page:{content_id}:{page_no}，value 是该页根评论 ID 列表（注意，只缓存根评论 ID，不缓存完整评论对象）。设置 2~5 分钟的过期时间，过期后回源数据库。为什么只缓存 ID？因为评论内容可能被用户删除或审核，缓存完整对象会导致删除后缓存里还能看到，一致性问题很难处理；只缓存 ID 列表，每次读取时再查一次 ID 对应的评论内容，虽然多一次查询，但一致性天然可控。

• 子树缓存：对于评论数特别多的热门根评论，缓存comment_subtree:{root_id}这棵树的 ID 列表。子树的组装成本最高，缓存收益最明显。

• 不缓存的内容：单个评论的详情和楼层号不单独缓存，让它们走 MySQL 主键查询，单条主键命中是极快的，没必要增加缓存管理和一致性成本。

• 计数器缓存：点赞数和回复数用 Redis Hash 或者直接 string 存，写入时用 INCR/DECR，定时异步刷新到 MySQL，展示时先读 Redis，读不到再回源。

缓存一致性的问题，我在第 4 节会单独展开讲。这里先强调一个容易被忽略的原则：写操作永远先动数据库，再主动失效缓存，而不是先更新缓存。原因很简单，数据库是数据的唯一真相源，缓存只是加速层，任何“双写”方案都会引入竞态条件——两个并发写请求，一个先写缓存一个后写缓存，最终缓存里可能是旧值。失效缓存则没有这个问题，最多是失效前有短暂的不一致窗口，被读到旧数据的概率和影响都可控。

4. 高并发场景的常见问题与排查实录

4.1 热点帖击穿缓存：一个明星八卦就够打崩评论服务的

评论系统的高并发风险主要不在平均流量，而在“超级热点”。一条内容突然爆了，几万人同时涌进来评论和刷新，如果这条内容的数据不在缓存里，请求就会全部打到数据库上——这就是缓存击穿。

我们第一次遇到这事是在一个晚上，某条内容突然冲上热搜，评论量从每分钟几十条瞬间涨到每分钟几千条，Redis 里没有对应的缓存，数据库连接被打满，评论接口超时率一度到了 35%。事后复盘，我们加了三个措施：

第一个是热点 key 永不过期 + 异步刷新。对于评论数超过阈值的超级热点内容，直接不给缓存设置过期时间，由一个后台任务定时（比如每 30 秒）检测内容的热度，热点内容主动刷新缓存，非热点再走正常过期逻辑。这样缓存永远不会在热点期间自然失效，也就没有击穿窗口。

第二个是本地布隆过滤器/互斥锁回源。当缓存 miss 时，用一个分布式锁（Redis SETNX）限制“回源查询数据库”的并发，只有一个请求能真正查库，其他请求短暂等待后重试缓存。这个方案能兜住极端瞬间的并发回源。

第三个是单 key 的查询限流。对同一个content_id的查询做 QPS 限制，超限后直接返回降级数据（比如只返回最近 100 条评论的简化列表），避免因为一条内容拖垮整个评论服务。后来我们把 Redis 的 key 做了拆分（按时间段分片存热评论），热点压力进一步分散，这个措施到现在一直没出过问题。

4.2 缓存一致性：删除缓存真的够用吗

缓存一致性的经典问题：更新数据库后，先删除缓存还是先更新缓存？偶尔有团队用“更新缓存”的方案，理由是省一次删除后的缓存重建。我明确建议：直接用删除（失效）缓存，不要更新缓存。

原因前面提过是竞态条件：两个并发请求同时写同一条评论相关的缓存，线程 A 写了新值，线程 B 又把旧值写回去，缓存就永久脏了。而删除缓存没有这个问题——删掉之后，下一次读取自然会去数据库拿最新数据重建。删除缓存唯一需要担心的是“删了但没人重建”，这就要配合读请求的 cache-aside 逻辑（读 miss 时主动回源加载）来兜底。

另一个容易忽略的坑是“更新数据库失败但缓存已删”。如果先删缓存再更新数据库，而数据库更新失败，缓存是空的，下一次请求回源拿到的是旧数据，重新写进缓存，又变成旧值了。所以我的执行顺序是：先更新数据库，成功后再删除缓存。万一删缓存失败，最多是短暂读到旧值，过几秒缓存过期后自然恢复。如果对一致性要求极高，可以把“删除缓存”放进消息队列，失败后重试，但这会增加系统复杂度，不是每个团队都值得做。我们当前的方案是“数据库更新成功后同步删缓存 + 定时任务兜底比对不一致数据”，实测下来线上基本没有出过缓存脏数据的事故。

4.3 评论计数的数据倾斜：一个热帖的计数更新拖垮全库

评论数、回复数、点赞数这些计数器，看着简单，实际上是评论系统最容易被低估的瓶颈。一个普通内容的计数器更新 QPS 可能就个位数，但一个超级热帖的点赞接口，QPS 能瞬间到几万。如果所有计数都走同一个 Redis key，这个 key 就成了单点热点——单个 Redis 实例上，一个 key 的 QPS 再高，也只能跑在一个 CPU 核心上，这就是“数据倾斜”。

我们的解法是把计数器做分片累加。对于超级热门的评论，把点赞数和回复数拆到多个 key 上，比如like_count:{comment_id}:{shard_id}，shard_id 按用户 ID 哈希取模分成 8~16 个分片，写入时随机选一个分片 INCR，读取时把所有分片 SUM 起来。代价是读取时从一次 GET 变成多次 GET，但换来的是写入能力的线性提升。这个方案在压测中效果非常明显：单 key 写入上限大概 5 万 QPS，分 16 片之后写入能力翻了十几倍，读聚合耗时增加不到 1ms。

计数器本身还有一个精度问题需要说清楚：Redis INCR 的计数和 MySQL 的真实计数可能不一致，因为异步落库可能失败或重复。我们接受的是“展示计数可能略有延迟，但最终一致性由 MySQL 兜底”的方案。每天晚上跑一次对账任务，把 Redis 计数和 MySQL 实际统计做比对，偏差大的自动修正。用户不会感知到这种秒级延迟，但架构上必须保证最终一致性是可靠的。

4.4 问题速查表：评论系统线上问题快速定位

最后把我在评论系统上线后遇到过的典型问题整理成一个速查表，方便大家遇到类似现象时快速定位：

这些问题的共性其实都是一个：评论系统本质上是“读多写多 + 树形复杂 + 热点集中”的三重困难叠加。任何一个环节用“通用方案”硬套，都会在后面某个数据量突然上来的时候爆雷。

我个人这套架构跑了两个完整的大促周期，最极端情况下单条内容同时在线评论数超过 12 万条，读写峰值 QPS 到了 7 万左右，评价接口 P99 耗时稳定在 90ms 以内，数据库没有因此出现过一次慢查询告警。踩过这么多坑之后最深的体会是：评论系统的架构设计，重心真的不在“用什么高端中间件”，而在于对数据模型和访问模式的理解——想清楚树怎么存、怎么查、怎么分页，比堆一堆中间件管用得多。如果你们正要动手做盖楼系统，建议先把业务形态和数据模型确认清楚，再照着这篇的链路一步步落地，能少走很多弯路。