架构实战营模块5作业

微博评论高性能高可用计算架构设计

一、计算性能预估

1.1 用户量

2020.9月月活5.11亿，日活2.24亿（参考《微博2020用户发展报告》）。

1.2 微博评论场景关键行为：

• 发评论

• 看评论

1.3 行为建模以及性能估算

• 发评论：假设平均每天每人发1条微博（只考虑文字微博），则微博每天的发送量约为2.5亿条。大部分的人发微博集中在早上8：00~9：00点，中午12：00~13：00，晚上20：00~22：00，假设这几个时间段发微博总量占比为60%。用户发评论的时间与发微博的时间基本重合，且多数评论都集中在明星和大V的微博下。假设平均每条微博有100人阅读，有十分之一的人会发表评论，那么每条微博对应10条评论。性能估算为：2.5亿条 * 10条评论
   
  * 60%/(4 * 3600) ≈ 100K/s

• 看评论：看评论的时间与发评论、发微博的时间也基本重合。假设看微博的人中约有30%会点开评论查看，那么性能估算为：2.5亿条 * 100人 * 30% * 60%/(4 * 3600) ≈ 300K/s

二、微博评论高性能计算架构设计

2.1 发评论

2.1.1 发评论架构设计

• 从业务特性上来分析，发评论是一个写操作，正常情况下不能用缓存，可以用负载均衡。

• 架构分析：用户量过亿，TPS要求也非常高，应该使用多级负载均衡的架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

• 架构设计：

（1）负载均衡算法设计：

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

（2）业务服务器数量估算：

发表评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），但是一般评论内容比微博的内容简单很多，因此按照一个服务每秒处理 1000 来估算，完成 100K/s 的 TPS，需要 100 台服务器，加上一定的预留量，150 台服务器差不多了。

2.1.2 发评论的多级负载均衡架构

2.2 看评论

2.2.1 看评论架构设计

• 业务特性分析，看评论是一个典型的读场景，由于评论发了之后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

• 架构分析：

（1）用户量过亿，应该要用多级负载均衡架构；

（2）请求量达到75亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

• 架构设计：

（1）负载均衡算法选择游客都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

（2） 业务服务器数量估算假设 CDN 能够承载90%的用户流量，那么剩下10%的看评论的请求进入系统，则请求 QPS 为300K/s * 10% = 30K/s，由于看评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是1000/s，则机器数量为30台，按照20%的预留量，最终机器数量为36台。

2.2.2 看评论的多级负载均衡架构

2.2.3 看评论的多级缓存架构

微博评论一般不如微博本身重要，同时根据微博热门评论以及精选评论等功能进行分析，排名靠前的微博评论是最容易被看到的，后面的评论可能很少被查看，所以可以区分两类评论，将热门评论存储到CDN，并定时更新，非热门的评论缓存一份列表到分布式缓存系统，能够节约CDN服务器资源的成本。

2.3 整体架构方案

2.3.1 微博评论的多级负载均衡设计

2.3.2 微博评论的多级缓存架构设计

只有看评论会用到缓存架构

三、微博评论高可用架构设计

3.1 微博热点事件用户行为建模、性能估算

热点一般是大V或明星的爆料、官宣等事件，或者是一些社会热点事件，一般集中在一两条微博，但引起大量用户在短时间内访问，给系统造成很大压力。

• 发评论：

热点事件下的评论数量一般非常多，一条热点微博下起码约几百甚至上千条评论。

• 看评论：

热点事件往往会聚集很多吃瓜群众，看微博评论的次数也会明显比平时要高出很多。但很难预估，主要和事件的影响力和影响范围有关。

3.2 业务特性分析

• 发评论：评论一般不如发微博重要，而且很多评论发出后就会被刷下去，也不会被马上看到，热点事件发生时可以通过写缓存的方式降低系统的负载压力。

• 看评论：热点事件发生后，看评论也主要是看热点微博下的热门评论居多，这部分评论主要缓存在CDN中，可以比较快的被访问到。

3.3 高可用架构分析

核心架构设计思想：既然无法预估，那就做好预防！

• 发评论：发评论不如发微博重要，且有很多评论不需要即刻被看到，可以考虑使用限流的方式保护系统。同时评论能够增加讨论度，活跃社区气氛，带来更好的传播效果，所以不应该被丢弃，可以考虑漏桶算法，通过一个kafka消息队列来实现写缓冲。

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

3.4 高可用架构设计示意图