1.1 用户量预估

2020 年 9 月微博月活用户 5.11 亿，日活 2.24 亿（数据参考《微博 2020 用户发展报告》）

1.2 用户行为建模

1. 发表微博评论

微博每天发送量约为 2.5 亿，看微博关注的重点都集中在大 V 和明星，假设平均每条有 100 人观看，再假设 10%的用户会对微博评论发表自己的看法，则评论发送量约为 25 亿条。

1. 查看微博评论

大部分查看微博的用户都喜欢看评论区，假设 90%的人都爱看评论，则评论查看次数为 2.25 x 100 x 0.9 = 225 亿。

1. 使用习惯

大部分人集中在早上 8 点~9 点，中午 12 点~13 点，晚上 20 点~22 点，假设这 4 个小时流量占比为 60%。

1.3 性能需求计算

1. 发表微博评论

25 亿 x 60% / (4 x 3600) = 100K/s

1. 看微博评论

225 亿 x 60% / (4 x 3600) = 950K/s

2. 业务分析

2.1 发表评论

业务特性分析

微博发布评论，不用实时展现，可以出现延迟，因此可以使用消息队列进行削峰操作。

架构分析

用于微博用户量巨大，因此采用多级负载均衡架构，CDN->F5->nginx->网关

架构设计

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

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

2.2 看评论

业务特性分析

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

架构分析

1. 用户量过亿，应该要用多级负载均衡架构;

2. 请求量达到 125 亿，应该要用多级缓存架构，尤其是 CDN 缓存。

架构设计

1. 负载均衡算法选择。游客（非登陆用户）都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

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

3. 与微博类似，并非所有的评论需要上 CDN。但是热门微博的热门评论页一定要上 CDN，并进行定期（如每半小时）更新。如此可以在保证 CDN 的命中率的同时提供相对较实时的用户体验。

微博评论的多级缓存架构