网页评论系统设计 第1篇
用户：用户相关信息，基础表。
文章：文章基础信息，业务表。
图片：文章相关联图片，业务表。
属性：文章相关联属性，业务表。
文章评论数，通过添加评论，动态更新字段。
点赞数。
文章 tags。
评论：文章评论，业务表。
文章 ID
rootId，如果是直接评论文章，这个值为 0，否则将设置为根评论节点的 ID。根评论节点代表为评论文章的评论的节点。
parentId，如果是直接评论文章，这个值为 0，否则设置为评论节点的 ID。评论节点代表为回复评论的节点
网页评论系统设计 第2篇
背景：
评论是生产用户内容的服务，那么对评论内容的运营则决定着整个评论区的氛围，对于优质/有趣或带有特殊属性的评论内容应该得到更多的曝光率，同时我们也希望低俗/辱骂/无意义的评论内容得到更少的关注，这样用户之间的互动才能得到正向的循环，这就要求评论服务构建一套排序机制，在产品层面上能够满足排序的需求，在技术上也可以做到排序数据快速收敛，不影响服务性能的前提下快速迭代。
思路：
在制定技术方案之前，我们需要考虑到几个核心问题，首先是如何对评论内容进行排序？
最容易想到的方案是为每条评论评估一个分值，按照分值的大小来输出一篇文章下的评论内容，以达到排序的效果；那么既然每条评论有了评分属性，接下来就要定义这个评分的公式，按照这个思路我们可以罗列出很多影响评论分值的因子。
比如一条评论的点赞数，回复数，创建时间等等，同时为这些因子设定相应的权重，组合起来可以计算出总分，在这个过程中，我们需要考虑公式的迭代给系统带来的性能冲击，当一个公式被确定下来，并不能马上推送到线上，而是需要小流量来评估排序结果带来的收益才能决定公式的因子或者因子权重是否是一组正确的组合，这便涉及到可能存在多组公式并存的情况，并且可以预料到公式的调整将会是频繁的迭代。
根据这些思路，我们最终开发出评论排序框架，采用离线计算评论分值，公式配置化，扇出并发模型等技术手段实现了智能化评论排序功能，下面我们详细看下架构设计。
方案：
评论排序服务分为两部分，离线粗排服务与在线精排干预。
首先介绍下离线粗排服务，我们将评估评论分值/输出排序列表的任务放在离线模块中执行，在数据量较大的情况下离线运算不会影响到线上服务。离线模块会监听评论行为队列，例如评论回复，评论点赞，评论删除，评论置顶等能够影响评论列表数据变更的行为，离线排序服务消费到行为数据后通过策略公式计算出评论分值，最终存储到排序索引中，这个流程涉及到的技术点如下：
单排服务；当一条评论数据发生变更时，触发单条评论分值的重新计算，判断是否需要触发全排服务，如果需要则将全排指令写入全排队列中，否责将最新的分值评估更新至排序索引中。
全排服务；从全排队列中读取全排指令，获取到评论所属的主题ID，遍历该主题ID下的所有评论，重新评估每条评论的评分，写入至排序索引中。此处使用了Golang语言的扇出模型，队列通过channel实现，管理多个协程并发消费channel的全排指令，减少数据消息的积压。
排序算子：在评估评论分值过程中，使用调度器并发获取排序因子所需要的数据，例如评论基础信息，主题物料信息，策略模型服务，提权/降权词表，重复内容库等，获取到的元信息通过排序公式的权重完成评估过程。
语义化公式：通过语义化公式识别，实现配置化上线，这里的考量是，线上的效果需要不断调整每个算子的权重来小流量验证，那通过这种方式可以实现快速上线完成验证，对研发效率及产品迭代都是非常高效；
排序索引：排序索引采用Redis作为存储介质，通过zset数据结构来维护一篇文章下的评论排序列表。不同的公式组成不同的策略，在多组策略同时生效时，排序索引会以文章维度生成多个策略的排序结果，同时维护多套ID索引，评论线上服务通过小流量读取策略组来命中不同的排序结果，方便AB实验。
离线粗排服务会针对评论的相关属性输出排序结果，在线部分，我们又对排序结果做了个性化的二次干预，包括个人评论提权，通讯录/关注好友评论提权，以及精排模型干预，这些策略帮助我们更为精准地定位用户群体的喜好，增加用户浏览评论的共鸣感。
网页评论系统设计 第3篇
评论从生产到读取历经多个环节，下图是评论生命周期中各个环节的简易模型：
评论数据的生产由用户触发，评论系统维护了与资源关联的主题数据，通过主题信息来检索归属的评论内容，评论数据本身维护了发表人，层级关系，是否展现状态，内容，点赞数，回复数，时间等等，每个数据维度用于特定的展现场景以及数据分析。
在用户生产内容过程中，系统识别恶意请求，针对用户、资源、内容等维度进行层层过滤，完成数据落盘，数据采用分布式数据库存储，同时根据查询维度进行垂直/水平拆库拆表，以解决业务持续增长带来的数据读写性能瓶颈，数据层面的变更最终落入大数据中心，用来分析业务现状以及未来的发展发向。
—3 —