微博评论的高性能高可用计算架构方案

（一） 计算性能说明

1. 用户量预估

根据微博发布的 2022 年一季度财报，日活跃用户达到 2.52 亿用户。即用户的基数为 2.52 亿

2. 行为建模

用户发布评论微博信息，大部分是针对于明星或者新闻信息，预计每一条微博，平均大约 10 人会有 1 人发布评论左右。用户每天查看评论频率会比用户看微博的频率低，即每天查看评论大约 10 人会有 2 人次左右。

3. 性能估算

发布评论： 2.52 亿 * 60% /（4 * 3600）* 0.1 * 0.8 = 800/S

查看评论： 2.52 亿 * 60% /（4 * 3600）* 0.2 * 0.8= 1.6K/S

注： 80%的评论发生在发布微博之后产生的。

(二) 分析

1. 功能分析

• 对于用户发布的评论，对于时效性要求并不高，可以缓存存储和负载均衡策率。

• 对于用户查看评论，可以通过本地缓存以及 CDN 等缓存手段和负载均衡策率。

• 对于用户来说发布和查看评论在同一页【同一场景触发】，因此将两个功能合并成一个应用服务，不再进行拆分。

2. 负载架构建议

用户的数量较大，应该使用多级负载均衡架构，主要为 DNS -> F5 -> Nginx ->网关的多级负载均衡架构。

3. 缓存架构建议

用户的评论数据的时效性要求不高，无论是发布评论还是查看评论均可以采用缓存临时存储处理。

（三）设计

1. 负载均衡算法选择

微博通过分布式共享缓存进行存储个人账户的基础信息，用户评论数据可以随意负载到任何一台服务器上，负载均衡的算法可以选择随机和轮询模式。

2. 业务服务器数量估算

微博评论服务采用微服务多机部署的模式，其处理过程包含 内容审核、写入缓存、数据入库，因此预估每台服务器能每秒处理 1K/s，根据预算分析的性能指标为 800/S[发布评论]、1.6K/S[查看评论], 因此预估要用 18 台服务器[有一定的冗余]。

（四）高性能架构设计说明

1. 负载架构设计如下：

• 微博用户大部分是通过手机 App[微博]，建立 HttpDNS 服务端[也是集群话部署模式]用于应用的高效负载。

• 建立四层负载均衡结构，分别为 DNS(HttpDNS)层、硬件负载层(F5/A10)、软件负载层（Nginx）、应用网关负载层。

发布评论和查看评论负载架构图

2. 多级缓存设计架构设计架构如下：

通过本地缓存保留部分原有的浏览信息[评论是按照时间排序的]，其中评论的内容可以在应用服务到的进程内缓存进行存储【业务的时效性较低】。

（五）高可用架构设计说明

1. 热点事件分析：

评论：热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。会在此微博内容下会有大量的评论。

2. 技术架构分析：

对于写评论本身已经采用缓存处理机制，对于出现热点问题应该不会有特殊的表现。对于看评论，可以将评论数据以 zset 数据结构存储在 redis 中，在每一个副本中进行存储，这样应用在读取的时候可以提供高可用。之后应用定期更新 zset 中的数据。