评论系统中评论盖楼设计和性能优化方案

在主流的视频网站和社交网站中评论是非常重要的模块之一，因为评论模块不仅为用户提供真实、可靠的决策参考信息，而且也为商家或平台提供宝贵的用户参与数据，同时增强用户互动与社区粘性。所以一套功能完善、高性能和高可用性的评论系统对于用户量很大的网站来讲是非常重要的。

那么，在评论系统中的用户对于其他的用户的某条评论在继续无限制的追加评论该如何设计呢？下面我们聊聊其设计方案。

1、评论盖楼数据存储设计方案——添加parentId关联

在设计评论表的时候，在表中添加字段parentId字段，这个字段用于标识父级评论，如下图所示的评论表和表中存储的数据：

如上图所示，id=1的评论parentId=0，那么标识id=1的评论是父级评论，然后id=2的评论是id=1评论子评论，此时这个子评论的parentId设计成等于1，这样就将父级评论和子级评论关联起来了。

如果现在要查询一个评论下面的所有回复的子评论，此时查询的步骤是先查询父级下的子级评论，然后查询子级评论下的子级评论，如下图所示：

如果id=1的评论楼盖了1000层，那么，在规范的查询要求下，我们就要向数据库发1000次SQL查询请求，一旦系统的并发上来后，数据库连接池瞬间就会被这种递归查询占满，进而导致整个系统的崩溃。

2、评论盖楼数据存储设计方案——存储路径方案

既然使用parantId存储评论盖楼数据存在查询的问题，那么我们是换个思路，将评论盖楼使用一个字段标识出来，如图所示：

在表中path字段记录了当前的评论的父级评论是来自哪个评论，如id=3的评论，它的父级评论是id=2的评论，id=2的评论的父级评论是id=1的评论，这样的设计不仅层级清晰，而且查询也方便，如果要查询id=1的评论下所有的子级评论，一条sql就可以完成查询，如下所示：

虽然存储评论路径的方案方便查询，但是也存在一个比较致命的缺点，如果用于一旦删除了id=2的评论，那么id=2的评论下的子级评论都要重新维护，如下图所示：

如果是一个热门的帖子或者视频，那么在评论的数据量非常大的情况下，如果将含字段path中含有id=2的评论数据全部找出来并且更新掉，这就出现了严重写放大问题。

3、评论盖楼数据存储设计方案——冗余rootId的方案

反范式设计方式增加一个字段rootId（顶级楼层id），这也是现在主流网站中比较通用的一种设计方案，如下图所示：

一个父级的评论，然后父级评论下继续有子级评论，两个用户分别就某个子级评论做了回复，我们使用两行分别展示评论的数据，针对这种扁平化的评论盖楼系统的数据存储表的设计如下图所示：

id=1是父级评论，它的rootId = 0；

id=2是子级评论，它回复了id=1的评论，此时rootId = 1，用replyId=1表示它回复的是id=1的评论；

id=3是子级评论，它回复了id=2的评论，此时rootId=1表示它的顶级评论是id=1的评论，用replyId=2表示它回复的是id=1的评论；

id=4是子级评论，它回复了id=2的评论，此时rootId=1表示它的顶级评论是id=1的评论，用replyId=2表示它回复的是id=1的评论；

如果现在要查询id=1的评论下的所有子级评论，那么查询方式如下图所示：

通过rootId查询评论数据，只需要一条sql直接就可以完成数据的查询，这样得到一个扁平的列表，然后在内存里使用代码里把数据组装好给客户端展示。

4、按热度排序的性能问题解决方案

如果现在要把热度最高的评论查询出来，对于数量大的情况下是不能在使用sql的order by方式获取数据，因为在大数据量下实时排序，数据库将会是性能的瓶颈，此时我们需要借助Redis的Zset数据类型来解决这个问题，如下图所示：

通过Redis缓存top100热评论数据，然后客户端查询热门评论的数据直接从Redis中读取，不仅速度快、用户体验好，而且也保护了系统不被拖垮。

5、用户点赞的高并发问题解决方案

热点稿件（视频或者文章）可能会有百万人同时点赞，如果用户的每次点赞都去实时更新数据库，那么数据库就是最大的瓶颈，可以采用先同步Redis在同步数据库的方案解决，如下图所示：

当用户点赞稿件后，客户端首先要将稿件上的点赞数+1（目的是提高用户的体验），然后客户端发送点赞的请求到服务器上，后端处理的逻辑是直接在Redis把稿件的点赞数+1，这个在Redis中处理是非常的快；然后Redis定期（如5秒）同步一次数据到数据库中。

对于用户点赞数据来讲，即使Redis宕机而导致几秒数据的丢失，其实也是没有关系的，一方面用户无感知，另一方面数据严格性没转账数据那么强。

总结：

（1）针对评论盖楼的数据存储方式可以采用冗余rootId的方案实现

（2）高并发的和大数量的评论系统中，借助Redis来扛住数据查询和保护系统的稳定性。

https://mp.weixin.qq.com/s/St3Fkz0usHq2GtYhLw2xJw