性能估算

微博日活约为 2.5 亿，假设每人每天发 5 条评论，大部分人评论微博与发微博的高峰时间一致，都集中在上午 8-9 点，中午 12-13 点，晚上 20-22 点，假设这几个时间段发评论总量占比 60%，则这 4 个小时平均发评论的 TPS 计算如下：

2.5 亿 × 5 × 60% / (3600 × 4) ≈ 5 万/s

非热点事件的高性能计算架构

业务特性分析

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

架构分析

用户量过亿，应该用多级负载均衡，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

架构设计

负载均衡算法选择

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

写缓冲

因为预估的 TPS 也是平均情况，峰值 TPS 会高于平均值，故使用 Kafka 集群作为写缓冲，评论请求先进入 Kafka 中的队列，业务线程再异步慢慢处理。

因为发评论的平均 TPS 约为 5 万/s，所以写缓冲的容量设为 5 万即可。

业务服务器

服务拆分

因为

1. 发评论与发微博和看微博的业务关联的紧密程度并不大，发了一条微博，过个两三天甚至 1 个月评论都是可能的

2. 发评论的请求次数与发微博和看微博都有较大不同，发一条微博也就一个请求，看这条微博可能几千万个请求，在这个微博下发评论多的话可能也就几万或几十万个请求

所以需要将发评论的业务拆分成独立的服务。

数量估算

发评论涉及几个关键的处理：

1. 内容审核(依赖审核系统)

2. 数据写入存储(依赖存储系统)

3. 数据写入缓存(依赖缓存系统)

因此按照一个服务每秒处理 500 来估算，完成 5 万/s 的 TPS，需要 100 台服务器，因为有些缓冲设计，所以不用预留富余的业务服务器。

多级负载均衡架构

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

业务特性分析

热点事件发生后，绝大多数的评论请求都落在了导致热点事件发生的那一条微博下面，或是大 V 转发的那几条微博下面，所以评论很快就会被刷到后面，无法看到，所以评论的重要性与影响力没有微博那么大。

架构分析

因为评论的重要性与影响力相对小，可以考虑对“评论”限流，但是“评论”也要做到尽量少丢弃请求，考虑用漏斗算法。

架构设计

漏斗算法

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

限流

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

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