架构实战营：模块五作业

数据估算

1. 2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)，故预计日发微博数为 2.5 亿；

2. 假设每条微博的评论是 10 个，所以每日新增评论是 25 亿；

3. 假设发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，发微博和发评论的时间重合，假设这几个时间段发评论总量占比为 60%，所以 4 小时为发微博平均 TPS：25 亿 x 60% / 4 / 3600 = 100k/s

4. 假设看微博和评论的时间段类似，且所看评论一般为前 5 条（前 5 条可以一次性加载），假设一条微博平均观看人数为 100，有兴趣点开查看评论的再减一半，也就是 50，所以 4 小时平均 TPS 为 25 亿 x 60% / 4 / 3600 * 100 / 2 = 5000k/s

机构设计：

用户量过亿，需要采用多级负载均衡架构，覆盖 DNS -> F5 -> NGINX -> 网关的多级负载。

1、负载算法选择

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

2、业务服务器数量估算

发评论按照一个服务器每秒 500 估算，完成 100k/s 的 TPS，需要 200 台服务器，加上一定量的冗余，250 台。

看评论的时候，假设 CDN 能承载百分之九十的流量，那么剩下的百分之十也就是 500K/s，假设单台服务器 TPS 为 1000/s，需要 500 台，按照百分之二十的预留量，看评论总需要 600 台服务器。

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

1、热点事件发生时尽量满足看的需求，转发和写评论可以限流，同时配合消息队列削峰。