引用

用户行为建模和性能预估

评论微博和看微博的情况差不多，因此我们假设一条微博平均有 100 人评论，则评论微博的次数为：

2.5 亿*100=250 亿

大部分人评论微博的时间段和发微博的时间段基本重合，因此评论微博的 TPS 计算如下：

250 亿*60%/(4*3600)=1000K/s

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

【业务特性分析】

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

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

评论微博可以用 kafka 写缓冲，1000K/s 的 TPS 需要 10 台 kafka 服务器，加上高可用需求 30 台 kafka 服务器就够了；

经过写缓冲处理后，后续慢慢处理，因此 TPS 计算如下：

250 亿/(24*3600)≈300K/s

评论微博和发微博的写流程差不多，因此按照一个服务每秒处理 500 来估算，完成 300K/s 的 TPS，需要 600 台服务器，加上一定的预留量，720 台服务器差不多了。

综上所述，30+720=750 台服务器。

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

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

和非热点事件时的高性能计算架构一样，多加几台服务器进行处理。