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