模块五作业 - 微博评论高性能高可用计算架构

业务场景分析和性能估算

用户量预估

微博月活跃用户数增至 5.73 亿，日活跃用户数达 2.48 亿

用户行为建模和性能需求预估

评论微博是一个写操作，假设每天每人发 10 条微博评论，每天评论数量预计 25 亿条。

评论微博时间和发微博集中时间相同，大部分的人发评论集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发评论总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下：

25 亿 * 60% / (4 * 3600) ≈ 100 K/s。

高性能计算架构设计

业务特性分析

发微博是一个典型的写操作，tps 较高，但是其对时效性要求并不严苛，可以采用写缓存，也可以用负载均衡。

架构分析

• 用户量过亿，要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

• 写性能需求较大且允许延迟，采用写缓存

架构设计

1. 负载均衡算法选择

发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发微博的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 1000 来估算，完成 100K/s 的 TPS，需要 100 台服务器，加上一定的预留量，大约需要 120 台服务器。拆分独立的服务可以降低对其他服务的影响。

高可用计算架构设计

热点事件行为建模和应对方案

• 以上设计应对平常没问题，热点事件发生时，用户量会暴增，大量用户会在短时间内访问，给系统造成巨大压力

• 热点事件通常指某个大 V 或者明星爆料或者官宣，评论会集中在原微博和少数转发的微博上

• 微博评论重要性和影响力不如发微博，可以考虑对评论微博限流，不得已时丢弃少量请求以保证整个系统不被压垮，可以用漏桶算法的变身写缓冲来应对。同时评论的时效性要求不那么高，可以使用写缓存来降低服务器瞬间压力。