设计微博系统中”微博评论“的高性能高可用计算架构

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：

1）计算性能预估（不需要考虑存储性能）

2）非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务

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

计算性能预估

• 用户量预估： 根据《微博 2020 用户发展报告》，在 2020 年 9 月，微博用户月活为 5.11 亿，日活为 2.24 亿

• 微博用户关键行为：

• 评论微博

用户行为建模和性能估算

• 假设条件：

• 平均每人每天评论 4 条微博

• 微博日评论量为 10 亿条

• 微博评论和发送时间为

• 8:00-9:00，12:00-13:00，20:00-22:00

• 估算平均 TPS 为：(10 亿 x60%)/(4x4600) = 40k/s

高性能计算架构设计

• 业务特点

  用户能立刻看到自己发的评论，其它人可以延迟看到某个用户发的评论。

  评论发出后不能丢失。是一个典型的写操作，因此不能用缓存，但是可以负载均衡

• 架构分析

• 日用户活跃量过亿，因此必须采用多级负载均衡架构 DNS->F5->Nginx->Gateway

• 架构设计

• 负载均衡算法依赖用户登录状态，而登录状态保存在分布式缓存里，因此负载均衡算法可采用“轮询算法”或者“随机算法”

• 服务器按照一个服务每秒处理 1000TPS 次来估算，完成 40k/s 的 TPS 处理，需要的服务器大概在 40 台左右。

• 架构设计图和“发微博的多级负载均衡架构类似，因此直接引用

热点事件时的高可用架构

• 业务特性

• 由于是热点事件，那么 90%的评论发送请求都在某一条微博上，并且是写操作

• 架构分析

• 用户活跃量过亿，因此必须采用多级负载均衡架构 DNS->F5->Nginx->Gateway

• 架构设计

• 负载均衡算法依赖用户登录状态，而登录状态保存在分布式缓存里，因此负载均衡算法可采用“轮询算法”或者“随机算法”

• 服务器按照一般情况下的数量翻倍，因此 80 台服务即可