建模：

·        5 亿用户，2.5 亿日活

·        大部分写评论、读评论发生在早上 8：00~9：00，中午 12：00~13：00，晚上 20：00~22，假设这几个时间段评论总量占总评论 60%

写评论

每个用户平均每天评论 3 条： 则 4 小时平均写评论 TPS 计算如下：2.5 亿 * 3 * 60% / (4*3600) ≈ 30K/s

读评论：

每个用户平均每天读评论 200 条，评论加载为 15 条一页：则 4 个小时平均读评论 QPS：2.5 亿 * 200 * 60% / (4*3600) ≈ 150K/s

写评论架构

业务分析

写评论，典型写操作，不能用缓存，可以用负载均衡。应为用户量过亿，需要多级负载均衡：DNS -> F5 -> Nginx -> 网关

架构设计

负载均衡算法（不考虑热点微博）：

因为评论从属具体微博，且有时间顺序要求，将某一微博评论选择相同服务器，因此选用 hash 算法（根据微博 ID）

服务器数量估算：

假设每个服务器评论处理速度为 500，完成 30K/s TPS，需要 60 台服务器

读评论架构

业务分析

评论不能修改，可缓存，因为读取请求大，需要负载均衡。评论实时性要求不高

架构分析设计

因为评论数量过大，如果使用 CDN 成本太高，并且评论实时性要求不高，所以不用 CDN

负载均衡算法（不考虑热点微博）：

因为评论从属具体微博，且有时间顺序要求，将某一微博评论选择相同服务器，因此选用 hash 算法（根据微博 ID）

服务器数量估算：

假设每个服务器评论处理速度为 5000，完成 150K/s TPS，需要 30 台服务器

评论缓存架构

评论数据量过大，更新频繁，此处不设置分布式缓存和 CDN 缓存