写点什么

微博系统中”微博评论“的高性能高可用计算架构

用户头像
唐江
关注
发布于: 2021 年 06 月 06 日

【作业要求】基于模块 5 第 6 课的微博实战案例,分析“微博评论”这个核心场景的业务特性,然后设计其高性能高可用计算架构,包括但不限于如下内容:

1)计算性能预估(不需要考虑存储性能)

2)非热点事件时的高性能计算架构,需要考虑是否要拆分独立的服务

3)热点事件时的高可用计算架构


计算性能预估


根据第 6 课的案例中的数据:日活:2.5 亿/人,我们假设如下:

高峰 4 小时:30%人发微博、60%人看微博、10%评论微博

其他时间段(10 小时): 30%发微博、60%人看微博、10%人评论微博


发微博的数量:

TPS:2.5 亿 * 30% / (4 * 3600) ≈ 5.5 K/s(高峰 4 小时)。

TPS:2.5 亿 * 30% / (10 * 3600) ≈ 2.1 K/s(其他 10 小时)。

评论微博的数量:

TPS:2.5 亿 * 10% / (4 * 3600) ≈ 1.8 K/s(高峰 4 小时)。

TPS:2.5 亿 * 10% / (10 * 3600) ≈ 700/s(其他 10 小时)。

总共一天评论微博的请求数量为:高峰 4 小时(2.5 亿 * 10%) + 其他 10 小时(2.5 亿 * 10%) ≈ 5 千万条


高性能计算架构


【业务特性分析】

评论微博不是核心业务。因此可以将评论请求缓冲起来或者限流

【架构分析】

高性能

非核心业务,评论处理不需要高性能。

高可用

非核心业务,可以容忍评论失败,因此不考虑高可用。

可扩展

评论微博主要是评论某条微博,业务基本已经明确,因此也不需要考虑可扩展。

成本

服务器、运维成本。本设计方案忽略该项。

安全

考虑评论的内容是否触犯法律法规,因此需要将内容和谐掉。本设计方案忽略该项。


总的来说,不需要高性能、高可用,但是用户量过亿,为了保证评论请求都能得到处理,即保证系统的吞吐量能做到过亿。所以要用多级负载均衡架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡。

【架构设计】


1、评论功能单独出一个服务,非主要的功能拆出来避免影响主要业务发展,如性能、查问题、维护等影响。

2、负载均衡算法选择 : 评论微博需要登录状态,同发微博一致保持在分布式缓存中,可以将请求发送到任意评论微博服务,选择轮询或随机算法。

3、缓存选择:发微博不需要实时处理,因此可以把评论内容缓存在客户端(手机 APP、单体页面),后端收到请求将数据缓存到消息中间件(降低服务器压力),最后处理消息。因此缓存设计包括客户端和后端消息中间件。

3、业务服务器数量估算: 评论微博涉及几个关键的处理: 消息存入中间件(kafka),内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统), 由于评论期间高峰是 4 小时,最多请求数量为 2.5 千万条,假设能接受 kafka 积压数据最多为 2G 存储(评论平均为 100 个汉字),即最多可以积压 1 千万条评论数据,又假设评论服务每秒可以处理 500 个请求,要完成 2.5 千万条的请求,,且不超过最多积压,需 3 台评论服务器就可以满足。


评论微博多级负载设计


缓存架构设计:



热点事件时的高可用计算架构

【业务特性分析】

点赞微博的业务逻辑基本等同于评论微博,点赞功能可能会暴涨,会导致服务器处理不过来。


【架构设计分析】

1. 点赞主要是带来请求量的增加,对于处理逻辑并不复杂,因此通过增加机器的数量就能应对该事件。

用户头像

唐江

关注

还未添加个人签名 2020.02.19 加入

还未添加个人简介

评论

发布
暂无评论
微博系统中”微博评论“的高性能高可用计算架构