评论系统设计#

数据模型： id / parent_id / root_id / content / user_id / create_time

存储： MySQL(持久化) + Redis(热评缓存/计数)

查询： 一级评论分页 + 子评论按 root_id 查询 + 游标分页

评论系统的数据模型我设计了三个关键字段：id 是评论自身的主键，parent_id 表示我回复的是哪条评论，root_id 表示我属于哪条一级评论的子树。查询策略分两步：先按 parent_id=0 分页查出一级评论列表，再按 root_id 批量查出每条一级评论下的子评论，避免递归查询导致的性能问题。分页方面用游标分页，也就是 WHERE id > lastId LIMIT N，替代 offset 方式避免深分页。存储层用 MySQL 做持久化，Redis 缓存热门评论和评论计数。敏感词过滤用 DFA 或 AC 自动机在写入时实时检测。排序方面，热门评论可以按点赞数+时间加权排序，缓存在 Redis Sorted Set 里。整体来说评论系统看着简单，但高并发下树形结构的查询优化、敏感词过滤、热评排序这几个点做好还是有挑战的。

追问方向：

• “树形结构怎么优化？”→ 不用递归查询，用 root_id 一次性查出一级评论下所有子评论，在应用层组装树结构；或者只展示两级（一级评论+直接回复），深层回复用 @用户名 平铺展示，像微博/B 站那样
• “敏感词怎么过滤？”→ 用 DFA（确定有限状态自动机）或 AC 自动机（Aho-Corasick）构建敏感词树，写入时实时匹配，O(n) 时间复杂度扫描文本；词库定期从配置中心更新，支持热加载
• “热门评论怎么排序？”→ 综合权重公式：score = 点赞数 x 权重 + 回复数 x 权重 - 时间衰减因子；计算结果存 Redis ZSet，定时更新；前 N 条热评缓存起来，新评论产生后异步重新计算

易错点：

• ❌ 评论直接递归查询——深层嵌套性能极差
• ❌ 评论系统简单——高并发+树形+敏感词+排序很有挑战