模块 5- 微博评论高性能高可用计算架构分析

微博评论高性能高可用计算架构分析

1.  用户行为建模和性能估算

【用户量】

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

【关键行为】

A.      发评论

B.      看评论

【发评论】

假设平均每天每人发 5 条评论，则评论每天的发送量约为 10 亿条。

大部分人发表评论集中在早上 8:00~9:00,中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发评论总量占比 60%，则这 4 个小时的平均发评论的 TPS 计算如下：

10 亿*60%/(4*3600) ≈40k/s

【看评论】

由于绝大部分用户看评论的对象是大 V 的和明显，因此假设平均一天微博评论观看人数有 100 次，则观看评论的次数为：

2.24 亿*100=224 亿

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

224 亿*60%/(4*3600)≈1200K/s

2.  架构设计

2.1     发评论

【业务特性分析】

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。

【架构分析】

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Ngnix ->网关的多级负载均衡

【架构设计】

A． 负载均衡算法选择

建议选择轮询或随机算法

B． 业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖存储系统），因此安装一个服务每秒 500 来估算，完成 40k/s 的 TPS，需 80 台服务器，按照 20%的预留，100 台服务器应该差不多。

2.2     看评论

【业务特性分析】

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

【架构分析】

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

B.      请求量达到 224 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心

【架构设计】

A.      负载均衡算法选择

建议选择轮询或者随机算法

B.      业务服务器数量估算

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

3.  方案

3.1 整体架构设计

3.2 评论业务的多级负载均衡整体架构

3.3 评论业务的多级缓存整体架构

4.热点事件计算高可用架构分析

对于热点事件，参与评论的人可能会很多，但发评论的重要性不如看微博甚至转发微博，可以考虑对“发评论”采用令牌桶算法”进行限流，放入消息队列中再慢慢写入数据库。