M_5: 设计微博系统中”微博评论“的高性能高可用计算架构。

一、性能估算

1.1 用户量预估

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

关键行为：评论微博

1.2 用户行为建模

参考看微博数据为：2.5 亿 * 100 = 250 亿。

【评论微博】假设看微博的次数中有 5%会参与评论，则评论微博的次数为：2.5 亿*5= 12.5 亿

1.3 性能估算

大部分人评论微博的时间段和发微博的时间段基本重合，因此评论微博的 TPS 计算如下：12.5 亿*60%/(4*3600)≈50k/s

二、非热点高性能计算架构设计

架构分析

【业务特性分析】 评论微博是一个典型的写操作，因此不能用缓存，但是由于发评论的即时性没有发微博要求那么高，但是又要尽量不丢，所以可以用写缓冲，异步处理，同时还需配合负载均衡。

【架构分析】 用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。因为预估的 TPS 也是平均情况，峰值 TPS 会高于平均值，故使用 Kafka 集群作为写缓冲，评论请求先进入 Kafka 中的队列，业务线程再异步慢慢处理。因为发评论的平均 TPS 约为 5 万/s，所以写缓冲的容量设为 5 万即可。

【架构设计】

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

2. 业务服务器数量估算 评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因 此按照一个服务每秒处理 500 来估算，完成 50K/s 的 TPS，需要 100 台服务器，加上一定的预留量，100 台服务器差不多了

3.发评论与发微博和看微博的业务关联的紧密程度并不大，发了一条微博，过个两三天甚至 1 个月评论都是可能的，发评论的请求次数与发微博和看微博都有较大不同，发一条微博也就一个请求，看这条微博可能几千万个请求，在这个微博下发评论多的话可能也就几万或几十万个请求。所以需要将发评论的业务拆分成独立的服务。

多级负载均衡架构设计

三、热点事件高可用计算架构

架构设计分析

【业务特性分析】

热点事件发生后，绝大多数的评论请求都落在了导致热点事件发生的那一条微博下面，或是大 V 转发的那几条微博下面，所以评论很快就会被刷到后面，无法看到，所以评论的重要性与影响力没有微博那么大。因为评论的重要性与影响力相对小，可以考虑对“评论”限流，但是“评论”也要做到尽量少丢弃请求，考虑用漏斗算法。

可调整写缓冲的容量为平均 TPS 的 10 倍，即 50 万。

限流设计

1. 当热点事件发生时，考虑在请求接入端做人工限流

2. 微服务端也需要限流，已提前完成限流逻辑，即如果 kafka 中的写缓冲已满，则丢弃无状态请求，不会交由业务线程处理。