除了写热点，评论的读热点也有一些典型的特征：
1. 由于大量接口都需要读取评论区基础信息，存在读放大，因此该操作是最先感知到读热点存在的。
2. 由于评论业务的下游依赖较多，且多是批量查询，对下游来说也是读放大。此外，很多依赖是体量相对小的业务单元，数据稀疏，难以承载评论的大流量。
3. 评论的读热点集中在评论列表的第一页，以及热评的热评。
4. 评论列表的业务数据模型也包含部分个性化信息。
因此，我们利用《直播场景下 高并发的热点处理实践》一文所使用的SDK，在读取评论区基础信息阶段探测热点，并将热点标识传递至BFF层；BFF层实现了页面请求级的热点本地缓存，感知到热点后即读取本地缓存，然后再加载个性化信息。
热点探测的实现基于单机的滑动窗口 LFU，那么如何定义、计算相应的热点条件阈值呢？
首先，我们进行系统容量设计，列出容量计算的数学公式，主要包括各接口QPS的关系、服务集群总QPS与节点数的关系、接口QPS与CPU/网络吞吐的关系等；然后，收集系统内部以及相应依赖方的一些的热点相关统计信息，通过前面列出的公式，计算出探测数据项的单机QPS热点阈值。最后通过热点压测，来验证相应的热点配置与代码实现是符合预期的。
冗余与降级
上文提到，评论基础服务层集成了多级缓存，在上一级缓存未命中或者出现网络错误后，可以视具体场景要求降级至下一级缓存。各级缓存可能有功能上的略微差异，但都能保障用户的基础体验。
此外，评论系统是一个同城读双活的架构。数据库与缓存均是双机房独立部署的，均支持多副本，具备水平扩容的弹性。针对双机房架构下特有的副机房数据延迟故障，支持入口层切流/跨机房重试/应用层补偿，尽可能保证极端情况下用户无感。
在功能层面，我们做了重要级别划分，把相应的依赖划分为强依赖（如审核）、弱依赖（如粉丝勋章）。对于弱依赖，我们一方面在异常情况下坚决限流熔断，另一方面也通过超时控制、请求预过滤、优化调用编排甚至技术方案重构等方式持续优化提升非核心功能的可用性，为业务在评论区获得更好的曝光展现。
安全性设计
评论系统的安全性设计可以分为「数据安全」与「舆论安全」。
数据安全
除了数据安全法所要求的以外，评论系统的数据安全还包括「合规性要求」。评论数据合规，一方面是审核和风控，另一方面对工程侧的要求主要是「状态一致性」。例如，有害评论被删除后，在客户端不能展现，也不能通过API等对外暴露。这就对数据一致性，包括缓存，提出了较高要求。在设计层面主要有两方面实践：
1. 数据读写阶段均考虑了一致性风险，严格保证时序性。
2. 对各类数据写操作，定义了优先级，避免高优先级操作被低优先级操作覆盖，例如审核删除的有害评论，不能被其他普通运营人员/自动化策略放出。
3. 通过冗余校验，避免风险数据外泄。例如评论列表的露出，读取sorted set中的id列表后，还需要校验对应评论的状态，是可见态才允许下发。
舆论安全
舆论安全问题更为泛化。接口错误导致用户操作失败、关闭评论区、评论计数不准，甚至新功能上线、用户不满意的评论被顶到热评前排等问题均可能引发舆情问题。
在系统设计层面，我们主要通过几方面规避。
1.不对用户暴露用户无法处理和不值得处理的错误。例如评论点赞点踩、某个数据项读取失败这一类的轻量级操作，不值得用户重试，此时告知用户操作失败也没有意义。系统可以考虑自行重试，甚至直接忽略。
2. 优化产品功能及其技术实现，例如评论计数、热评排序等。
这里重点介绍一下评论计数的优化思路。
计数不一致的根源，是数据冗余造成的。一般出于性能考虑，会在评论列表以外，给这个列表记录一个长度。也就是用SELECT count FROM subject，代替 SELECT count(*) FROM reply_index。基于这种冗余设计，count字段大部分都是增量更新，即 1、-1，是容易出现误差累积的。
评论计数不准的原因主要有几方面：
1. 并发事务导致的「写倾斜（write skew）」，例如依据评论的状态来做评论区的计数更新。在A事务中读取的评论状态，可能在B事务中被修改，此时A事务计数更新的前提被破坏，也就造成了错误的增量更新。此时计数可能偏大或偏小。
2. 运行时异常、脏数据或者非常规的展示侧控制，导致部分数据被过滤。此时计数可能偏大。
3. 计数冗余同步至其他系统，例如视频表的评论数，延迟导致了过程不一致，同步失败则直接导致最终不一致。
对应并发事务的解决方案，主要有两种：
1. 事务加锁。综合评估而言，对性能的影响较大，特别是存在"锁放大“，越需要加锁的场景，越容易出现”锁冲突“。
2. 串行化。将评论区的所有操作，抽象为一个排队的Domain Events，串行处理，不容易出错。那为什么不能按照评论维度进行拆分，更加不容易出现评论区维度的热点？因为上文提到，删除一级评论时，实际也会从计数上删除其回复；删除二级评论时，也会更新其根评论的计数。多个评论的操作相互影响，因此按照评论维度进行拆分仍然存在并发事务问题。
热评设计
什么是热评
早期的热评，实际就是按照评论点赞数降序。后来衍生了更为复杂的热评：既包括类似「妙评」这种用户推荐、运营精选且带logo突出展示的产品形态，也包括各类热评排序算法，且热评排序算法应用场景也不仅局限于评论主列表的热度序，还包括楼中楼（外露子评论）、动态外露评论等。
热评排序逻辑一般包括点赞数、回复数、内容相关、负反馈数、“时间衰退因子”、字数加权、用户等级加权等等。如何在B站评论区脱颖而出？[7]一文从内容运营层面，介绍了什么样的评论更容易上热评前排。
咬文嚼字来说，我们对「热」的理解，大致分为几个阶段：
1. 点赞高，就代表热度高。→ 解决热评的有无问题
2. 基于用户正负样本投票的，加权平均高，就代表热度高。→ 解决高赞高踩的负面热评问题
3. 短时间内点赞率高，就代表热度高。→ 解决高赞永远高赞的马太效应
4. 热评用户流量大，社区影响也大。要权衡社会价值观引导、公司战略导向、商业利益、UP主与用户的「情绪」等。→ 追求用户价值平衡
挑战与应对
显然，我们在不同阶段对热评的理解，在系统设计上也提出了不同层面的要求：
1. 按照点赞绝对值排序，即要实现ORDER BY like_count的分页排序。点赞数是一个频繁更新的值，MySQL，特别是TiDB，由于扫描行数约等于OFFSET，因此在OFFSET较大时查询性能特别差，很难找到一个完美的优化方案。此外，由于like_count的分布可能出现同一个值堆叠多个元素，比如评论区所有的评论都没有赞，我们更多依赖redis的sorted set来执行分页查询，这就要求缓存命中率要非常高。
2. 按照正负样本加权平均的，即Reddit：威尔逊排序[6]，到这个阶段，数据库已经无法实现这样复杂的ORDER BY，热评开始几乎完全依赖sorted set这样的数据结构，预先计算好排序分数并写入。于是在架构设计上，新增了feed-service和feed-job来支撑热评列表的读写。
3. 按照点赞率排序，需要实现点赞率的近实时计算。点赞率=点赞数/曝光数，曝光的数据来源是客户端上报的展现日志，量级非常大，可以说是一个写多读少的场景：只有重算排序的时候才会读取曝光数。
4. 追求用户价值平衡，需要处理各种细分场景下的差异化需求。热评排序与feed排序很像，但也有一点根本性差异：feed排序我们往往都希望是个性化的，每个人看到的都不相同，但评论往往不会如此激进，一般来说会希望大家看到的评论排序都大致相同。由于排序问题的解决方案是探索型的，因此系统设计层面需要提供更多元、更易扩展的工程化能力，包括算法和策略的快速迭代、实验能力等，并提升整个热评模块的可观测水平，监控完善、数据报表丰富、排序过程可解释等等。在架构上，新增了strategy-service和strategy-job来承担这部分策略探索型业务。
此外，数据量级规模的增加，也对系统的吞吐能力提出了更高要求：不管热评的算法如何变化，一般来说，热评列表都需要能够访问到全部评论，且基本维持相同的热评排序逻辑。在评论数过百万甚至千万的评论区，热评排序的挑战点主要在于：
1. 大key问题：例如单个sorted set过大，读写性能都受影响（时间复杂度的基数可以认为都是O(logN)）；全量更新时，还可能遇到redis pipeline的瓶颈。
2. 实时性放大存储压力：多样化的数据源，对特征的导入与更新都提出了挑战，需要支持较丰富的数据结构，和尽可能高的写吞吐（想象一下曝光数作为排序特征的变态要求）；与推荐排序不同，热评排序是全排序，此时需要读取全部评论的全部特征，查询压力也会非常大。
这一阶段，我们仍然在持续优化，在工程落地层面尽可能还原理想的排序算法设计，保障用户的热评浏览体验。目前形成的系统架构总体如下图所示：
图示的「评论策略层」，负责建立一套热评调控体系化能力，通过召回机制来实现想要的“balance“。即先通过策略工程，召回一批应该沉底的不良评论或者应该进前排的优秀评论，然后在排序分计算阶段根据召回结果实现这样的效果。
这样做的好处是，可以保留一套通用的底层排序算法，然后通过迭代细分场景下的召回策略，来实现差异化评论排序的平衡。
召回策略的工程设计，按照分层设计的原则拆分为3个部分：
1. 因子机。主要职责是维护策略所需的全部「因子」，包括一些已有的在线/离线数据，也包括为了策略迭代而需要新开发的流式的窗口聚合数据。因子机的重难点是需要管理各种数据获取的拓扑关系，以及通过缓存来保护下游（数据提供方很难也不应该承受热评业务的巨大流量）。所有的因子可以构成一个有向无环图，通过梳理依赖关系和推导计算，实现并发提效、减少冗余。
2. 规则机。实现了一套声明式规则语法，可以直接引用因子机预定义的因子，结合各种逻辑算子构成一个规则表达式。规则机执行命中后，会向下游传递预先声明的召回决策，例如排序提权。
3. 召回处理中心。这一层的职责就是接收规则机返回的各种决策并执行，需要处理不同决策的优先级PK、不同规则的决策叠加作用、决策豁免等。
热评排序涉及的特征，是多数据源的，数据更新方式、更新频率、查询性能也天差万别。因此我们针对数据源的特点做了多级缓存，通过多级冗余与跨级合并，提升了特征读取的稳定性与性能上限。当然，其中的数据实时性、一致性、可用性，仍然处于一个动态权衡取舍的过程。举个例子，曝光数使用redis计数器维护，受限于成本并未持久化；各类静态模型分存在4到5层冗余。此外，还应用了内部稀疏数据的bloom-filter查询、数据局部性集中与散列相结合、近实时大窗口聚合计数等多种性能优化手段。需要指出的是，召回和排序两阶段都需要查询因子/特征，得以复用「因子机」，完成各个特征的差异化实现与维护。
热评排序最关键的计算模块，首先是引入了自适应的冷却算法，根据评论区的评论数、活跃程度等，对重算排序的收益进行预估，拦截了大部分低价值重排请求。其次在全量打分排序阶段，「排序策略」贯穿上下文，既支持传统的静态的经验算分公式，也支持动态的模型打分，支撑AI模型的快速部署快速迭代。通过组合与继承，支持排序策略的叠加、微调，结合评论网关层的排序策略路由，可实现各类定制化排序，完成热评排序系统的平台化。
除了大家点开评论区看到的“热评”，在楼中楼、动态外露评论、评论详情页等类似场景，我们同样应用了这套热评系统，在工程上实现了架构的统一。
