业务量估算

• 可用写评论

考虑微博是一个写少看多的系统，假设每个人每天平均发两条微博评论，则微博评论量大概每天为 2.5 亿 2 =5 亿条。大部分人写评论集中在早上 8 点～9 点，中午 12 点到 13 点，和晚上 8 点到 10 点。这几个时段占总量的 60%。则平均发评论的的 TPS 5 亿 * 60%/ （4 *3600） = 20K/s

• 读评论

评论一般集中在热名帖子。假设每个评论平均被浏览 100 次。看评论和发评论的时间端基本重合。

QPS = 5 亿 * 60% * 100/ （4 *3600） = 2000k/s

构架分析

• 写评论

业务特征分析

写评论是写操作， 不需要缓存，但需要负载均衡

• 构架分析

用户量过亿， 需要用多级负载均衡（F5->Nginx->Gateway)

• 构架设计

• 负载均衡算法

轮询，随机多可以

• 业务服务器估算

写评论涉及几个步骤，内容审核，写入存储，写入缓存。按一个服务可以处理 500 请求计算，处理 TPS :20k/S 需要 40 台服务器，加上预留量 10%， 44 台服务器即可。

• 读评论

业务特征分析

读评论是典型读操作，一般评论很少修改，适合用缓存架构。业务量巨大，需要用负载均衡

• 构架分析

用户量过亿， 需要用多级负载均衡（F5->Nginx->Gateway)

请求量达到 2M/s ,需要用多级缓存架构，特别是 CDN

业务量

• 构架设计

• 负载均衡算法

轮询，随机多可以

• 业务服务器估算

假设 CDN 能处理 90%的流量，业务服务器要处理 10% 的流量 2000K/S * 10% = 200k/s

读评论逻辑比较简单。按一个服务可以处理 1000 请求计算，处理 TPS :200k/S 需要 200 台服务器，加上预留量 10% 220 台服务器即可。

总体构架：

由于写评论和读评论请求量级差异太大，建议拆分独立的服务

热点事件

业务量估算

热点事件 指大 V , 突发事件，明星爆料或者官宣。但热点事件发生时候会有针对某几个微博的大量的评论发布和浏览。

• 写评论

会有大量的用户围观某一两个微博，假设有 10% 的人会发布评论

• 读评论

很难评估。取决于事件的影响力和范围。

构架分析

热点事件无法预估只能预防。

• 写评论

短时间写评论集中在某几个微博上。但 因为对评论实时性要求不高。可以用写缓冲。甚至可以限流，可用漏桶算法

• 读评论

短时间读评论集中在某几个微博上。为了解决缓存热点问题，可以用多副本缓存。因为构架已使用本地缓存，热点问题不一定很明显