1.计算性能估算

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

【关键行为】微博评论

【数据量预估】

• 假设每人每天发 1 条微博，每天新增微博约 2.5 亿条

• 假设每人每天评论 5 条微博，每天新增评论数 12.5 亿条

• 假设评论发送集中在早上 8：00~9：00 点、中午 12：00~13：00 和晚上 20：00~22：00 这 4 个小时，则高峰期 TPS 约为 12.5(亿)*60%/(4*3600)，50k/s

• 假设没人每天浏览 10 条评论，每天评论浏览数约为 25 亿

• 假设评论浏览集中在早上 8：00~9：00 点、中午 12：00~13：00 和晚上 20：00~22：00 这 4 个小时，则高峰期 QPS 约为 25(亿)*60%/(4*3600)，100k/s

2.非热点事件高性能计算架构

【业务特征分析】微博评论属于写操作

【架构分析】

• 多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡

• 针对发送评论，评论内容可以在用户本地缓存，通过引入消息队列缓存并异步处理评论写请求

• 针对浏览评论，考虑到微博本身大概率会用到 CDN 缓存，因此评论可以复用 CDN 内容缓存，这样如果覆盖 90%请求的话最终仅有 10%请求会访问到业务服务器

【架构设计】

• 评论请求为无状态服务，可以发到任意服务器，因此可以采用“轮询”或“随机”算法

• 针对写评论，假设每台服务器每秒处理 500 请求，完成 50k/s 的 TPS，需要 20*5=100 台服务器

• 针对读评论，假设每台服务器每秒处理 1000 请求，完成 10k/s 的 QPS，需要 10 台服务器

• 最终机器数量为 110 台

• 任务分解，可以拆解为：

• 评论查询

• 评论接收/审核

• 评论写入

3.热点事件高可用计算架构

高可用方案可以分为以下几种

• 限流 -- 针对热点事件的评论可以采用限流，譬如请求端限流(图中用户处，譬如通过本地缓存等处理一部分用户请求)，接入端限流(譬如图中的评论接收服务器)，微服务限流

• 排队 -- 收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理，如图中 Message Queue

• 熔断及降级处理，热点事件发生时保证核心业务正常运营，同时通过 message queue 保留请求慢慢消化