用户量

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）

业务场景

• 假设平均每天每人发 1 条微博，则每天微博发送量约为 2.5 亿，且大部微博发送时间集中在早上 8 点到 9 点，中午 12 点到 1 点，晚上 8 点到 10 点，假设这几个小时微博发送量占比 60%；

• 由于大部分微博用户都是围观大 V 和明星，则假设每条微博观看人数为 100 次，大部分人看微博的时间和发微博时间基本重合；

性能预估

看评论：假设有 60%的用户在看微博的时候，查看了评论，且每条被查看的微博平均包括 30 条评论，则看评论的平均 QPS 为：

2.5 亿*100*60%/（4*3600）*60%*30≈1800W/s

发评论：假设在看微博的时候，有 10%的用户平均发布了一条评论，则发评论的 TPS 为：

2.5 亿*100*10%/（4*3600）≈17W/s

架构分析

由上面性能预估结果可知，微博评论这个场景属于读多写少，用户发送的评论实时性要求并不高，则可考虑拆分评论查看和发送评论两个服务，读写分离，针对性设计以优化性能，可采用以下设计：

评论查看

1. 采用 APP/浏览器-> CDN -> WEB 容器缓存 ->应用缓存 ->分布式缓存的多级缓存，存储评论数据，分摊庞大的数据查询压力；

2. 评论数据可再按照热度，划分为热点评论数据，以及普通数据，动态判断数据热度，分别存储在不同的缓存位置；

评论发送

1. 采用 DNS->Nginx->网关->服务集群的四级负载均衡，

2. 当请求到达服务集群时，由于评论发送需要读取分布式缓存中的登录状态，可利用“轮询”或者“随机”算法分发请求到具体的业务服务器中；

3. 评论发送请求到达业务服务器时可压入消息队列（比如 Kafka）,再进一步通过将同步转为异步的方式，降低服务器压力；

架构设计

多级缓存架构

多级负载均衡

服务器预估

评论查看

按照每台服务器支持 2500 读请求/s，则可考虑设置 100 台即可；

评论发送

按照每台服务器可支持 800 请求/s，可设置 17w/800≈220 台，增加一定的冗余，则可设置 350 台即可。