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

（一） 计算性能说明

•  用户量预估

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

• 行为建模

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

• 性能估算

 发布评论： 2.52亿 

* 60% /（4 * 3600）* 0.1 *

 

0.8 = 800/S

 查看评论： 2.52亿 

* 60% /（4 * 3600）* 0.2 *

 

0.8= 1.6K/S 

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

(二) 分析

• 功能分析

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

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

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

• 负载架构建议

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

• 缓存架构建议

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

（三）设计

• 负载均衡算法选择

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

• 业务服务器数量估算

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

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

• 负载架构设计如下：

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

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

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

• 多级缓存设计架构设计架构如下：

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

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

• 热点事件分析：

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

• 技术架构分析：

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