架构实战营模块 5 作业

用户量估算

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

关键行为：

1. 发评论；

2. 看评论

本作业主要针对评论微博和看评论两个关键行为。根据业务重要性及耗时容忍度排序， 看微博 < 发微博 < 看评论 < 发评论。

按照课程中的预估，每天微博发送量约为 2.5 亿条。看微博量 250 亿次。发评论、看评论的数据量缺少支撑。

因此假设发评论量也为 2.5 亿条。看评论量约为看微博量的 30%，大约 75 亿次。

假设 4 个小时内数据量占比 60%，则：

发评论 TPS 为 2.5 亿 * 60% /(4*3600)  ≈ 10 K/s

看评论 QPS 为 75 亿 * 60%/(4*3600)  ≈ 300K/s

计算架构设计

服务拆分设计

发评论和看评论服务拆开

理由：

1、发评论和看评论并没有特别强的关联，举个例子发评论以后并不需要被马上看到

2、发评论和看评论的性能差距比较大，特别是热点微博的热点评论，在架构设计上也有一些差别，所以拆开比较好设计和维护

负载均衡架构设计

发评论和看评论均采用 5 层负载均衡：

1 层负载均衡：dns，采用双机房负载均衡

2 层负载均衡：F5

3 层负载均衡：LVS

4 层负载均衡：nginx

5 层负载均衡：网关

业务服务器量预估

发评论也涉及到审核等多个步骤，评估 MQ 的性能，以及服务器消费性能，因此按照一个服务支撑突发流量 2000/s 计算，完成 10K/s，需要 5 台服务器，加上一些与流量 8 台差不多了。

多级负载均衡架构

热点事件高可用架构设计

请求量预估

由于热点事件的时间和流量的不确定性，因此不太好预估请求量

限流/缓冲设计

发评论

由于发评论的数据是不能丢的，否则会造成较差的用户体验，因此发评论不适合使用类似令牌桶算法的限流策略；

这里可以使用消息队列实现缓冲，设计理由：

1、消息队列有出色的消息积压能力

2、消息队列能做到削峰填谷，

3、评论实时性要求没有很高，发出去 1 分钟后才展示出来并没有太大的影响

看评论

看评论是允许消息丢失的，因为丢失后无非就是重新请求一次，并没有太大的影响，那么就可以使用我们常用的令牌桶算法，也可以使用漏桶算法