1.计算性能预估

【用户量】

2020.9 月月活 5.11 亿，日活 2.24 亿

【关键行为】

微博评论

【微博评论】

假设平均每天每人发 5 条评论，每天的评论总量为 11 亿。发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，评论的时间段和发微博相同。假设 60%的评论在这 4 个小时内发出，微博评论的 TPS 为 11 亿*60%/（4*3600）=46k/s。

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

架构设计

【业务特性分析】

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

【架构分析】

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

【架构设计】

1.负载均衡算法

发评论依赖登陆状态，登陆状态一般保存在分布式缓存中，因此可以用“轮询”或者“随机”算法。

2.业务服务器数量预估

发表评论涉及的处理：内容审核、数据存储、缓存，因此按照一个服务每秒处理 500 来估算，完成 46k/s 的 TPS，需要 92 台服务器，加上服务冗余，大约需要 110 台服务器。

多级负载均衡架构

整体架构设计

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

热点事件用户行为建模和性能估算

【微博评论】

评论和转发有一定的相似性，TPS 稍高与转发，假设有 20%的围观用户会在事件发生后 60 分钟内评论

【业务特性分析】

评论不造成传播，只表明大家对该事件的关心程度，没有影响力的扩散。

【架构设计分析】

可以考虑对评论进行限流，或者写入高可用消息队列中。

计算高可用架构示意图