新闻App评论后端架构演进：从单表到智能审核的高并发实战

做了这么多年新闻App的后端，评论区是我觉得最“有温度”也最“有杀气”的一块系统。说它有温度，是因为用户最真实的声音都沉淀在这里；说有杀气，是因为每次热点新闻一爆，评论流量的尖峰能在几秒钟之内把服务打到崩溃边缘。新闻App评论后端体系的进化，本质上就是跟这种“不可预测流量”反复较量的过程。今天想把这条体系从最初的一张表打天下，到现在的服务化架构，再到正在摸索的智能演进，用“昨天、今天、明天”三个视角完整梳理一遍，给正在做内容平台后端、或者准备从零搭评论系统的同学一份可以直接参考的实战记录。

这篇文章不画概念图，也不堆PPT架构。我会把每一步的技术选型、踩坑过程、参数取舍都摆出来，尽量还原一个真实评论后端从野蛮生长到体系化的全过程。

1. 昨天：从一张表打天下到第一次拆家

1.1 最原始的评论系统长什么样

早期的新闻App评论系统，说直白点就是一张表。我当时接手的时候，核心表结构大概是这样的：

CREATE TABLE `comment` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `news_id` bigint(20) NOT NULL, `user_id` bigint(20) NOT NULL, `parent_id` bigint(20) DEFAULT '0', `content` text, `status` tinyint(4) DEFAULT '0', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_news_time` (`news_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

当时所有的评论逻辑都耦合在一个单体应用里，读和写混在一起。用户发评论就是Insert一条记录，拉评论列表就是一个Order By create_time Desc Limit 20的查询。这套东西在最开始确实能跑，因为新闻App的日活没起来，评论量撑死一天几万条，MySQL单库单表毫无压力。

那时候团队对评论系统的认知也很简单：这不就是一个CRUD吗。真正出问题是在一次突发社会新闻之后，那条新闻一小时内涌入了上万条评论，数据库连接数直接被打满，慢查询堆积，整个App的接口都跟着雪崩。那次事故之后，我们才意识到评论系统不是CRUD，它是一个读多写少、峰值流量极端、数据增长极快的典型场景。

1.2 流量冲击下的三次被动升级

第一次升级是引入Redis做缓存。当时没有什么复杂的设计，就是查列表之前先查Redis，把新闻ID的评论列表按时间顺序缓存成List结构，每次有新评论就LPush进去，列表上限保留1000条。这个方案在普通新闻场景下效果很明显，线上数据库的读压力瞬间降了一个量级。

但很快我们踩了一个经典坑：缓存穿透。有人专门挑一些不存在评论的冷门新闻ID来刷接口，Redis查不到，MySQL也查不到，然后请求直接打到数据库。更麻烦的是热点新闻的缓存击穿，某条新闻突然爆火，评论列表的缓存刚好过期，一瞬间所有用户都在查同一个Key，数据库直接被击穿。

第二次升级是分库分表。评论表按news_id哈希分成了32个库、每个库64张表，分布式ID用雪花算法生成。这次改造解决的是存储容量和单表写入瓶颈，但引入了新的麻烦：跨表分页、按用户查询、按时间聚合都变得很痛苦。

第三次升级是引入消息队列削峰。评论写入不再直接操作数据库，而是先发到MQ，由消费端异步批量落库。当时团队用的是Kafka，写入峰值被有效打平，数据库不再被瞬时流量打死。代价是用户发完评论之后不能立刻在列表里看到，需要等待几百毫秒到几秒的最终一致窗口。后来为了优化这个体验，我们做了“本地即时回显 + 服务端异步确认”的方案：用户的评论先渲染在客户端，服务端落库后再通过推送或者刷新来确认。

这一套走下来，系统算是“能撑住”了。但坦白讲，这段历史留下的技术债非常重：缓存和数据库的一致性靠定时任务扫，分页逻辑因为分库分表变得异常啰嗦，审核逻辑塞在主链路里，一次误判就会导致接口超时。

2. 今天：评论中台的架构棋局

2.1 按职责拆服务：评论不是单点，而是一条链

“昨天”给的最大教训就是：评论系统不能是一个大而全的单体服务，它天生是一条链路。现在的评论后端体系，我一般会拆成下面几个独立部署的服务：

• 评论网关服务：负责鉴权、限流、参数校验，把客户端请求转发到下游。
• 评论写服务：处理发布、删除、举报等写操作，核心逻辑是校验和削峰。
• 评论读服务：处理列表、详情、楼中楼展开等读操作，跟写服务完全隔离，独立扩容。
• 审核服务：接收评论内容做文本、图片的机审和人工抽检。
• 互动服务：管理点赞、点踩、热度值等辅助数据。
• 索引同步服务：把评论数据从MySQL同步到ES，支撑后台管理和个性化查询。

