作业要求

性能评估

• 用户量

DAU 2.24 亿， MAU 5.11 亿

• 写评论

写评论的数量基于发微博的数据量（平均每人每天发 1 条微博），写评论的时间也与发微博的时间基本重叠（高峰时段 8：00-9:00， 12:00-13:00， 20:00-22:00），假设每条微博有 20 条评论

TPS: 2.5 亿 * 60% / (4*3600 秒) *20 = 200k/s

• 看评论

假设每十条微博会被点开来看评论

25 亿*10 条*60% / (4*3600 秒) = 100k/s

高性能计算架构设计

• 业务特性分析

写评论 典型写操作，不能用缓存，需要用负载均衡

看评论 典型读操作，评论发完不能修改，只能删除，请求量很大，需要多级缓存和多级负载均衡

• 架构分析

写评论 应用多级负载均衡架构， DNS-> F5 -> Nignx->网管多级负载均衡

看评论 应用多级负载均衡架构，100k/s 可以不使用 CDN，使用 APP 缓存 -> WEB 容器缓存 -> 进程内缓存 -> 分布式缓存 多级缓存

• 架构设计

负载均衡 评论微服务应设计成无服务的，请求给任意服务器都是等效的，使用轮询算法。

业务服务器估算

假设每台服务器处理 500TPS 写评论请求，需要写评论服务器 200k/500=400 台

假设每台服务器处理 1000QPS 看评论请求，需要写评论服务器 100k/1000=100 台

负载均衡架构图

缓存架构图

高可用计算架构设计

热点事件评论性能估算

业务特性分析

造成热点事件的微博自己只有 1~2 条，但是用户围观后会有很多转发，假设有 10%的围观用户会在事件发生后 60 分钟内转发。

针对每条热点微博，在发布一个小时之内，会有 1k ~ 100k 的评论数，写的评论可以容忍不是立即被看到

架构设计分析

写评论 评论要保证尽量不丢失，同时做好系统限流，考虑用漏桶算法

看评论 热点微博 1k ~ 100K 评论，采用 Redis list 来存储评论， 并在多个 slave 上保存副本

计算高可用架构图