计算性能预估

发评论

绝大多数用户会针对热点微博进行评论，很少对普通微博进行评论，假设平均每天每 2 人发一条评论，则发评论的次数：

2.5 亿 * 0.5 = 1.25 亿

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

1.25 亿 * 60% / (4*3600) = 5K/s。

查看评论

绝大部分用户是查看热点微博的评论，查看评论的次数应少于查看微博的次数，因此我们假设每条微博产看评论人数有 50 次

查看评论的次数一般大于微博的次数，假设查看微博评论（包括评论的评论）人数有 20 次

2.5 亿 * 50= 125 亿

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

125 亿 * 60% / (4*3600) = 500K/s。

发评论

【业务特性分析】

发评论是写操作，典型特点针对热点事件的评论数会出现流量高峰，会出现 10 倍，100 倍，甚至 1000 倍通常情况下的流量，需要用负载均衡。

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

【架构设计】

1. 负载均衡算法选择，发评价是基于一条微博，因此发评论的时候，将请求发送给指定服务器比较好，这 里选择“Hash”算法。

2. 业务服务器数量估算 发评论涉及几个关键的处理：数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因 此按照一个服务每秒处理 500 来估算，完成 5K/s 的 TPS，需要 10 台服务器，需要为热点事件冗余服务器，我们用 5 倍的服务器，50 台服务器。

发评论的多级负载均衡架构

查看评论

【业务特性分析】 产看评论是读场景，由于评论发了后不能修改，适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

【架构分析】

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

2. 请求量达到 125 亿，应该要用多级缓存架构；

【架构设计】

1.负载均衡算法选择 网友是查看指定微博的评论，因此将请求发送给指定服务器较好，这里选择 Hash 算法。

2. 业务服务器数量估算 假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 500K/s * 10% = 50K/s，由于读取微 博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 50 台，按照 20%的预留量， 最终机器数量为 60 台。

查看评论的多级负载均衡架构

查看评论的多级缓存架构

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

1.  发评论

重要性和影响力不如发微博，限流、排队、降级都得用

根据微博业务特性，降级分 2 种，一种是全面降级，一种是保证热点微博的评论功能，其它普通微博暂停评论功能，按照热点情况，给微博排优先级，根据优先级动态降级；

2.  查看评论

除了发评论时用到的方法以外，备份多份热点微博评论，降低新鲜度；