这个拆分看着简单，但有一个关键点：读服务和写服务必须彻底隔离。新闻App的流量特征非常明显，一条爆款新闻可以让读QPS瞬间冲到几万，但写QPS可能也就几百，如果读写混在一起，读流量会把写服务拖垮，导致用户连评论都发不出去。

另外一个容易忽略的点是：审核不能塞在评论写服务的主线程里。我见过很多团队把文本过滤直接写在发布接口里，结果一个正则匹配或者一次第三方审核调用超时，整个发布接口就挂了。正确做法是评论先落库标记为“待审核”状态，然后丢进MQ异步处理，审核通过后再把状态改为“已发布”，同时更新可见缓存。

2.2 读写分离的两条核心链路

当前业内比较成熟的评论中台，核心就是两条链路：

写链路的设计大概是这样的：

客户端 -> API网关 -> 评论写服务 -> 写入comment表(status=0) -> 发送MQ消息 -> 返回“发布成功，待审核” 审核服务消费MQ -> 机审 + 人审 -> 更新status=1 -> 更新Redis缓存 -> 清理本地缓存

读链路则是：

客户端 -> API网关 -> 评论读服务 -> 本地进程缓存(Caffeine) -> Redis缓存 -> MySQL兜底

初看读链路很简单，但细节全在缓存策略里。我们的本地缓存设置是每个节点最多缓存最近访问的200个热门新闻的评论列表，过期时间60秒。Redis缓存则存全量的热门评论列表和分页游标信息，过期时间5到15分钟，并加上随机抖动防止雪崩。

为什么需要本地缓存？因为在极端热点下，Redis本身也会成为瓶颈。一条千万级阅读量的新闻，评论区可能同时有几十万人刷，就算Redis能扛住几万QPS，网络开销和连接数也会变得很难看。加了本地缓存之后，同一个App实例上的用户可以共享一份内存缓存，网关层再做一层一致性哈希，让同一新闻的请求尽量落到同一组实例上，这个本地缓存的命中率能做得非常高。

写链路里最容易被忽视的是消息顺序问题。用户对同一条评论的多次操作（比如先发一条、再删掉）如果被不同消费者处理，可能会出现删除先于插入执行的极端情况。我们的做法是给每条评论一个业务侧的event_id，在消费端做去重和顺序保证，消息幂等性必须从一开始就设计好。

2.3 新闻场景的性能天花板与容量视角

新闻App的评论后端跟电商评论、社区评论最大的不同，就是流量的突发性和高度聚集性。某条新闻在未被审核通过前可能只有几百人看，一旦过了审核并推送，瞬间涌入几十万人。这就导致评论服务要面向“尖峰”设计，而不是面向“均值”设计。

我常用的容量估算公式很简单：

并发评论读QPS预估 = 日活 × 人均刷新评论次数 / 用户活跃秒数 × 热点系数 写QPS预估 = 并发读QPS / 读写比

举个例子：日活1000万，人均每天刷评论20次，用户活跃时段集中在4小时，那平均读QPS大概是1000万×20/(4×3600)≈13888。但这只是平均值，热点新闻出现时这个数字要乘上3到5倍，也就是说读能力至少要奔着5万QPS去设计。而写QPS按读写比100比1算，就是500，这个量级对数据库来说完全不是问题。

重点在缓存层。但我们经历过一次比较惨痛的事故：某条全球性突发新闻的评论数据，Redis里的热key负载已经到单分片极限，本地缓存因为上线完导致命中率不高，读服务一直回源到Redis，Redis的CPU被打到90%以上。当时紧急做了一次动态热key识别，把前N个热key在每个实例的本地缓存里再冗余一份，并且在网关层做了限流，才算把服务稳住。

这里有个经验总结：新闻评论的热key不是固定的，它会随着新闻热度的变化而快速转移，所以静态的缓存策略不能解决问题，必须要有一个实时计算热key的组件，把Redis中的访问频次实时反馈到缓存策略里。

3. 今天的基础设施：存储、缓存与核心算法细节

3.1 存储选型：MySQL、Redis和ES各守什么阵地

存储层是我见过争议最多的地方。有些团队一上来就说要用MongoDB或者Cassandra替代MySQL，但我们实测下来，评论数据本身就是一个强关系型数据模型：评论和新闻之间有外键关系，用户和评论之间有归属关系，楼层和回复之间有父子关系。MySQL在这个场景下依然是最稳的选择。

我们的分工是：

