滁州市网站建设_网站建设公司_网站建设_seo优化

背景

评论系统，不属于电商系统的核心链路，但当评论数据较大时，也将为成为瓶颈。本文讨论评论系统的设计。

问题

评论系统的特点是：嵌套评论，当嵌套层级多的时候，性能会出现问题。所以，我们主要解决的是盖楼问题。

业界主流到盖楼模式有两种。

1、嵌套模式：一层套一层，无限循环嵌套。

2、盖楼模式：不论多少层，都在同一层级展示。

目前微信、抖音采用第二种方式，只保留两层，要么是楼主，要么是回复信息。

数据库：嵌套模式

1、邻接表

优点：写入速度快、查询效率低。每个记录只需要记录父级Id即可。存储结构简单，易于理解。

不足：递归查询性能差，需要N+1次；删除中间节点，维护成本高。

2、全路径

优点：查询方便，使用like'1/2%'，符合索引最左原则，性能高。存储了直观的层级关系。

不足：Path长度受字段类型和长度大小限制，层的修改维护较复杂。

3、闭包表

优点：查询性能高、支持层级快速移动。

不足：存储开销大（两张表，一张数据表、一张关系表），写入逻辑复杂。

通常，闭包表方案，是平衡i性能和可维护性的最佳方案。

数据库：盖楼模式

盖楼模式采用两层结构，避免了递归调用。只需存储一级评论和二级评论（所有回复）即可。

查询所有一级评论，不需要遍历，直接where 一级评论id=Id即可。

如何写

写入时，异步入库，数据最终一致性。发MQ消息，MQ消费者，消费，入库。为保证页面的展示，前端JS缓存并写页面。

如何读？

上面解决了存储（写）的问题，如何读呢，面对百万千万用户，访问呢？如果直接查询数据库，系统会瞬间宕机。我们采用的方案是：针对热数据进行缓存，冷数据按需加载。

1、热点缓存：通常用户只看前几页评论，所以可以将热点数据，存储在redis中，使用zset数据结构。

2、按需加载：对于冷门数据，懒加载，当用户点击时再查数据库。分页采用游标翻页方式，记录上一页最后的位置，如：WHERE id < ? ORDER BY id DESC LIMIT ?，而不是offset方式翻页：LIMIT offset, size 。

全链路

上文主要描述了，评论系统的数据层设计，以及读写的内容。一个完整的设计是全链路的，所以还会涉及限流，降级，熔断，服务拆分等内容。

架构设计是一个系统工程，个人最新的打算是，尽量输出些内容，或许只是一部分或只是一个概括的点（读者可以根据这个点，搜索相关的内容，逐步组成线和面）。或许这些内容融入原有的设计中，就是一个完整的系统。

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