一、计算性能评估

【用户量】

参考《微博 2020 用户发展报告》，2020 年 9 月微博月活 5.11 亿，日活 2.24 亿

【用户行为建模】

微博每天的发送量按每人每天发送一条计算，即每天微博发送量约为 2.5 亿

假设每条微博被阅读 100 次，则每天微博的阅读量为 250 亿

再假设每 10 次阅读会产生 1 条评论，则每天微博的评论次数为 25 亿次

【性能估算】

每天有 4 个小时的时间内，产生的流量占全天的 60%，则高峰时段写微博评论的平均 TPS 为 25 亿*60%/(3*3600)=100K/s，即每秒 10 万条

二、架构设计

【业务特性分析】

微博评论属于写操作，因此不能使用缓存，但可以使用负载均衡

微博评论的用户对于业务的实时性要求不高，因此可以使用写缓冲来提升整体架构的资源利用率

【架构分析】

用户量过亿，应当要用多级负载均衡架构，覆盖 DNS→F5→Nginx→网关的多级负载均衡

写缓冲需要一个消息队列集群来作为缓冲队列，可以使用 Kafka、RocketMQ、Pulsar 等

【架构设计】

1.负载均衡算法选择

微博评论发送到任意服务器都可以，因此负载均衡可以选择“轮询”或者“随机”算法

2.消息队列集群选择

可以沿用公司现有技术栈，如果要新建的话，可以采用 Pulsar，来支撑后续的弹性扩缩容需求

3.服务器数量评估

业务服务器：微博评论的业务流程包括内容审核、数据写入存储、数据写入缓存

由于使用了写缓冲技术，我们把业务服务器集群分为两部分，一部分只用来完成缓冲队列的写入，另一部分用来完成业务流程

写缓冲服务集群，按照一台服务器 5000TPS 来估算，再加上一定的预留量，大约需要 25 台机器

业务处理服务集群，按照一台服务器 500TPS 来估算，需要完成 100K/s 的 TPS，需要 200 台机器，由于使用了写缓冲，机器数量的预留可以相对少一些，甚至不预留，需要的时候再扩容

消息队列集群，由于需要承载 100K/s 的 TPS 写入，按照一个 Pulsar 节点 10k/s 的写入速率来估算，再预留一部分资源，Pulsar 集群规模为 15 台机器

总计 240 台机器

4.热点事件高可用方案

针对微博 ID 维度产出评论令牌桶，评论前由客户端获取令牌，通过对令牌桶的限流进行业务量控制

令牌限流策略可动态调整，当超大规模热点事件发生时，系统根据令牌桶使用情况进行告警，进而要求人工介入，确定底层系统能力可支持后(扩容等)，可人工调大令牌桶限流数量

【架构图】