• MySQL：存储评论主数据，包括评论ID、新闻ID、用户ID、内容、状态、时间等。核心表拆成comment_base和comment_content两张，base存索引字段和计数，content存大字段文本，减少宽表带来的IO放大。
• Redis：存热门的评论列表、评论计数、用户最近评论记录、点赞状态。Value用紧凑的二进制结构或者JSON，根据场景来选。
• Elasticsearch：存全量评论数据的索引，主要服务两类查询：用户在个人中心查“我发过的评论”，以及运营后台做内容检索和批量处理。

这里特别要说一个索引设计细节：如果直接用Elasticsearch做评论列表的主存储，在数据量大之后会有明显的延迟，而且很难支撑高度一致的读写。所以我们选择用MySQL当权威数据源，通过binlog同步到ES，ES的最终一致性完全够用。

3.2 缓存一致性：业务容忍度决定了方案

评论系统的缓存一致性不能套用电商库存那种强一致方案。用户对评论的容忍度是：自己发出去的评论要立刻看到，别人是否立刻看到同一秒钟的评论，其实没那么敏感。

我们的具体做法是Cache Aside模式加延迟双删。写入流程是：

1. 先更新MySQL中的评论状态。
2. 删除Redis中的对应缓存。
3. 延迟几百毫秒后再次删除Redis中的对应缓存。

这个延迟双删主要解决并发读请求把旧数据回填到缓存的问题。具体延迟时间我们设置为300到500毫秒，要小于我们业务上能接受的最终一致窗口。

另一个实操经验是：不要删整个新闻的评论列表缓存，而是把缓存细粒度化。比如按页缓存，或者按时间范围缓存，这样删缓存的影响面可以控制在用户实际感知的范围内，而不是每次有人发评论就把整条新闻的缓存清掉。

3.3 分页、热度与楼中楼：评论的三座山

第一个是分页问题。

很多人分页直接写Order By create_time Desc Limit 20。这种写法在offset小的时候没问题，一旦用户翻到几百页，offset很大，MySQL需要在索引里扫过前面所有记录再丢弃，性能会急剧下降。评论系统的正确解法是游标分页：客户端传last_create_time和last_id，服务端用索引条件定位到具体位置再取固定条数。

SELECT * FROM comment WHERE news_id = ? AND status = 1 AND (create_time < ? OR (create_time = ? AND id < ?)) ORDER BY create_time DESC, id DESC LIMIT 20;

游标分页在MySQL的联合索引(news_id, create_time, id)下，每个查询都走的是索引的精准定位，不会因为翻页深度而变慢。

第二个是热度排序问题。

纯按时间排序会让优质评论沉底，纯按点赞排序会被时间稀释。我们参考了Hacker News的评分算法，做了一些新闻场景的调整：

score = (点赞数 - 点踩数 + 基础分) / pow((当前时间 - 发布时间)/3600 + 2, 重力系数)

其中重力系数设置成1.5左右，这样新评论会有一定的曝光机会，但不太容易把高质量的热门评论挤下去。考虑到新闻的时效性非常强，我们还加了一个衰减时间窗口，发布超过48小时的评论进入“沉淀区”，不再参与热度榜竞争，按时间倒序直接展示。

第三个是楼中楼问题。

楼中楼是新闻评论区最复杂的交互。我们的存储方案是给每条评论增加一个path字段，用来记录从根评论到当前评论的路径，比如“1_23_45”。查询楼中楼时，直接在path字段上做前缀匹配：

SELECT * FROM comment WHERE parent_path LIKE '1_23_%' ORDER BY create_time ASC LIMIT 100;

这个方案牺牲了一点写入时的计算，但极大简化了查询逻辑。为了避免无限嵌套，我们限制最多展开两层，超过两层就默认把更深层的回复拍平到第二层。这个产品上的约束大大降低了后端的复杂度。

4. 明天：智能、实时、会自我迭代的评论体系

4.1 AI审核与人工审核的人机协作

评论区管理是目前投入人力最大的地方，纯靠关键词黑名单完全不够用。现在的敏感表达方式越来越隐蔽，谐音、拆字、图片化的文本，普通正则根本拦不住。我们正在尝试用大模型做语义审核：输入评论内容，模型输出风险分类、风险等级、嫌疑关键词片段，再结合概率阈值决定是直接拦截、进入人工审核还是放行。

这套体系的核心困难不是模型准确率，而是延迟和成本。评论发布链路要求在200毫秒内返回结果，大模型动辄几百毫秒的推理时间很难扛住。我们目前采用的方案是两阶段审核：先用轻量级模型（比如FastText或者BERT的小蒸馏版本）做第一层粗筛，大概能覆盖60%到70%的明显垃圾内容；剩下模糊地带的消息进入重型模型或人工审核队列。

