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

在主流的视频网站和社交网站中评论是非常重要的模块之一因为评论模块不仅为用户提供真实、可靠的决策参考信息而且也为商家或平台提供宝贵的用户参与数据同时增强用户互动与社区粘性。所以一套功能完善、高性能和高可用性的评论系统对于用户量很大的网站来讲是非常重要的。那么在评论系统中的用户对于其他的用户的某条评论在继续无限制的追加评论该如何设计呢下面我们聊聊其设计方案。1、评论盖楼数据存储设计方案——添加parentId关联在设计评论表的时候在表中添加字段parentId字段这个字段用于标识父级评论如下图所示的评论表和表中存储的数据如上图所示id1的评论parentId0那么标识id1的评论是父级评论然后id2的评论是id1评论子评论此时这个子评论的parentId设计成等于1这样就将父级评论和子级评论关联起来了。如果现在要查询一个评论下面的所有回复的子评论此时查询的步骤是先查询父级下的子级评论然后查询子级评论下的子级评论如下图所示如果id1的评论楼盖了1000层那么在规范的查询要求下我们就要向数据库发1000次SQL查询请求一旦系统的并发上来后数据库连接池瞬间就会被这种递归查询占满进而导致整个系统的崩溃。2、评论盖楼数据存储设计方案——存储路径方案既然使用parantId存储评论盖楼数据存在查询的问题那么我们是换个思路将评论盖楼使用一个字段标识出来如图所示在表中path字段记录了当前的评论的父级评论是来自哪个评论如id3的评论它的父级评论是id2的评论id2的评论的父级评论是id1的评论这样的设计不仅层级清晰而且查询也方便如果要查询id1的评论下所有的子级评论一条sql就可以完成查询如下所示虽然存储评论路径的方案方便查询但是也存在一个比较致命的缺点如果用于一旦删除了id2的评论那么id2的评论下的子级评论都要重新维护如下图所示如果是一个热门的帖子或者视频那么在评论的数据量非常大的情况下如果将含字段path中含有id2的评论数据全部找出来并且更新掉这就出现了严重写放大问题。3、评论盖楼数据存储设计方案——冗余rootId的方案反范式设计方式增加一个字段rootId顶级楼层id这也是现在主流网站中比较通用的一种设计方案如下图所示一个父级的评论然后父级评论下继续有子级评论两个用户分别就某个子级评论做了回复我们使用两行分别展示评论的数据针对这种扁平化的评论盖楼系统的数据存储表的设计如下图所示id1是父级评论它的rootId 0id2是子级评论它回复了id1的评论此时rootId 1用replyId1表示它回复的是id1的评论id3是子级评论它回复了id2的评论此时rootId1表示它的顶级评论是id1的评论用replyId2表示它回复的是id1的评论id4是子级评论它回复了id2的评论此时rootId1表示它的顶级评论是id1的评论用replyId2表示它回复的是id1的评论如果现在要查询id1的评论下的所有子级评论那么查询方式如下图所示通过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