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

业务场景计算性能估算

用户量预估

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

用户行为建模 &性能估算

大部分人看微博的时间集中在早上 8:00~9:00、中午 12:00~13:00、晚上 20:00~22:00，假设这几个时间段看微博的用户数占日活总用户数的 60%

假设评论微博的人数占看微博的人数的 60%，且平均每个人每天评论 10 条微博

假设平均每人每天看 100 条微博，看微博的人中 80%的人会看微博评论，且会查看前 20 条评论

综合以上，得出：

TPS

2.5 亿*60%/(4*3600)*60%*10=60k/s

QPS

2.5 亿*60%*100*80%*20/(4*3600)=2000k/s

高性能计算架构（非热点事件）

发评论

业务特性分析

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

架构分析

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

架构设计

负载均衡算法选择

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

业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 60k/s 的 TPS，需要 120 台服务器，加上一定的预留量，150 台服务器差不多

架构图

负载架构

看评论

业务特性分析

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

架构分析

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

2. 请求量过亿，应该要用多级缓存架构

架构设计

负载均衡算法选择

游客可以直接看评论，因此将请求发送给任意服务器即可，选择“轮询”或者“随机”算法

业务服务器数量估算

假设 CDN 能够承受 90%的用户流量，那么剩下的 10%的读评论的请求进入系统，则请求 QPS 为 2000k/s*10%=200k/s，由于读评论的处理逻辑较为简单，主要是读缓存系统。因此，假设单台业务服务器处理能力是 1000/s，则机器数量为 200 台，按照 20%的预留量，机器数量为 240 台

架构图

负载架构

缓存架构

整体架构设计

任务分解：双机房，三机房

任务分配：将发评论和看评论拆分到不同服务

多级负载均衡整体架构

多级缓存整体架构

高可用计算架构（热点事件）

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统造成很大压力

用户行为建模 &性能估算

发评论

造成热点事件的微博只有 1~2 条，但是用户围观后会有很多用户在微博下方进行评论，假设有 20%的围观用户会在事件发生后 60 分钟内进行评论

看评论

很难预估，和事件的影响力和影响范围有关

业务特性分析

发评论

微博评论的重要性和影响程度不如微博本身

看评论

热点事件后，绝大部分请求都落在了导致热点事件发生的那一条微博上面

架构分析

核心思想：依然无法预防，那就做好预防

发评论

发布的评论的重要性不如微博本身，可以考虑对“发评论”进行限流，考虑用带有“写缓冲”的“漏桶算法”

看评论

热点事件微博存在缓存热点问题，可以考虑“多副本缓存”

架构图

发评论

看评论