微博评论的高性能高可用计算架构方案
(一) 计算性能说明
用户量预估
根据微博发布的 2022 年一季度财报,日活跃用户达到 2.52 亿用户。即用户的基数为 2.52 亿
行为建模
用户发布评论微博信息,大部分是针对于明星或者新闻信息,预计每一条微博,平均大约 10 人会有 1 人发布评论左右。用户每天查看评论频率会比用户看微博的频率低,即每天查看评论大约 10 人会有 2 人次左右。
性能估算
发布评论: 2.52 亿 * 60% /(4 * 3600)* 0.1 * 0.8 = 800/S
查看评论: 2.52 亿 * 60% /(4 * 3600)* 0.2 * 0.8= 1.6K/S
注: 80%的评论发生在发布微博之后产生的。
(二) 分析
功能分析
对于用户发布的评论,对于时效性要求并不高,可以缓存存储和负载均衡策率。
对于用户查看评论,可以通过本地缓存以及 CDN 等缓存手段和负载均衡策率。
对于用户来说发布和查看评论在同一页【同一场景触发】,因此将两个功能合并成一个应用服务,不再进行拆分。
负载架构建议
用户的数量较大,应该使用多级负载均衡架构,主要为 DNS -> F5 -> Nginx ->网关的多级负载均衡架构。
缓存架构建议
用户的评论数据的时效性要求不高,无论是发布评论还是查看评论均可以采用缓存临时存储处理。
(三)设计
负载均衡算法选择
微博通过分布式共享缓存进行存储个人账户的基础信息,用户评论数据可以随意负载到任何一台服务器上,负载均衡的算法可以选择随机和轮询模式。
业务服务器数量估算
微博评论服务采用微服务多机部署的模式,其处理过程包含 内容审核、写入缓存、数据入库,因此预估每台服务器能每秒处理 1K/s,根据预算分析的性能指标为 800/S[发布评论]、1.6K/S[查看评论], 因此预估要用 18 台服务器[有一定的冗余]。
(四)高性能架构设计说明
负载架构设计如下:
微博用户大部分是通过手机 App[微博],建立 HttpDNS 服务端[也是集群话部署模式]用于应用的高效负载。
建立四层负载均衡结构,分别为 DNS(HttpDNS)层、硬件负载层(F5/A10)、软件负载层(Nginx)、应用网关负载层。
发布评论和查看评论负载架构图
多级缓存设计架构设计架构如下:
通过本地缓存保留部分原有的浏览信息[评论是按照时间排序的],其中评论的内容可以在应用服务到的进程内缓存进行存储【业务的时效性较低】。
(五)高可用架构设计说明
热点事件分析:
评论:热点事件发生后,绝大部分请求都落在了导致热点事件发生的那一条微博上面。会在此微博内容下会有大量的评论。
技术架构分析:
对于写评论本身已经采用缓存处理机制,对于出现热点问题应该不会有特殊的表现。对于看评论,可以将评论数据以 zset 数据结构存储在 redis 中,在每一个副本中进行存储,这样应用在读取的时候可以提供高可用。之后应用定期更新 zset 中的数据。
评论