模块五作业

1. 用户行为建模和性能估算

【浏览评论】

基数：用户 2.5 亿；

假设：每人每日浏览的微博数量为 100 条，并对其中 80%的微博查看其评论；

时间：用户 60%的浏览量集中在早 8:00-9:00，中午 12:00-13:00，晚 20:00-22:00 的 4 个小时内；

QPS：2.5 亿 *60%*100*80%/(4*3600) = 833K/s

【发布评论】

基数：用户 2.5 亿；

假设：每人每日浏览的微博数量为 100 条，并对其中 30%的微博发布评论；

时间：用户 60%的评论操作集中在早 8:00-9:00，中午 12:00-13:00，晚 20:00-22:00 的 4 个小时内；

TPS：2.5 亿 *60%*100*30%/(4*3600) = 312K/s

2. 微博评论高性能计算架构设计

2.1 整体架构

2.2 业务分析

2.2.1 发布评论

【业务特性】

发布评论是典型的写操作，由于其实时性要求不太高且请求不可丢弃的特点，因此为了降低系统压力，可引入写缓冲。

【架构分析】

用户量过亿，应该要使用多级负载均衡架构。

【架构设计】

1. 由于需要用户登录，登录状态可记录在分布式缓存中，因此发布评论的时候，可发给任意服务器。故选择轮询或者随机算法。

2. 服务器数量

发布评论的关键处理步骤与发微博相似：内容审核、数据写入存储、数据写入缓存。由于评论的内容一般是低于微博的内容，因此按照每个服务器每秒处理 1000 请求来估算。由于引入了写缓冲，为保证用户在 5 秒之内可看见自己的评论，故每台服务器可缓冲 5000 请求。加上 20%的预留量，综上，完成 312K/s 的 TPS，需要约 75 台服务器。

2.2.2 浏览评论

【业务特性】

发布评论是典型的读操作，适合缓存架构，由于请求量大，也需要引入负载均衡架构。

【架构分析】

1. 用户量过亿，应该要使用多级负载均衡架构。

2. 请求量超过 200 亿，应该使用多级缓存架构，尤其是 CDN 缓存。

【架构设计】

1. 由于需要用户登录，登录状态可记录在分布式缓存中，因此发布评论的时候，可发给任意服务器。故选择轮询或者随机算法。

2. 服务器数量

假设 CDN 承载了 90%的流量，那么剩下的 10%的读请求进入系统。因此，QPS = 833K/s *10% = 83K/s。假设单机处理能力为每秒 1000，预留量 20%，故需约 100 台服务器。

2.3 微博评论业务架构图

综上所述，微博评论的多级负载均衡架构如下如图。

微博评论多级缓存架构如下图。

3. 微博热点事件高可用架构

3.1 核心思想：无法预估，做好预防。

3.2 架构设计分析

3.2.1【发布评论】

热点事件突发，评论量会显著上升。由于在发布评论业务中，引入了写缓冲，系统不会有宕机的危险，但用户体验会下降，因为能刷到自己评论的时间会等更久。

3.2.2【浏览评论】

热点事件会带来缓存热点的问题，可以考虑多副本缓存。

3.3 热点事件评论业务计算高可用架构示意图