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

估算步骤-用户量预估

•【用户量】

1.2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)。

•【关键行为】

2. 评论微博。

用户行为建模和性能估算

【评论微博】

•考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博(只考虑文字微博)，则微博每天的发送量约为 2.5 亿条。

• 由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，假设有 4 分之一的人看了会评论，则评论微博的次数为:

•2.5 亿 * 100*0.25 = 62.5 亿。

•大部分人看微博的时间段和评论微博的时间段基本重合，因此看微博的平均 TPS 计算如下:

• 62.5 亿 * 60% / (4*3600) = 250K/s。

评论微博分析

•【业务特性分析】

•评论微博发了后不能修改，并且读多写少，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

•【架构分析】

•1. 用户量过亿，应该要用多级负载均衡架构;

•2. 请求量达到 62.5 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

•【架构设计】

•1.负载均衡算法选择 游客都可以直接看微博评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

•2. 业务服务器数量估算

•假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博评论的请求进入系统，则请求 QPS 为 250K/s * 10% = 100K/s，机器性能 1000/s，则机器数量为 25 台，按照 20%的预留量， 最终机器数量为 30 台台。

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

评论微博的多级负载均衡架构

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

评论微博的多级缓存架构

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

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

微博热点事件用户行为建模和性能估算

【评论微博】

•很难预估，和事件的影响力和影响范围有关。

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

微博热点事件业务特性分析

【评论微博】

•热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。

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

微博热点事件计算高可用架构分析

【评论微博】

•评论微博和看微博往往绑定在一起，热点事件微博存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题其 实不一定很突出。

•微博的评论可以不立即查看，因此可以通过排队来实现高可用