【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其

高性能高可用计算架构，包括但不限于如下内容：

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

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

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

用户行为建模和用户分析

假设平均每人每天发表两次评论，每人每天查看 100 条微博，每条微博发出查询评论请求 1 一次。

大部分人集中在每天的 8:00-9:00、12:00-13:00、20:00-22:00，假设这个时间段发表和查看评论的总量占比为 60%，那么这 4 个小时发表评论和查看评论的计算如下（按照 2.5 亿计算）：

1、发表评论 TPS = 2.5 亿*2*60%/4*3600= 20K/s

2、查看评论 QPS = 2.5 亿*100*60%/4*3600 =1000K/s

性能架构设计

发表评论

• 业务特性分析

发表评论是一个典型的写操作，因此不能用缓存，可以用负载均衡

• 架构分析

由于用户量大，使用多级负载均衡，DNS->F5->Nginx->网关->应用服务器

• 架构设计

发表评论每个服务性能 500TPS，完成 20K/S 的 TPS，需要部署应用 40 台服务器，按照 20%的预留量，最终需要 48 台服务器。

查看评论

• 业务分析

是一个典型的读场景，需要做多级缓存。

• 架构分析

缓存：使用多级缓存架构。

负载均衡：由于用户量大，使用多级负载均衡，DNS->F5->Nginx->网关->应用服务器。

高可用：可在客户端、服务端均进行限流

• 架构设计

估算 CDN 可以承载 90%的流量，剩下 10%的读请求发生至应用服务，则请求 QPS 为 1000K/s*10%=100K/s，由于查看评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量为 120 台。

整体架构设计

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

【业务特性】一般原微博的评论会特别多，回复量多的评论重要一些

【架构分析】

• 发评论不需要特别及时，可以“写缓冲”来应对海量评论；

• 热点事件微博和相关的热点评论存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题不一定很突出