)
背景
评论系统，不属于电商系统的核心链路，但当评论数据较大时，也将为成为瓶颈。本文讨论评论系统的设计。
问题
评论系统的特点是：嵌套评论，当嵌套层级多的时候，性能会出现问题。所以，我们主要解决的是盖楼问题。
业界主流到盖楼模式有两种。
1、嵌套模式：一层套一层，无限循环嵌套。
2、盖楼模式：不论多少层，都在同一层级展示。
目前微信、抖音采用第二种方式，只保留两层，要么是楼主，要么是回复信息。
数据库：嵌套模式
1、邻接表
主键Id | 父级Id | 内容 |
1 | 0 | 种草 |
2 | 1 | +1 |
3 | 1 | +2 |
优点：写入速度快、查询效率低。每个记录只需要记录父级Id即可。存储结构简单，易于理解。
不足：递归查询性能差，需要N+1次；删除中间节点，维护成本高。
2、全路径
主键Id | 路径 | 内容 |
1 | 1/ | 种草 |
2 | 1/2 | +1 |
3 | 1/2/3 | +2 |
优点：查询方便，使用like'1/2%'，符合索引最左原则，性能高。存储了直观的层级关系。
不足：Path长度受字段类型和长度大小限制，层的修改维护较复杂。
3、闭包表
祖先Id | 后代Id | 深度 |
1 | 1 | 0 |
1 | 2 | 1 |
1 | 3 | 2 |
优点：查询性能高、支持层级快速移动。
不足：存储开销大（两张表，一张数据表、一张关系表），写入逻辑复杂。
通常，闭包表方案，是平衡i性能和可维护性的最佳方案。
数据库：盖楼模式
盖楼模式采用两层结构，避免了递归调用。只需存储一级评论和二级评论（所有回复）即可。
主键Id | 一级评论Id | 回复Id | 内容 |
1 | 0 | 0 | 种草 |
2 | 1 | 1 | +1 |
3 | 1 | 2 | +2 |
查询所有一级评论，不需要遍历，直接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
