课题

作业要求

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

1) 计算性能预估 (不需要考虑存储性能)

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

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

提示

分析方法对照"看微博"和"发微博"的案例

1. "微博评论"性能估算

基于模块 5 第 6 课的实战案例，假设看微博的人当中只有 20%的人会评论微博，平均每条评论被 10 个人看，则读写微博评论的性能估计为：

写微博 TPS 为：2.5 亿 × 100 × 0.6 × 0.2 / 4(小时) = 200k/s

读微薄的 QPS 为：200k/s × 10 = 2000k/s

写评论服务器按照 500 条/s 的处理量，则需要服务器数量为：200k/s / 500 = 400 台

读评论服务器按照 1000 条/s 的处理量，则需要服务器数量为：2000k/s / 1000 = 2000 台

2. 高性能计算架构设计

2.1 写评论

1. 写评论的实时性不如写微博，不需要第一时间让别人知道，为了提高性能，引入写缓存;

2. 由于用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡;

3. 与发微博业务类似，写评论所依赖的登录状态一般都是保存在分布式缓存中，因此将请求发送给任意服务器都可以，选择“轮询”或者“随机”算法;

4. 写评论也涉及几个关键的处理：内容审核、数据写入存储以及数据写入缓存，但是由于评论一般都有字数限制，所以处理速度要快于写微博，按照 1000/s 来估算，完成 200k 的 TPS, 在加上些许冗余，总共需要 200 台服务器;

2.2 看评论

1. 看评论属于典型的读场景，且评论之后不能修改，因此适用缓存架构及负载均衡架构;

2. 由于用户量过亿，应该用多级负载均衡架构; 并且数据请求量达到 2000K QPS，适用结合 CDN 的多级缓存架构;

3. 无注册也可以看评论，故可以将请求发送给任意服务器，选择“轮询”或者“随机”算法;

4. 假设 CDN 能够承载 90%的用户流量，且看评论的处理相对于看微博的处理效率要高一些，按照 1500/s 的处理能力，然后在加上一些冗余，总共需要 150 台服务器;

3. 整体架构设计

整合微博评论发与看两类核心功能，整体计算架构设计分析如下：

1. 任务分配：基于负载均衡架构，采用多机房部署;

2. 任务分解：由于看与写评论的量相当，故可以整合为评论服务;

3. 负责均衡算法：采用随机或轮询算法;

4. 服务器资源计算：由于看评论和写评论整合为评论服务，取其需求的最大值：200 台服务器;

综上，微博评论负载均衡架构如下图所示：

多级缓存架构如下图所示：

4. 热点事件高可用计算架构

微博的评论重要性不如微博本身，可以考虑对“写微博”限流。由于评论不是核心业务，必要时可以丢弃，用户重新评论即可，所以可以考虑用“令牌桶算法”进行限流。