0.作业要求

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

1.计算性能预估

1.1 基本数据

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

• 微博评论包含 2 种关键行为：发微博评论，看微博评论

1.2 建模和性能估算

发微博评论

• 考虑到微博是一个看得多，发很少的业务。假设平均每天每人会对 2 条微博发评论，则微博评论的每天发送量为 2.5 * 2 = 5 亿条

• 假设大部分人发微博评论的时间段集中在 8:00~9:00, 12:00~13:00, 20:00~22:00，假设上述时间段发送评论的量占总量的 60%，则发评论的 TPS 为：2.5 亿 * 2 * 60% / (4 * 3600) = 20K/s

看微博评论

• 假设平均每人会看 100 条微博，20%的微博会打开评论的第一页，2%的微博会打开第二页的评论, 上述浏览行为 60%发生在高峰的 4 小时内。

• 微博评论的 QPS 计算：2.5 亿*100*(20% + 2%) *60%/(4*3600) = 230K/s

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

2.1 发微博评论

• 发微博评论是一个写操作，而且完成后不能修改。因此不需要缓存。

• 每日活跃用户总量过亿，需要用多级负载均衡架构，包括 DNS->F5->Nginx->网关

• 发评论只有一次的交互，可以负载均衡算法可以选择最简单的“轮询”或者“随机”算法

• 按照一个服务器每秒 500 来估算，完成 20K/s 的 TPS 需要 40 台服务器，加上预留量，50 台服务器

2.2 看微博评论

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

• 用户量过亿，必须采用多级负载均衡架构，DNS->F5->Nginx->网关。负载均衡算法选用“轮询”或者“随机”算法

• 请求数量达到 55 亿，应该用多级缓存架构，本地缓存->CDN->web 容器缓存->应用缓存->分布式缓存

• CDN 中只需缓存第一页的评论，其余缓存前 5 页的评论

• 假设 CDN 承担绝大部分的流量，只有 10%的读评论请求进入系统，流量为 23K/s，一台服务器处理读请求为 1000/s，机器数量为 23 台，加上预留，30 台服务器

2.3 整体架构

多级负载均衡架构

多级缓存架构

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

3.1 发微博评论

• 对于热点事件，用户发微博评论的意愿更强烈，短期内对系统冲击较大可以采取：用户端缓存+后端限流的方式。

• 用户端本地缓存：用户发完评论后，利用本地缓存直接将该评论在客户端置顶

• 后端限流：采用漏桶算法，减少丢弃请求

3.2 看微博评论

• 热点事件中，用户更加愿意翻看更多的评论，可以采用 CDN + 后端多副本缓存

• CDN：将前 5 页的评论都存入 CDN

• 后端：将热点微博的评论的副本的放入多个缓存服务器。