发微博评论

2020．9 月日活 2.24 亿（≈2.3 亿），假设每人只发一条微博。

非热点事件的评论，5 条以内。

每天构成热点事件的微博不超过 20 条，热点事件的评论，五千万条以上

由于热点事件的条数不多，基数可以忽略。日评论条数，

2.3 亿*5 + 20*0.5 亿 ≈12 亿+10 亿=22 亿。

大部分人发微博集中在早上 8~9 点，中午 12~13 点，晚上 20~22 点，假设这几个时间段发微博总量占比 60%，60%的评论在发微博后一小时以内，这 6 小时平均发微博评论的 QPS 计算如下：

22 亿*60%*60% / (6*3600) ≈ 37k/s

发微博评论是写操作，不用（先写）缓存，可以负载均衡。

用户量过亿，应该要用多级负载均衡。

负载均衡算法选择

发微博评论依赖登录状态，登录状态一般保存在分布式缓存中。发微博评论时，可以把请求发送给任意服务器，这里选择“轮询”或者“随机”算法。

业务服务器数量估算

发微博评论涉及几个关键处理：内容审核（依赖审核系统），数据写入存储（依赖存储系统），数据写入缓存（依赖缓存系统）。几个关键处理不需要额外机器。可以写缓冲，不用直接写存储，因为评论的实时性相对不重要。按一个服务器 500 QPS，完成 37k/s QPS，需要 74 台服务器，加上预留量，50 台服务器处理发微博评论。

看微博评论

2020．9 月日活 2.24 亿（≈2.3 亿），假设每人只发一条微博。

非热点事件的评论，5 条以内，每条评论被查阅 20 次。

每天构成热点事件的微博不超过 20 条，热点事件的评论，五百万条以上（从五千万条降级，方便分析。），每条评论被查阅 10 万次。

大部分人发微博集中在早上 8~9 点，中午 12~13 点，晚上 20~22 点，假设这几个时间段发微博总量占比 60%，非热点事件评论前一小时的查阅率：20%，热点事件评论前一小时的查阅率：60%。这 6 小时平均发微博评论的 QPS 计算如下：

(2.3 亿*5*20*20% + 20*0.05 亿*100,000*60%) *60% / (6*3600) =60,048 亿*60% / (6*3600)≈ 1.668 亿/s

看微博评论是读场景，发微博评论后不能修改，适合用缓存架构。由于请求量大，需要负载均衡架构。

用户量过亿，应该要用多级负载均衡，

请求量达到了 60,048 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

负载均衡算法选择

游客都可以直接看微博评论，请求发送给任意服务器都可以，选择“轮询”或“随机”（负载均衡）算法。

业务服务器数量估算

假设 CDN 承受 90%的用户流量，剩下 10%流量进入系统，则请求 QPS 为 1.668 亿/s * 10% = 166.8 百万/s。读微博不需要额外的处理逻辑，压力主要在缓存系统。假设单台业务服务器处理能力是 1000/s，需要 166,800 台，按照 20%的预留量，最终机器数量为 200,160 台。

热点事件

“多副本缓存” & 应用内缓存 & 令牌桶限流 去保证相对高可用。

没法把非热点事件的处理单独拆分，因为无法预测哪些时间会成为热点事件。只能在整体架构上，尽量高性能。