模块 5 作业

性能估算

2020 年微博认证的媒体机构类账号数量超过 3.8 万个，全年媒体机构所发布微博累计被转评、评论和点赞超过 66.8 亿次，总阅读量超过 2.4 万亿次。

假设全年转评、评论和点赞次数为 100 亿次 则 评论与阅读的比例为 24000/100 约为 200 比 1

根据前面课程分析看微博的次数约为 250 亿次/天，所以评论微博数量为 1.25 亿次每天

评论微博的时间段与看微博的时间段也是重合的所以，评论的 TPS 计算如下：

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

非热点事件时的高性能计算架构

业务特性分析

评论是写操作，不能用缓存，可以用负载均衡

架构分析

用户量比较大，采用多级负载均衡架构，覆盖 DNS→ LVS（F5）→Nginx→网关的多级负载均衡。

是否需要拆分？

由于请求量不是很大，可以复用写微博的服务

好处是：

• 节省服务器资源

• 降低运维成本

• 读微博时可以与评论在相同服务返回给用户，效率高

弊端是：

• 可能有故障互相影响的可能性

• 需要统一协调部署测试资源，开发效率与拆分相比低

架构设计

1. 负载均衡算法选择

2. 发评论依赖登陆状态，按照课程分析登陆状态，是在分布式缓存内的，发评论和发微博一样，发送到任意服务器都可以。所以选择“轮训”或“随机算法”。

3. 服务器数量估算

4. 按照每个服务器 500TPS，需要 10 台服务器

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

业务特性分析

热点事件是一个不易预测的事件，突发流量非常大，挑战是如何用有限的资源应对突发的巨大流量，然后等待扩容完成。

架构分析 &设计

热点事件属于请求量过大的场景，同时要尽量保障写请求不丢失，所以要保障服务的高可用，选择写缓冲的限流手段（漏桶），通过把评论写入 Kafka 消息队列，再由评论服务消费队列写入评论数据库