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

一、评论微博_计算性能估算

1.1【用户量】日活 2.5 亿，还是假设平均每天每人发一条微博

1.2【性能估算】

我们假设每条微博有 5 人评论，根据发微博和看微博的时间集中在早上 8:00-9:00, 中午 12:00-13:00，晚上 20:00-22:00，我们可预估，在这四个小时平均 TPS 如下：

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

二、非热点事件时的高性能计算架构

2.1【业务特性分析】

跟发微博一样，这是一个写操作，不需要缓存，由于用户量很大，需要使用多级负载均衡

2.2【架构分析】

用户量过亿，需要使用多级负载均衡架构，即 DNS -> F5 -> Nginx -> 网关

【架构设计】

1、负载均衡算法选择

跟发微博一样，评论也需要依赖用户的登录状态，由于登录状态一般保存在分布式缓存如 redis 中，因此将请求发给任何一台业务服务器都可以，这里使用轮训即可(假设所有的服务器配置一样)

2、业务服务器数量估算

跟发微博一样，评论也涉及内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统),  按照一台服务器每秒处理 1000 来估算，完成 50k/s 的 TPS，需要 50 台服务器，加上一定的预留量，这里 60 台服务器就可以了

3、非热点时间时的高性能计算架构，需要考虑是否要拆分独立的服务

为了系统的性能提升和可用性，评论微博需要拆分为独立的服务

微博评论的多级负载均衡架构

微博高性能计算架构-整体架构设计

微博的多级缓存整体架构

由于微博评论和发微博一样没有缓存，因此微博业务整体的缓存架构，就是看微博的多级缓存架构

三、热点事件时的高可用计算架构

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

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

【微博评论】

虽然热点事件的微博可能只有 1-2 条，但是会有很多用户来评论，这里的评论很难估算，因此评论接口需要做好限流、排队、降级、熔断的措施来预防

3.2 微博热点事件业务特性分析

【微博评论】

微博评论的重要性和影响力也同样不如原微博，且评论之后，当前用户不需要马上看到自己的评论，只需要尽量保证写成功即可

3.3 微博热点事件计算高可用架构分析

核心架构设计思想：既然无法预估，那就做好预防

【架构设计分析】

由于微博评论的重要性和影响力也同样不如原微博，只需要尽量少丢失请求即可，这里考虑使用”漏桶算法”的限流策略，并且设置尽量大的缓存队列

微博热点事件计算高可用架构示意图