核心内容摘要
刘亦菲“大战黑金刚3”：荧幕传奇与观影指南
评论是个人观点的出口是公共领域的基石它鼓励参与者理性讨论形成多元意见市场塑造个人在社群中的形象获得认同感与影响力。
对个体而言评论可成就独立思考与表达自由对社会而言评论可维系理性对话与文明演进对时代而言评论可记录精神轨迹塑造集体记忆。
新闻App下的评论是新闻内容的延伸、公共观点的载体它兼具“观点属性”和“舆论属性”其
核心价值主要是围绕新闻内容做观点表达本质是对新闻事件的补充解读附加价值在于承载了公共议题的讨论热点事件等。
而其它非新闻类App下的评论大多都是为了服务核心业务多数可能无“舆论属性”例如电商App服务于交易闭环其评论是“商品参考”核心是帮其他用户判断商品好坏辅助下单转化。
本文针对新闻App评论体系的部分核心功能和排序逻辑进行了讨论重点介绍了后端相关实现的演进过程旨在为该领域的体系化建设提供多元认知与实践借鉴。
下面将从评论分库分表、列表展示、实验平台、话题聚合、中台建设展望等方面来阐述新闻App评论后端体系的“昨天、今天和明天”。
01评论的昨天评论的发布流程大致如下评论发布之后早期的展示情况是怎样的呢评论盖楼的实现早期评论列表是以盖楼形式展示的如图所示数字
1、
3表示楼层1楼是最原始的评论想实现这样的盖楼列表可以通过哪些方式实现呢实现方式做法优点缺点邻接表每条评论都记录其父评论的ID简单直观查询父评论容易查询多层嵌套式需递归性能可能随深度增加而下降路径枚举每条评论都存储从根评论到当前评论的路径如
是根2回复了13回复了2查询楼上的所有内容方便楼层比较高时可能也有性能问题一般需限制楼层总层数闭包表使用一个额外的表来存储评论之间的关系每一行记录祖先节点和后代节点之间的关系查询关系灵活需要额外的表且数据量随着嵌套深度增加而增加非关系型数据库的文档结构在文档中直接以数组形式存储子评论将嵌套关系内嵌在文档中读多写少场景下有一定优势嵌套深度有限且文档大小可能超出限制混合模式结合以上几种方式的优点基于用户规模、评论深度、实时性等因素我们采用了“邻接表”“路径枚举”这种混合模式的思路来实现盖楼的评论列表展示。
这种混合模式不仅可以实现盖楼也可为后续平铺的评论列表展示打下基础一定程度上增加了可扩展性。
相关类图如下评论分为主评论表和回复表每一条主评论都会冗余存储在回复表内目的是以空间换取部分迭代的灵活性。
回复表的sessionId记录了其父级id至主评论id在Reply表里的id这条路径上所有的言论id当需要展示某一回复所有楼上信息时只需一条SQL查询语句即可在Reply表查询出所有的楼层信息commentId属性的设计是为了获取主评论下所有的回复列表parent属性的设计是为了获取某一回复下所有的回复列表。
这些属性都是基于将来可能的扩展而设计的。
热门评论早期热门评论列表的展示是通过点赞数倒序实现的点赞数大于阈值的评论才会出现在热门列表里除点赞数之外并无其它策略的干预。
02评论的今天分库分表评论系统运行一段时间后我们发现单Comment表、单Reply表不能满足性能等要求需要分表。
第一次分表我们采用了双写的方式流程是双写不双读验证数据一致性-双写双读部分流量验证查询一致性-双写、只读新表-只写新表只读新表。
第一次分库分表经历了5年多的稳定运行后在2024年我们发现分表后的单表容量即将对性能产生影响但此时数据库单库的容量不便于继续分表所以需要既分库又分表。
我们对一些分库分表的工具进行了调研结果是• 分库分表工具可用但需要双写、双读等增加额外风险已有评论量级大。
需要扩容时数据迁移和重新分片可能是个挑战• 分库分表工具在SQL解析、路由、结果合并等有一定性能开销尤其是在跨多个分片查询时• 评论库非常重要尽量以最小的改动实现目标• 新闻具有一定的时效性老的新闻评论写入量一般比较少• 我们可以采用预判文章id的方式不引入额外框架文章id达到某一阈值则读写新库• 通过文章id方式分库分表实现简单、风险低、无多余性能开销再扩容等操作容易最终我们采用一种简单的分库分表方式在上线当天预判文章id的最大值文章id在上线当天肯定不会达到这个最大值。
上线后大于此id的文章评论进入新库小于此文章id的评论还会写老表如上图右侧所示。
在分库的过程中我们发现现有的评论id生成方案不支持分库。
因项目使用的分布式id是严格递增的有许多接口都在使用评论id进行排序老库里的评论和回复表创建时间只精确到小数点后两位基于这些因素我们设计并实现了一种严格递增的分布式id生成器旨在解决目前我们项目中遇到的分库问题流程如下图所示详见另一篇文章《如何生成严格递增的分布式id》。
盖楼列表查询-平铺的最热、最新查询列表新闻App在经历了一些版本的迭代后评论列表的展示由原来的盖楼方式变为了平铺的列表展示且分为“最热”和“最新”两个tab页。
最热tab列表的展示和原来的热门评论列表类似但可以采用不同的策略下面我们描述三种不同的“最热”列表展示策略。
最热评论列表展示策略策略一-按评论点赞数倒排和“热门”评论列表一样按点赞数倒排不设阈值点赞数相同按评论发布时间倒序。
策略二-类“推荐”形式按点赞数倒排实现简单但判断是否最热只参考点赞总数这一维度可能不够准确。
是否还有其它的方式来判断最热呢我们联想到推荐的形式将评论划分为多个维度不同维度的评论数据一同给到算法侧算法侧实时计算并将排序完的评论id返回。
我们主要将评论划分为6个维度每一个维度的评论数据缓存若干条缓存失效后重新从数据库拉取。
我们将算法的Rank模块引入到评论项目用户点击评论区查看最热评论列表的时候我们先并发“召回”6个维度的评论数据之后过滤用户已浏览的评论数据剩余评论数据通过API传递给算法Rank模块Rank模块同步返回排序结果。
如果推荐给用户的评论条数剩余不足x条x阈值可根据业务自由设定那么我们将启用二阶段缓存继续从数据库里读取一些评论数据缓存并传递给Rank模块。
所用策略优势主动缓存被动缓存结合二阶段缓存解决数据量级和数据库压力问题不同维度不同刷新时间不同维度缓存过期时间不同以此来优先“推”某些维度的数据采用依赖而非接口调用同算法交互简单避免一些网络开销这种类“推荐”的形式综合考虑了评论的多个方面避免只考虑点赞这一单一维度。
但Rank模块是”静态“引入的如果算法调整Rank策略则我们的服务必须”一同“打包发布才能应用这些新策略且这种缓存方式可能导致有些评论”永远“不会展示在”最热“列表。
是否有更好的方式既能通过算法策略来推荐评论又能避免如上的问题呢策略三-算法得分为了解决策略二的问题我们采用了“算法得分”的方式为每一条评论都计算一个分值分值的高低用以排序。
评论分数的计算是在评论首次发布、评论有互动时、评论被设置权重、评论被选为神评等时机具体流程如图所示当评论首次产生或者有各种交互的时候我们将其放入队列。
调度程序不断从队列里获取评论然后传递给算法侧。
如果算法侧有策略调整评论服务不用上线且所有的评论都会有得分避免了策略二的一些问题。
评论实验最热的计算方式有多种如何感知哪一种最热策略是有优势的呢如果是算法得分策略更好那么哪一种算法得分策略更好呢经调研已有的一些实验平台不适合做评论的实验于是我们自研发了SNS评论实验系统。
实验系统目标• 支持算法侧对正文评论区的多桶实验• 保证性能的前提下通过实验系统快速获取评论列表以及评论数• 留有一定的扩展性为以后实验打下基础评论实验系统架构图评论或回复新增时的流程图评论查询时的流程图评论有交互时的流程图评论实验系统设计的宗旨是通过实时计算来换取迭代的灵活性。
针对最热列表可以同时进行不同的实验。
目前评论实验系统已为推全评论区展示方式提供了数据支持也为后续评论实验打下平台基础。
话题聚合新闻App另一个重要功能是话题聚合相同或类似事件的新闻通过算法或者人工筛选的方式“汇聚”在一起每一篇新闻下的评论也会聚合到一起形成统一的讨论场。
相同的评论可能出现在多个不同的聚合话题下如何保证评论一处修改、处处更新呢即评论的交互结果要在所有出现的地方都体现。
我们采用了一种类似“广播”的方式交互图如下广播报文实际上是一条kafka消息这条kafka消息会在不同的评论系统间传递文章评论和话题评论隶属于不同系统其结构如下广播的方式依赖于各种关系表的维护比如一条文章评论聚合到了哪些话题下我们会维护一张表表字段有源评论id话题id评论在话题里新生成的“伪评论”id这样当文章评论属性有变化时通过广播的方式“广播”给接收方接收方查关系表检索出源评论id聚合到的所有话题id记录然后更新话题下相对应的评论属性。
03展望-明天展望一-评论中台建设我们对百度评论体系、微博平台架构、B站评论系统架构设计、字节评论中台进行了简单调研调研发现通过适当的模块化、抽象化和可定制功能实现我们的评论中台系统是可行的。
一种预期的评论中台架构图如下所示未来通过评论中台业务方可以快速的引入评论功能还可以在此基础上实现自定义的一些功能如下图所示AI生成展望二-AI驱动的评论系统架构演进未来可以引入AI的一些能力来优化评论系统架构具体可通过以下方面来实施。
合规检查自动化针对黑灰产的对抗性攻击平台需升级审核合规体系构建“多模态融合识别动态迭代优化”的AI审核模型——融合画面、语音、文本等多维度信息进行综合判断提升对反侦察手段的识别能力。
同时定期收集黑灰产的最新攻击样本对模型进行迭代训练增强模型的健壮性。
此外需合理配置AI审核与人工复核的比例在高并发场景下自动提升AI审核权重保障实时拦截效率。
情感分析与用户互动优化未来不仅可以通过算法分值对评论排序还可以通过AI对评论排序。
通过AI分析评论内容的情感价值以及讨论质量情感价值高、讨论质量优的评论将排在前几位。
还可通过AI实现实时情感仪表盘看板展示情感价值高的一些言论方便运营。
评论数据库自治运维未来通过AI有可能实现如下几方面数据库相关的自运维• 全自动数据库运维• 自动优化慢查询• 自动数据重平衡• 自动连接池调整• 预测性维护• 自适应学习• 识别未使用的索引• 预测未来需要的索引• 自动创建/删除索引实时洞察与决策支持借助AI未来我们有望实现• 情感洞察• 话题洞察• 争议检测发现热点问题• 预测某些指标• 行动建议• 自动生成评论业务相关报告• 实时预警策略除上面列出的几项AI还可能实现评论智能查询优化与路由、评论存储相关的动态分片、基于AI的评论列表查询缓存预热、AI辅助评论系统的开发、自然语言到评论操作SQL的智能转换等。
一种可能的AI改造评论系统路线图如下AI生成
总结-AI带来的评论体系转变维度传统评论系统AI驱动的评论系统架构理念规则驱动、静态分片数据驱动、动态适应性能优化被动响应、经验调优预测预防、自动优化内容治理关键词过滤、人工合规检查语义理解、智能分级用户体验千人一面个性化、价值排序运维模式人工监控、手动干预自运维、自恢复开发效率手动编码、复杂调试AI辅助、自动生成业务价值基础互动功能深度洞察与创新互动AI带来的评论体系转变其核心思想是未来的评论后端不再是简单的数据存储查询系统而是一个能感知、能思考、能适应、能进化的智能有机体。
它能够理解内容语义、预测用户行为、优化资源分配、甚至主动促进有意义的对话。
对于技术团队而言未来重点可能将从如何实现分库分表转变为如何设计AI友好的数据架构和如何构建持续学习的系统。
这不仅是技术升级更是思维方式的根本转变。