最新要闻
- 环球微资讯!多地或迎来30℃的“春天”:今夏是否会遭遇极端高温?专家回应
- 每日热讯!宜家储物柜竟成网红打卡地 上海宜家禁止在仓库拍照
- 每日消息!农民工大哥火车上用盆炫10袋泡面 饭量让网友惊叹:干活能吃更多
- 环球观焦点:海尔为何能反超格力
- 天天快消息!微软坚信Switch可原生运行《使命召唤》:没有理由不能优化
- 3月9日生意社DBP基准价为9475.00元/吨
- 环球今头条!中核首席专家:人造太阳有望在30年后实现供能 核聚变商用
- 【天天报资讯】有你在的城市吗?中国“民富”50城:沪京苏杭位列前4 长三角仍是最富庶地区
- 0.536秒!清华学子拍到中国空间站凌月 画面震撼:网友为中国航天点赞
- 每日讯息!15年耗费万亿日元 日本国产飞机梦碎:原型机被拆解
- 【全球新视野】夫妻200万造别墅找陌生人抱团养老 每月1500元 网友并不看好
- 世界观天下!湖北现购车狂潮 东风系最高降9万遭疯抢 乘联会:其他省份或效仿
- 全球播报:专家权威点评比亚迪CTB技术:刀片与车身完美结合 只能在比亚迪才能实现
- 天天亮点!促销潮蔓延 汽车全面降价已来临?比亚迪或是最大功臣!
- 当前时讯:新生儿史低 日本恐将不复存在:工业正在崩溃边缘
- 每日消息!湖北现购车狂潮:最高发9万元补贴 12万买合资B级车
手机
iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?
警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案
- iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?
- 警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案
- 男子被关545天申国赔:获赔18万多 驳回精神抚慰金
- 3天内26名本土感染者,辽宁确诊人数已超安徽
- 广西柳州一男子因纠纷杀害三人后自首
- 洱海坠机4名机组人员被批准为烈士 数千干部群众悼念
家电
世界即时看!10Wqps评论中台,如何架构?B站是这么做的!!!
文章持续更新,建议收藏起来,慢慢读!疯狂创客圈总目录 博客园版为您奉上珍贵的学习资源 :
免费赠送 :《尼恩Java面试宝典》持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备免费赠送 经典图书:《Java高并发核心编程(卷1)加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领免费赠送 经典图书:《Java高并发核心编程(卷2)加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领免费赠送 经典图书:《Java高并发核心编程(卷3)加强版》面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 资源宝库: Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取
(资料图片)
说在前面
在尼恩的(50+)读者社群中,经常遇到一个 非常、非常高频的一个面试题,但是很不好回答,类似如下:
- 千万级数据,如何做系统架构?
- 亿级数据,如何做系统架构?
- 千万级流量,如何做系统架构?
- 亿级流量,如何做系统架构?
- 高并发系统,如何架构?
最近有个尼恩的社群中,有小伙伴阿里三面又遇到了这个问题。
其实,尼恩一直想梳理一个教科书式的答案,
咱们一直心心念念的 “千万级数据,如何做性能优化?” 的教科书式的答案,其实就藏着在这个行业案例里边。
前几天,尼恩结合B站的点赞系统,写过一个 教科书式的答案:
1000亿数据、30W级qps如何架构?来一个天花板案例
这里,再结合一个新的行业案例《B站评论系统架构设计》,尼恩从 面试维度,对这个方案,进行二次重构和梳理,现在写一个 教科书式的答案,并收入咱们的《尼恩Java面试宝典 PDF》 V58版本
统一都做了解答,这些答案,都可以给后面的小伙伴参考,大家一定好好看看这些教科书级别的答案。
本文原始方案的作者,是黄振,是哔哩哔哩资深开发工程师。
此文的原始文章请参见b站的公众号, pdf版收藏在尼恩的3高行业案例集合中,也可以找尼恩获取。
本文的架构方案,是尼恩在作者的B站方案的二次创作,是结合自己的3高架构笔记,以及尼恩的3高架构知识体系(3高架构宇宙)做的二次分析。
文章中,加入了社群小伙伴遇到的最新面试题: redis 集群如何做同城双活?
参考答案,见下文。
注:本文以 PDF 持续更新,最新尼恩 架构笔记、面试题 的PDF文件,请从这里获取:码云
评论系统的业务分析
在B站,UP主每天都会发布海量的视频、动态、专栏等内容,随之而来的是弹幕和评论区的各种讨论。
播放器中直接滚动播放的弹幕,如同调味剂,重在提升视频观看体验;
而点进评论区,相对而言评论文本更长,内容的观点、形式都更丰富,更像是饭后甜点。
随着业务不断发展,B站的评论系统逐渐组件化、平台化;
通过持续演进架构设计,管理不断上升的系统复杂度,从而更好地满足各类用户的需求。
评论的基础功能模块是相对稳定的。
发布评论:支持无限盖楼回复。
读取评论:按照时间、热度排序;显示评论数、楼中楼等。
删除评论:用户删除、UP主删除等。
评论互动:点赞、点踩、举报等。
管理评论:置顶、精选、后台运营管理(搜索、删除、审核等)。
结合B站以及其他互联网平台的评论产品特点,评论一般还包括一些更高阶的基础功能:
评论富文本展示:例如表情、@、分享链接、广告等。
评论标签:例如UP主点赞、UP主回复、好友点赞等。
评论装扮:一般用于凸显发评人的身份等。
热评管理:结合AI和人工,为用户营造更好的评论区氛围。
总体的架构设计
评论系统 中台,从总体的架构上来区分,分为:
(1)接入层
(2)服务层
(3)异步任务层
(4)cache层
(5)DB层
接入层架构 reply-interface
reply-interface是评论系统的接入层,主要服务于两种调用者:
一是客户端的评论组件,
二是基于评论系统做二次开发或存在业务关联的其他业务后端。
面向移动端/WEB场景,设计一套基于视图模型的API,利用客户端提供的布局能力,接入层负责组织业务数据模型,并转换为视图模型,编排后下发给客户端。
面向服务端场景,接入层设计的API需要体现清晰的系统边界,最小可用原则对外提供数据,同时做好安全校验和流量控制。
接入层整个业务数据模型组装,分为两个步骤:
一是服务编排,
二是数据组装。
服务编排拆的架构为:
(1)对服务进行分层,分为若干个层级,
(2)前置依赖通过流水线调用,
(3)同一层级的可以并发调用,结构性提升了复杂调用场景下的接口性能下限;
(4)针对不同依赖服务所提供的SLA不同,设置不同的降级处理、超时控制和服务限流方案,保证少数弱依赖抖动甚至完全不可用情况下评论服务可用。
SLA一般指服务级别协议。 服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
服务层架构
评论管理服务层reply-admin
评论管理服务层,为多个内部管理后台提供服务。
运营人员的数据查询具有:
组合、关联查询条件复杂;
刚需关键词检索能力;
写后读的可靠性与实时性要求高等特征。
此类查询需求,ES几乎是不二选择。
但是由于业务数据量较大,需要为多个不同的查询场景建立多种索引分片,且数据更新实时性不高。
因此,我们基于ES做了一层封装,提供统一化的数据检索能力,并结合在线数据库刷新部分实时性要求较高的字段。
评论基础服务 reply-service 架构设计
评论基础服务层,专注于评论功能的原子功能,例如:
- 查询评论列表
- 删除评论等。
这一层的特点是:
- 较少做业务逻辑变更的,
- 极高的可用性
- 极高性能吞吐。
这一层采用了多种高性能方案:
- 多级缓存
- 布隆过滤器
- 热点探测等。
尼恩提示:
多级缓存、布隆过滤器、热点探测等理论和实操非常重要,
很多的高并发应用,都要用到这些理论知识和实操知识,大家一定 要掌握,
具体可以参见尼恩的3高架构知识笔记。
异步任务层reply-job 架构设计
异步任务层,主要有两个职责:
- 为原子的业务操作操作,提供异步协助
与reply-service协同,为评论基础功能的原子化实现做架构上的补充。
- 异步削峰处理
为 长耗时/高吞吐的调用, 做异步化/削峰处理
职责1:提供异步协助
为原子的业务操作操作,提供异步协助, 最典型的案例就是缓存的更新。
一般采用Cache Aside模式,先读缓存,再读DB;
Cache Aside模式下的缓存的重建策略:就是读请求未命中缓存穿透到DB,从DB读取到内容之后反写缓存。
这一套流程对外提供了一个原子化的数据读取功能。
但由于部分缓存数据项的重建代价较高,比如评论列表。
为啥呢?
由于列表是分页的,缓存重建时会启用预加载,也就是要多加载几页,
如果短时间内大量请求缓存未命中,并且多个服务节点的同时重建缓存,容易造成DB抖动。
解决方案是啥?
利用消息队列+reply-job ,实现单个评论列表异步重建,只重建一次缓存。
另外呢,reply-job还作为数据库binlog的消费者,执行缓存的更新操作。
职责2:异步削峰处理
与reply-interface协同,为 长耗时/高吞吐的调用,做异步化/削峰处理
诸如评论发布等操作,基于安全/策略考量,会有非常重的前置调用逻辑。
对于用户来说,这个长耗时几乎是不可接受的。同时,时事热点容易造成发评论的瞬间峰值流量。
因此,reply-interface在处理完一些必要校验逻辑之后,会通过消息队列送至reply-job异步处理,包括送审、写DB、发通知等。
那么异步处理后用户体验是如何保证的呢?
首先是当次交互,返回最新数据。
C端的发评接口会返回展示新评论所需的数据内容,客户端据此展示新评论,完成一次用户交互。
其次,控制延迟时长,如果太长则进行预警和调优
若用户重新刷新页面,因为发评的异步处理端到端延迟基本在2s以内,此时所有数据已准备好,不会影响用户体验。
消息队列的保证有序
利用了消息队列的「有序」特性,将单个评论区内的发评串行处理,避免了并行处理导致的一些数据错乱风险。
一个有趣的问题是,早年间评论显示楼层号,楼层号实际是计数器,且在一个评论区范围内不能出现重复。
因此,这个楼层发号操作必须是在一个评论区范围内串行的(或者用更复杂的锁实现),否则两条同时发布的评论,获取的楼层号就是重复的。
而分布式部署+负载均衡的网关,处理发评论请求是无法实现这种串行的,因此需要放到消息队列中处理。
数据存储架构
结构化模型设计
结合评论的产品功能要求,评论需要至少两张表:
(1)首先是评论表,主键是评论id,关键索引是评论区id;
(2)其次是评论区表,主键是评论区id,平台化之后增加一个评论区type字段,与评论区id组成一个”联合主键“。
(3)评论内容表. 由于评论内容是大字段,且相对独立、很少修改,因此独立设计第3张表。主键也是评论id。
评论表和评论区表的字段主要包括4种:
关系类,包括发布人、父评论等,这些关系型数据是发布时已经确定的,基本不会修改。
计数类,包括总评论数、根评论数、子评论数等,一般会在有评论发布或者删除时修改。
状态类,包括评论/评论区状态、评论/评论区属性等,评论/评论区状态是一个枚举值,描述的是正常、审核、删除等可见性状态;评论/评论区属性是一个整型的bitmap,可用于描述评论/评论区的一些关键属性,例如UP主点赞等。
其他,包括meta等,可用于存储一些关键的附属信息。
评论回复的树形关系,如下图所示:
以评论列表的访问为例,我们的查询SQL可能是(已简化):
查询评论区基础信息:SELECT * FROM subject WHERE obj_id=? AND obj_type=?
查询时间序一级评论列表:SELECT id FROM reply_index WHERE obj_id=? AND obj_type=? AND root=0 AND state=0 ORDER BY floor=? LIMIT 0,20
批量查询根评论基础信息:SELECT * FROM reply_index,reply_content WHERE rpid in (?,?,...)
并发查询楼中楼评论列表:SELECT id FROM reply_index WHERE obj_id=? AND obj_type=? AND root=? ORDER BY like_count LIMIT 0,3
批量查询楼中楼评论基础信息:SELECT * FROM reply_index,reply_content WHERE rpid in (?,?,...)
分库分表架构
评论系统对数据库的选型要求,有两个基本且重要的特征:
必须有事务;
必须容量大。
一开始,B站采用的是MySQL分表来满足这两个需求。MySQL分库分表数据量起来之后,原来的MySQL分表架构很快到达存储瓶颈。
尼恩提示:
mysql 不停服在线扩容实际非常复杂,很多公司选择停服切换, 估计B站为了不停服, 或者不愿意发生停服的风险, 选择了 专门的商用 分布式 TiDB, 毕竟这个是花了钱的。
于是从2020年起,我们逐步迁移到TiDB,从而具备了在线水平扩容能力。
高并发写入架构,TPS提升了10倍以上
面对10Wqps的并发写入超大规模吞吐量,做了如下优化:
方案一:内存聚合+ 批量写入评论区评论计数的更新,先做内存合并再更新,可以减少热点场景下的SQL执行条数;评论表的插入,改成批量写入。
tips: 这就是 尼恩3高架构知识宇宙当中,所讲的 队列缓存+批量写入的架构
具体,请去看 100Wqps 三级缓存组件实操
方案二:核心逻辑和非核心异步化,为核心操作瘦身
非数据库写操作的其他业务逻辑,拆分为前置和后置两部分,
其他业务逻辑从数据写入主线程中剥离,交由其他的线程池并发执行。
总之,采用新的高并发写入架构之后,性能得到极大提升。
写入架构调整之后,系统的并发处理能力有了极大提升,同时支持配置并行度/聚合粒度,在吞吐方面具备更大的弹性,热点评论区发评论的TPS提升了10倍以上。
缓存层架构
数据的缓存模型架构
主要有3项缓存:
subject,对应于「查询评论区基础信息」,
redis string类型,value使用JSON序列化方式存入。
reply_index,对应于「查询xxx评论列表」,
redis sorted set类型。
member是评论id,score对应于ORDER BY的字段,如floor、like_count等。
reply_content,对应于「查询xxx评论基础信息」
存储内容包括同一个评论id对应的reply_index和reply_content表的两部分字段。
缓存的一致性架构
缓存的一致性依赖binlog刷新,主要两个要点:
- 消息队列,保证 同一个评论区内有序
binlog投递到消息队列,分片key选择的是评论区,保证单个评论区和单个评论的更新操作是串行的,消费者顺序执行,保证对同一个member的zadd和zrem操作不会顺序错乱。
- 采用删除缓存而非直接更新的方式
程序主动写缓存和binlog刷缓存,都采用删除缓存而非直接更新的方式,避免并发写操作时,特别是诸如binlog延迟、网络抖动等异常场景下的数据错乱。
缓存击穿解决方案
那大量写操作后读操作缓存命中率低的问题如何解决呢?
读缓存的时候, 可以利用 锁的机制,进行同步控制,防止缓存击穿。
具体方案,请参见尼恩的3高架构笔记中,redis 高可用实操的章节
热点探测架构
除了写热点,评论的读热点也有一些典型的特征:
- 由于大量接口都需要读取评论区基础信息,存在读放大,因此该操作是最先感知到读热点存在的。
- 由于评论业务的下游依赖较多,且多是批量查询,对下游来说也是读放大。此外,很多依赖是体量相对小的业务单元,数据稀疏,难以承载评论的大流量。
- 评论的读热点集中在评论列表的第一页,以及热评的热评。
- 评论列表的业务数据模型也包含部分个性化信息。
在读取评论区基础信息阶段探测热点,并将热点标识传递至服务层;
服务层实现了页面请求级的热点本地缓存,感知到热点后即读取本地缓存,然后再加载个性化信息。
热点探测的实现基于单机的滑动窗口+LFU,那么如何定义、计算相应的热点条件阈值呢?
首先,我们进行系统容量设计,列出容量计算的数学公式,主要包括各接口QPS的关系、服务集群总QPS与节点数的关系、接口QPS与CPU/网络吞吐的关系等;
然后,收集系统内部以及相应依赖方的一些的热点相关统计信息,通过公式,计算出探测数据项的单机QPS热点阈值。
最后通过热点压测,来验证相应的热点配置与代码实现是符合预期的。
高可用架构
包括:
(1)缓存降级与DB降级
(2)同城读双活 + 双机房独立部署 架构
(3)副本数据延迟优化架构
(4)限流熔断策略的优化
缓存降级与DB降级
基础服务层集成了多级缓存,在上一级缓存未命中或者出现网络错误后,降级至下一级缓存,
缓存没有命中,就降级到DB,保证系统的的可用性。
同城读双活 + 双机房独立部署 架构
评论系统是一个同城读双活+ 双机房独立部署 的架构。
DB 和 redis 均支持多副本,具备水平扩容的弹性。
双机房独立部署 :
数据库与缓存均是双机房独立部署的,通过 db-proxy,或者 db-redis进行访问
副本数据延迟优化架构
双机房架构场景下,存在跨机房数据延迟问题,
采用如下的策略解决:
- 入口层切流
- 应用层补偿
- 跨机房重试
尽可能保证极端情况下, 用户没有延迟感。
限流熔断策略的优化
为了尽可能 保证系统可用, 在功能层面,做了级别划分:
把依赖划分为强依赖(如审核)、弱依赖(如粉丝勋章)。
首先,在如果强依赖出现异常,下坚决限流熔断,尽可能 保证 强依赖的可用性。
另外,对于弱依赖,通过超时控制、请求预过滤、优化调用编排, 持续优化提升非核心功能的可用性,
重点:Redis 的双机房部署方案
tips:在写这个文章的过程中,尼恩的疯狂创客圈社群中,有小伙伴说他刚刚面试遇到了一道难题:
双机房部署redis该怎么做 ?
顺着这个文章,尼恩 给大家 把双机房部署redis 方案说一下。
采用 redis-cluster-proxy + redis cluster的架构方案。
redis cluster是redis的官方集群方案,但是他要求客户端自己做重定向,
redis-cluster-proxy 是redis的官方集群代理,经过这个proxy的代理后,连接redis集群就和连接单机redis一样了。
proxy+cluster架构
proxy+cluster架构图如下:
架构说明:
1、redis-cluster采用了同城双活架构,
其中,图中的AZ1和AZ2表示为可用区1、可用区2,
主节点(AZ1)按3主3从部署,备节点(AZ2)作为Cluster的6从,整个集群为3主9从;
2、单个master节点发生故障,redis集群自动感知并进行选主,完成主从切换,不影响业务正常使用;
3、应用服务连接所有Redis集群主从节点,以便自动感知主从切换情况。
其实只要连接到redis-proxy一个节点,应用服务便可以获取到集群信息,某些节点宕机后,客户端不会收到影响。
注意:单AZ1池资源出现问题,可以使用已准备好的脚本进行快速切换AZ2节点,完成集群恢复。
当然,上面的方案,可以考虑把master节点打散到两个AZ,避免集群超半数master节点宕机;
proxy+cluster架构问题
redis-proxy模式采用官方的redis-proxy+cluster模式,优点就是应用只需要连接proxy节点即可,不需要配置更多的node节点,生产环境proxy需要考虑高可用,而proxy也可以考虑用lvs+keepalived作为代理取代,
自动切换脚本
先使用cluster failover force
命令执行强制切库,如果试了3次都不行,就使用cluster failover takeover
更强制的切库,
手动故障转移是一种特殊的故障转移,通常在没有实际故障的情况下执行,我们希望将当前主节点与其中一个slave从节点(我们发送该命令的节点)交换(安全地,而不会有数据丢失的窗口)。
- 当前slave从节点通知主节点停止处理客户端的请求。
- 主节点回复slave从节点当前的 同步偏移量。
- slave从节点等待同步偏移量在slave从节点的侧匹配,以确保它已经处理了所有主节点的数据,然后继续。
- slave从节点开始故障转移,从主节点的大多数主节点获取新的配置纪元值epoch,并广播新的配置。
- 旧的主节点接收配置更新:解除对客户端访问的阻止,并开始回复重定向消息,以便它们继续与新的主节点通信。
两个选项:
FORCE option: manual failover when the master is down 当主节点停止时手动故障转移
如果选择FORCE选项,slave从节点不会与master主节点进行协商(master节点可能不可达),而是直接尽快从上文的故障转移步骤中的第4步开始做故障转移。当主节点不可达时,FORCE选项对于我们做手动故障转移非常有用。
TAKEOVER option: manual failover without cluster consensus 在集群数据不一致的场景下,也要人工故障转移
TACKOVER选项实现了FORCE选项的所有实现,但是无需集群一致性验证来进行故障转移。
如果需要故障转移,在从节点上,可以输入以下命令
redis-cli -p 7001 -c CLUSTER FAILOVER
也可以结合linux上的定时器,使用脚本,配合使用
(1)探活脚本:redis_check.sh
(2)切换脚本:redis_task.sh
redis_check.sh脚本为检测redis节点是否存活
#!/bin/bash LOGDIR="/root"BINDIR="/data/redis/7001/bin/redis-cli"PASSWD="123456"IPDIR="172.16.0.8:7001 172.16.0.8:7002 172.16.0.8:7003 172.16.0.8:7004 172.16.0.8:7005 172.16.0.8:7006" DATE=`date`LOGFILE=${LOGDIR}/logsERROR_LOG=${LOGDIR}/error.logs cd ${LOGDIR}if [ ! -d bak ] ; then mkdir -p bakfi for i in $IPDIRdo port=${i#*:} ip=${i%:*} ALIVE=`$BINDIR -h $ip -p $port PING` #ALIVE=`$BINDIR -h $ip -p $port -a $PASSWD PING` if [ "$ALIVE" == "PONG" ]; then echo "${DATE} Success: redis-cli -h $ip -p $port PING $ALIVE" >> $LOGFILE 2>&1 else echo "${DATE} Failed:redis-cli -h $ip -p $port PING $ALIVE " >> $ERROR_LOG 2>&1 fi done
redis_task.sh为AZ1节点宕机后,执行脚本切换到AZ2节点
#!/bin/bash IPMASTER="172.16.0.8:7001 172.16.0.8:7002 172.16.0.8:7003"BINDIR="/data/redis/7001/bin/redis-cli"PASSWD="123456"DATE=`date`LOGDIR="/root"LOGFILE=${LOGDIR}/logsERROR_LOG=${LOGDIR}/error.logs for i in $IPMASTERdo port=${i#*:} ip=${i%:*} status=`$BINDIR -h $ip -p $port -c cluster failover takeover` #status=` $BINDIR -h $ip -p $port -a $PASSWD -c cluster failover takeover` if [ "$status" == "OK" ]; then echo "${DATE} Success: $i 成功切换成master节点" >> $LOGFILE 2>&1 else echo "${DATE} Failed: $i 切换master节点失败 " >> $ERROR_LOG 2>&1 fi done
机房故障的redis 故障转移过程
最开始cluster搭建方式如下图所示
在AZ1机房全部宕机后,我们需要通过执行cluster failover takeover命令将AZ2机房切换为Master,如下图所示:
在AZ1机房恢复正常之后,如下图所示:
安全性架构
一、数据安全
满足数据安全法要求,除了数据安全法所要求的以外,评论系统的数据安全还包括「合规性要求」。
评论数据合规,一方面是审核和风控,另一方面对工程侧的要求主要是「状态一致性」。
例如,有害评论被删除后,在客户端不能展现,也不能通过API等对外暴露。
这就对数据一致性,包括缓存,提出了较高要求。
在设计层面主要有两方面实践:
数据读写阶段均考虑了一致性风险,严格保证时序性。
对各类数据写操作,定义了优先级,避免高优先级操作被低优先级操作覆盖,例如审核删除的有害评论,不能被其他普通运营人员/自动化策略放出。
通过冗余校验,避免风险数据外泄。
例如评论列表的露出,读取sorted set中的id列表后,还需要校验对应评论的状态,是可见态才允许下发。
二、舆论安全
舆论安全问题更为泛化。
接口错误导致用户操作失败、关闭评论区、评论计数不准,甚至新功能上线、用户不满意的评论被顶到热评前排等问题均可能引发舆情问题。
在系统设计层面,我们主要通过几方面规避。
不对用户暴露用户无法处理和不值得处理的错误。
例如评论点赞点踩、某个数据项读取失败这一类的轻量级操作,不值得用户重试,此时告知用户操作失败也没有意义。系统可以考虑自行重试,甚至直接忽略。
优化产品功能及其技术实现,例如评论计数、热评排序等。
热评设计架构
什么是热评
早期的热评,实际就是按照评论点赞数降序。
后来衍生了更为复杂的热评:
既包括类似「妙评」这种用户推荐、运营精选且带logo突出展示的产品形态,
也包括各类热评排序算法,且热评排序算法应用场景也不仅局限于评论主列表的热度序,
还包括楼中楼(外露子评论)、动态外露评论等。
热评排序逻辑一般包括点赞数、回复数、内容相关、负反馈数、“时间衰退因子”、字数加权、用户等级加权等等。
咬文嚼字来说,我们对「热」的理解,大致分为几个阶段:
- 阶段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来支撑热评列表的读写。
Reddit最早成立于2005年,两名创始人是史蒂夫·霍夫曼和阿里克西斯·奥哈尼安,当时他们刚刚从弗吉尼亚大学毕业。他们的创业想法获得了美国知名创业孵化器Y Combinator的天使投资。
Reddit在美国的影响力非常大,它的信息展示形式像论坛,又像贴吧。是由不同版块下的帖子组成的交流平台,用户可以选择对帖子点击“上涨”或“下沉”来决定帖子的排名顺序。
Reddit在2009年公开过自己如何用威尔逊区间(wilson interval)对评论排序的,代码也开源过。
Wilson算法要点有两个:
把“所有正负反馈中正反馈的比例”作为对评论质量的考核指标。
在Reddit的情况中,正负反馈分别为点赞和反对。
简单来说,就是 正为点赞, 负为反对
对在冷启动过程中的评论(即正负反馈总数很少)做降权处理。
具体算法就是:假设观测到的正反馈率符合真实正反馈率的正态分布,求当前观测得到的正反馈率恰好位于95%置信上区间时的真实反馈率。
阶段3:按照点赞率排序
按照点赞率排序,需要实现点赞率的近实时计算。
点赞率=点赞数/曝光数,曝光的数据来源是客户端上报的展现日志,量级非常大,
可以说是一个写多读少的场景:只有重算排序的时候才会读取曝光数。
阶段4 :追求用户价值平衡
追求用户价值平衡,需要处理各种细分场景下的差异化需求。
热评排序与feed排序很像,但也有一点根本性差异:
feed排序是个性化的,每个人看到的都不相同,
但评论排序往往不会如此激进,一般来说会希望大家看到的评论排序都大致相同。
由于排序问题的解决方案是探索型的,因此系统设计层面需要提供更多元、更易扩展的工程化能力,
包括算法和策略的快速迭代、实验能力等,
并提升整个热评模块的可观测水平,监控完善、数据报表丰富、排序过程可解释等等。
在架构上,新增了strategy-service和strategy-job来承担这部分策略探索型业务。
此外,数据量级规模的增加,也对系统的吞吐能力提出了更高要求:
不管热评的算法如何变化,一般来说,热评列表都需要能够访问到全部评论,且基本维持相同的热评排序逻辑。
在评论数过百万甚至千万的评论区,热评排序的挑战点主要在于:
大key问题:
例如单个sorted set过大,读写性能都受影响(时间复杂度的基数可以认为都是O(logN));全量更新时,还可能遇到redis pipeline的瓶颈。
实时性放大存储压力:
多样化的数据源,对特征的导入与更新都提出了挑战,需要支持较丰富的数据结构,和尽可能高的写吞吐(想象一下曝光数作为排序特征的变态要求);
与推荐排序不同,热评排序是全排序,此时需要读取全部评论的全部特征,查询压力也会非常大。
这一阶段,我们仍然在持续优化,在工程落地层面尽可能还原理想的排序算法设计,保障用户的热评浏览体验。目前形成的系统架构总体如下图所示:
图示的「评论策略层」,负责建立一套热评调控体系化能力,通过召回机制来实现想要的“balance“。
即先通过策略工程,召回一批应该沉底的不良评论或者应该进前排的优秀评论,然后在排序分计算阶段根据召回结果实现这样的效果。
这样做的好处是,可以保留一套通用的底层排序算法,然后通过迭代细分场景下的召回策略,来实现差异化评论排序的平衡。
召回策略的工程设计,按照分层设计的原则拆分为3个部分:
因子机。
主要职责是维护策略所需的全部「因子」,包括一些已有的在线/离线数据,也包括为了策略迭代而需要新开发的流式的窗口聚合数据。
因子机的重难点是需要管理各种数据获取的拓扑关系,以及通过缓存来保护下游(数据提供方很难也不应该承受热评业务的巨大流量)。
所有的因子可以构成一个有向无环图,通过梳理依赖关系和推导计算,实现并发提效、减少冗余。
规则机。
实现了一套声明式规则语法,可以直接引用因子机预定义的因子,结合各种逻辑算子构成一个规则表达式。
规则机执行命中后,会向下游传递预先声明的召回决策,例如排序提权。
召回处理中心。
这一层的职责就是接收规则机返回的各种决策并执行,需要处理不同决策的优先级PK、不同规则的决策叠加作用、决策豁免等。
热评排序涉及的特征,是多数据源的,数据更新方式、更新频率、查询性能也天差万别。
因此我们针对数据源的特点做了多级缓存,通过多级冗余与跨级合并,提升了特征读取的稳定性与性能上限。
当然,其中的数据实时性、一致性、可用性,仍然处于一个动态权衡取舍的过程。
结合 B站的方案,大家回到前面的面试题:
- 千万级数据,如何做系统架构?
- 亿级数据,如何做做系统架构?
- 千万级流量,如何做系统架构?
- 亿级流量,如何做做系统架构?
- 高并发系统,如何架构?
以上的方案,才是完美的答案,才是“教科书式” 答案。
后续尼恩会给大家结合行业案例,分析出更多,更加劲爆的答案。
当然,如果大家遇到这类高并发的面试难题,可以找尼恩求助。
参考资料:
B站原文
https://www.bilibili.com/read/cv20346888
redis 集群异地双活参考
https://blog.csdn.net/u012171444/article/details/127525169
推荐阅读:
《响应式圣经:10W字,实现Spring响应式编程自由》
《Linux命令大全:2W多字,一次实现Linux自由》
《阿里一面:谈一下你对DDD的理解?2W字,帮你实现DDD自由》
《网络三张表:ARP表, MAC表, 路由表,实现你的网络自由!!》
《1000亿数据、30W级qps如何架构?来一个天花板案例》
《干翻 nio ,王炸 io_uring 来了 !!(图解+史上最全)》
《SpringCloud+Dubbo3 = 王炸 !》
《4次迭代,让我的 Client 优化 100倍!泄漏一个 人人可用的极品方案!》
《全链路异步,让你的 SpringCloud 性能优化10倍+》
《阿里一面:你做过哪些代码优化?来一个人人可以用的极品案例》
《网易二面:CPU狂飙900%,该怎么处理?》
《阿里二面:千万级、亿级数据,如何性能优化? 教科书级 答案来了》
《峰值21WQps、亿级DAU,小游戏《羊了个羊》是怎么架构的?》
《场景题:假设10W人突访,你的系统如何做到不 雪崩?》
《2个大厂 100亿级 超大流量 红包 架构方案》
《Nginx面试题(史上最全 + 持续更新)》
《K8S面试题(史上最全 + 持续更新)》
《操作系统面试题(史上最全、持续更新)》
《Docker面试题(史上最全 + 持续更新)》
《Springcloud gateway 底层原理、核心实战 (史上最全)》
《Flux、Mono、Reactor 实战(史上最全)》
《sentinel (史上最全)》
《Nacos (史上最全)》
《分库分表 Sharding-JDBC 底层原理、核心实战(史上最全)》
《clickhouse 超底层原理 + 高可用实操 (史上最全)》
《nacos高可用(图解+秒懂+史上最全)》
《队列之王: Disruptor 原理、架构、源码 一文穿透》
《环形队列、 条带环形队列 Striped-RingBuffer (史上最全)》
《一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系(史上最全)》
《红黑树( 图解 + 秒懂 + 史上最全)》
《分布式事务 (秒懂)》
《缓存之王:Caffeine 源码、架构、原理(史上最全,10W字 超级长文)》
《缓存之王:Caffeine 的使用(史上最全)》
《Docker原理(图解+秒懂+史上最全)》
《Redis分布式锁(图解 - 秒懂 - 史上最全)》
《Zookeeper 分布式锁 - 图解 - 秒懂》
《Netty 粘包 拆包 | 史上最全解读》
《Netty 100万级高并发服务器配置》
关键词:
世界即时看!10Wqps评论中台,如何架构?B站是这么做的!!!
简讯:前端设计模式——中介者模式
全球今日报丨Typora语法
Linux 中如何开启端口
环球微资讯!多地或迎来30℃的“春天”:今夏是否会遭遇极端高温?专家回应
每日热讯!宜家储物柜竟成网红打卡地 上海宜家禁止在仓库拍照
每日消息!农民工大哥火车上用盆炫10袋泡面 饭量让网友惊叹:干活能吃更多
环球观焦点:海尔为何能反超格力
天天快消息!微软坚信Switch可原生运行《使命召唤》:没有理由不能优化
环球快播:Kubernetes 的 HPA 原理详解
世界热资讯!当我把ChatGPT拉进群聊里,我的朋友都玩疯了
NTP校时服务器(时钟服务器)在安防监控系统里的重要性
天天新动态:以宿主机用户身份运行Docker容器
环球讯息:配置中心 | .NET 集成 Nacos 配置中心
3月9日生意社DBP基准价为9475.00元/吨
环球今头条!中核首席专家:人造太阳有望在30年后实现供能 核聚变商用
【天天报资讯】有你在的城市吗?中国“民富”50城:沪京苏杭位列前4 长三角仍是最富庶地区
0.536秒!清华学子拍到中国空间站凌月 画面震撼:网友为中国航天点赞
每日讯息!15年耗费万亿日元 日本国产飞机梦碎:原型机被拆解
【全球新视野】夫妻200万造别墅找陌生人抱团养老 每月1500元 网友并不看好
世界观天下!湖北现购车狂潮 东风系最高降9万遭疯抢 乘联会:其他省份或效仿
全球播报:专家权威点评比亚迪CTB技术:刀片与车身完美结合 只能在比亚迪才能实现
天天亮点!促销潮蔓延 汽车全面降价已来临?比亚迪或是最大功臣!
前沿资讯!怎么做才能不丢消息?
世界快看:读Java性能权威指南(第2版)笔记11_堆内存上
当前时讯:新生儿史低 日本恐将不复存在:工业正在崩溃边缘
每日消息!湖北现购车狂潮:最高发9万元补贴 12万买合资B级车
云计算的历史演进
狗屁不通文章生成器在线网页版 (2023年最新)
当前时讯:1万元!TP-Link发布Wi-Fi 7挖矿路由器:比RTX 4090快得多
世界今热点:2岁娃总发烧咳嗽 一查肺里有个洞:8个月前嗑南瓜子 壳进入肺部
非洲部落活人献祭的食人树:真的存在吗?
热文:有人在《绝地求生》里把炸弹扔了2000米远!还没开挂
世界热门:《星空》确定延期至9月6日发售 直面会6月11日举行
四川雅安旅游景点 四川雅安有哪些好玩的地方
盐山县聚成管道防腐保温厂
青岛西海岸新区2023年第一批产权型人才住房项目配售条件
【世界新视野】认养大熊猫1年10万终身100万:成龙认养了2只
岚图CEO讽刺路虎汽车抄袭:我们鼓励原创
世界焦点!类魂游戏《卧龙:苍天陨落》10场最难BOSS战:吕布让玩家绝望
环球消息!0.vim常用命令
【C++】购书系统问题测试&功能补充
环球热门:Celery框架的基本使用与介绍
班主任请全班女生喝奶茶:高考前还要请学生吃寓意为“高中”粽子
当前资讯!空乘招聘排队7小时面试3分钟 空姐空少挤满现场:有航空公司给年薪33万
通用表表达式
【全球独家】关于docker镜像IMAGE的备份和还原操作
【世界新要闻】七彩虹进军元宇宙!推出首款免费NFT、神秘实体权益
每日简讯:14.5英寸杜比视界大屏!联想拯救者Y900屏幕参数公布
张颂文回应沙漠捡垃圾被剧组丢下:临时租车司机行为
【独家焦点】三星Galaxy Tab S9系列平板曝光:Ultra机型首上IP67防尘防水
天天通讯!女足U20国青6-0横扫菲律宾,一场大胜,往往只需要简单的战术
世界即时看!匈牙利舞曲第五号_匈牙利舞曲
2月汽车销量前8名油车仅剩2个 比亚迪宋力压特斯拉Model Y
每日速递:1100万元的捐赠没给 中国矿业大学起诉90后校友
东北大熊猫着急下班 哐哐敲铁门:网友心酸想起在美丫丫 蜂花将认养?
世界观点:民族品牌蜂花将认养大熊猫丫丫 官方回应属实:加快与美国办理手续
Android 14首个公测版要来!Google I/O 2023定档5月10日
全球速讯:内网穿透的高性能的反向代理应用FRP-自定义404错误页【实践可行版】
明解Redis(一)概述
环球要闻:AMD狂堆缓存!锐龙9 7950X3D游戏性能遥遥领先
天天最新:核聚变之后 美国团队宣布突破常温超导技术:颠覆物理学
天天快看点丨国内手游一哥出海!腾讯《王者荣耀》正式于巴西上线
【环球热闻】日本双胞胎姐妹身高相差75厘米 获吉尼斯纪录认证
提升国民平均寿命25岁?创维汽车:让每位车主实现基本百岁人生
全球微速讯:Node 非服务脚本调试
分享一个可以早点下班的开发小技巧
【环球报资讯】SpringBoot启动控制台的banner是怎么回事
环球新资讯:AppUploader教程:如何注册账号并激活AppUploader
全球快看点丨Android工程接入UnityLibrary工程
【聚看点】存储一哥扛不住了!三星在售最旗舰SSD 990 PRO降至史低价
天天速看:15万买特斯拉 那得多“毛坯”?成本降50%是文字游戏
原生PCIe 5.0更安全!酷冷至尊GX1250 GOLD电源评测:满载电压偏移<0.1%
环球今热点:不再烧主板!ROG 2023系列内置环境光传感器:见光自动断电
索尼PS中国发文祝4位游戏女角节日快乐:蒂法、希里等出镜
全球微头条丨潍坊市寒亭区举行庆“三八”专场招聘会
k8s-安全机制
Docker全家桶入门到进阶教程,Docker快速上手
焦点滚动:Docker入门到高级教程(一)Docker 的用途
当前热议!卡车
前沿热点:小心上当 国外免费软件被不良人士玩坏:收费299
环球消息!比亚迪开通苹果NFC数字车钥匙功能 两款车型已支持
魅族换新Logo了!魅族20系列官宣定档3月30日
每日速讯:未获版号就擅自出版网络游戏 重庆一公司被罚45万元
在鸡面前画条直线为何它呆住不动 科普:只是在装死
每日报道:qiankun 的使用
当前热议!Linux常用的20个命令(下)
【天天播资讯】Linux网卡驱动程序
讯息:(数据库系统概论|王珊)第十一章并发控制-第一节:并发控制概述
【环球速看料】如何轻松学习网页设计和网页编程?
当猛男遇上脱毛仪:用前抗拒、用后真香
终身质保成笑话?女车主购入威马新车三年维保无配件
Win11不支持拖动任务栏 强行修改注册表后:画面尴尬了
快播:爱吃辣的人不容易得糖尿病?是真的吗?
天天观焦点:你的护照又升值了!我国与马尔代夫互免签生效 浏览量暴增200%
环球时讯:凌云B股(900957)3月8日主力资金净卖出558.00元
全球观察:跨境电商卖家如何应对拒付、盗卡
热推荐:前端设计模式——观察者模式
热消息:代码审计之旅之百家CMS
环球头条:Paxos算法理解与java实现