这里有一个产品上的取舍：先审后发还是先发后审。新闻App我建议默认先审后发，因为新闻评论区一旦出现违规内容，传播速度和影响面都很恐怖。但为了兼顾用户实时互动的体验，可以给高信用分老用户开启先发后审的通道，系统实时监控其历史负面率，一旦超过阈值立刻降级。

4.2 实时互动与容量预测

“明天”的评论体系肯定不止于“发一条、刷一屏”。我比较看好的一个方向是实时互动：比如在新闻正文阅读到某个段落时，直接显示当前用户群体对该段落的即时评论流。这要求评论系统具备毫秒级的推送能力，WebSocket或者SSE通道会逐步替代传统的轮询。

另外一个重要的方向是容量预测。我们现在做的事情是：在新闻运营侧标注新闻类别（社会、娱乐、体育等）和预期热度等级，评论后端根据同类别历史数据，自动预测这条新闻可能带来的评论峰值，进而提前扩容缓存分片、动态预热可能的热点key。这要比等到流量真正打上来再去扩容稳得多。

4.3 数据驱动下的评论生态演进

评论数据是新闻App的一座富矿。我们在尝试用评论内容反向指导新闻推荐：分析评论区的情感倾向和争议度，来判断这条新闻是否适合推给更大的人群。争议度高的新闻天然有更高的评论转化率，但争议度过高又容易引战，所以这个阈值需要非常精细地调。

从用户侧看，个性化评论排序也会有明显效果。同一篇文章，有人喜欢看抖机灵的短评，有人喜欢看有深度的长评。基于用户的阅读历史和点赞行为，用一个简单的CTR预估模型给每条评论算一个个性化系数，然后叠加到热度分上，这个方向我们已经做了初步验证，整体评论互动率有提升。

智能审核、实时互动、个性化排序，最终会组成一个数据回路：用户在评论区的行为不断产生新数据，模型从数据中学习并调整自己的策略，策略反过来影响用户的评论体验。这比单纯堆机器、调SQL更像“明天”该有的样子。

5. 常见问题与排查技巧实录

5.1 五个高频事故与处置过程

第一个事故是热点新闻打崩Redis热key。当时典型的表现是Redis某个分片的CPU飙到100%，但其他分片很闲。排查时先用redis-cli的hotkeys参数扫描热key，确认是单个新闻ID的评论列表，然后紧急提升该key的本地缓存命中率，同时对该key的读请求做一致性哈希，确保尽量命中同一个实例。

第二个事故是缓存穿透导致数据库连接暴涨。当时表现是数据库慢查询数量持续高位，但Redis命中率却很高。排查后发现攻击者用不存在的新闻ID批量请求评论接口，每次都在缓存和DB中查不到。解决方式是布隆过滤器加空值缓存，空值也缓存5分钟，业务上可接受。

第三个事故是MySQL主从延迟导致用户评论“一会看得到一会看不到”。这通常发生在评论写服务刚写入主库，读服务却从从库读到旧数据的时候。我们的方案是增加一个“刚发布的评论”状态：如果请求带上了用户自身的user_id，则强制走主库；其他用户的列表走从库，延迟窗口控制在1秒内。

第四个事故是审核消息队列积压。某次机审服务依赖的第三方接口完全不可用，MQ里的消息积压了几百万条，导致评论全部卡在“待审核”状态，用户舆论直接爆炸。这次之后我们把审核服务做成双重降级：第三方接口超时后先走本地朴素规则，确保评论不会长时间不可见。

第五个事故是分页接口慢查询。原因是某个版本把游标分页改成了offset分页，用户翻到100页之后，MySQL扫描了大量无用行。这个属于代码审查不严导致的问题，教训是核心链路的SQL变更必须走性能评审。

5.2 评论系统排查工具箱与速查表

我整理了一张实战排查速查表，基本覆盖了评论后端最常见的线上问题：

排查看似零散，其实核心思路就一条：先看缓存命中率，再看MQ积压数，最后查DB慢查询。80%的评论系统问题都能在这三个环节里定位到根源。

做评论后端这些年，我最深的体会有两点：一是评论区是新闻App离用户最近的地方，技术上任何一点波动，都会直接反映到舆论场上，所以稳定性的优先级永远高于一切花哨的功能；二是评论系统没有一天建成的中台，它都是从一张表、一个缓存、一次事故里一步步长出来的。每踩一次坑，就把对应的防御机制焊死在系统里，这就是评论后端体系演进最真实的轨迹。