当前位置：网站首页>架构实战营模块五作业

架构实战营模块五作业

2022-06-29 15:33:00 【InfoQ】

评论微博计算性能预估

1. 用户量预估

2020.9月月活5.11亿，日活2.24亿（参考《微博2020用户发展报告》）。

2. 关键行为

写评论、回复他人评论、删除自己的评论

看评论

3. 性能预估

（1）写评论、回复他人评论、删除自己的评论

由于绝大部分微博用户看/评论微博的对象是大V和明星，因此我们假设看微博的用户有10%会进行评论，那么平均一条微博评论人数有10次，则评论微博的次数为：2.5亿 * 10 = 25亿。

大部分的人发微博集中在早上8：00~9：00点，中午12：00~13：00，晚上20：00~22：00，假设这几个时间段发微博总量占比为60%，大部分人评论微博的时间段和发微博的时间段基本重合，因此评论微博的平均 TPS 计算如下：25亿 * 60% / (4*3600) = 100K/s。

（2）看评论

由于绝大部分微博用户看微博评论的对象是大V和明星，因此我们假设平均一条微博观看人数有100次，评论与微博一同请求，则观看微博评论的次数为：2.5亿 * 100 = 250亿。

大部分人看微博评论的时间段和发微博的时间段基本重合，因此看微博评论的平均 QPS 计算如下：

250亿 * 60% / (4*3600) = 1000K/s。

4. 是否拆分独立的服务

写评论和看评论业务区别较大，比如写评论不能用缓存，看评论很依赖缓存。拆分为写评论服务和看评论服务。

非热点事件时的高性能计算架构

1. 写评论、回复他人评论、删除自己的评论

（1）业务特性分析

都是写操作，希望及时能看到，因此不能用缓存，可以用负载均衡。

（2）架构分析

请求量达到十亿级别，秒并发十万，要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

（3）架构设计

负载均衡算法选择

发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发评论的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理500来估算，完成100K/s的 TPS，需要200台服务器，加上一定的预留量，250台服务器差不多了。

2. 看评论

（1）业务特性分析

看评论是一个典型的读场景，由于评论发了后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

（2）架构分析

请求量达到百亿级别，秒并发百万，要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

（3）架构设计

负载均衡算法选择

游客都可以直接看微博评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

业务服务器数量估算

假设 CDN 能够承载90%的用户流量，那么剩下10%的读微博评论的请求进入系统，则请求 QPS 为1000K/s * 10% = 100K/s，由于读取微博评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是1000/s，则机器数量为100台，按照20%的预留量，最终机器数量为120台。