微博评论 - 高性能、高可用计算架构分析与设计

1、用户行为建模和性能估算

1.1 - 用户量

• 2020.9 月月活 5.11 亿、日活 2.24 亿（参考《微博 2020 用户发展报告》）

• 关键行为分类：发微博评论、看微博评论

1.2 - 发微博评论（非热点）

考虑到微博评论是一个看得多发的少的业务，假设平均每天每人发 5 微博评论，则微博评论每天的发送量约为 12.5 亿条。大部分的人发微博评论集中在早上 8:00~9:00、中午 12:00~13:00、晚上 20:00~22:00，假设这几个时间段发微博评论总量占比为 60%，则这 4 个小时的平均发微博评论的 TPS 计算如下：

• 12.5 亿 x 60% / (4 x 3600) = 52 K/s

1.3 - 看微博评论（非热点）

由于绝大部分用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次。

• 而这 100 次当中，大多数情况不会点开微博评论。

• 假设每 100 次看微博中，仅有 10 次点开微博评论。

• 假设在点开评论的时候，平均查看 10 条评论。

• 2.5 亿 x 100 / 10 x 10 = 250 亿

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

• 250 亿 x 60% / (4 x 3600) = 1000 K/s

1.4 - 热点事件微博

热点事件指某个大 V 或者明星爆料或者官宣，一般只有 1、2 条微博。

但这 1、2 条微博会引起大量用户在短时间内访问，给系统造成很大压力。

• 发微博评论：

• 造成热点事件的微博本身只有 1、2 条，但是用户围观后会有很多评论。

• 假设有 15% 的围观用户会在事件发生后 60 分钟内发布评论。

• 看微博评论：

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

2、微博评论高性能计算架构（非热点）

2.1 - 发微博评论（非热点）

业务特性分析

• 发微博评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。

架构分析

• 用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关 的多级负载均衡。

架构设计

• 负载均衡算法选择：

• 发微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的。

• 因此发微博评论的时候，将请求发送给任意服务器都可以，这里选择轮询或随机算法，大道至简。

• 业务服务器数量估算：

• 发微博评论涉及几个关键的处理：内容审核、数据写入存储、数据写入缓存。

• 因此按照一个服务每秒处理 500 次请求来估算，完成 52 K/s 的 TPS，需要 105 台服务器。

• 按照 20% 至 25% 的预留量，最终机器数量为 130 台。

2.2 - 看微博评论（非热点）

业务特性分析

• 看微博评论是一个典型的读场景，因此非常适合用缓存架构。

• 同时由于请求量很大，负载均衡架构也需要。

架构分析

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

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

架构设计

• 负载均衡算法选择：

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

• 业务服务器数量估算：

• 假设 CDN 能够承载 90% 的用户流量，那么剩下 10% 的读微博评论的请求进入系统。

• 则请求 QPS 为 1000 K/s x 10% = 100 K/s

• 由于读微博评论的处理逻辑比较简单，主要是读缓存系统。

• 因此按照一个服务每秒处理 1000 次请求来估算，则机器数量为 100 台。

• 按照 20% 的预留量，最终机器数量为 120 台。

2.3 - 微博评论整体架构（非热点）

业务整体架构

• 发微博评论、看微博评论 -> 拆分到不同服务。

多级缓存整体架构

• 评论具有时间局部性：

• 自己的评论

• 时事的评论（翻非常老的微博看评论的情况不多）

• 增加进程内缓存虽然加大了复杂度，但可以很好地加速读取时间局部性数据。

多级负载均衡整体架构

• 结合上述发微博评论、看微博评论的整体架构，得出汇总后的多级负载均衡架构如下：

3、微博评论高可用计算架构（热点）

• 用户行为建模和性能估算详见上述 1.4 热点事件微博分析。

• 热点高可用架构核心思想：既然无法预估，那就做好预防！

3.1 - 业务特性分析（热点）

• 发微博评论：

• 热点事件发生后，会有大量评论涌入，但评论的重要性不如热点微博本身。

• 看微博评论：

• 热点事件发生后，绝大部分请求都落在导致热点事件发生的那 1、2 条微博及其评论上面。

3.2 - 架构设计分析（热点）

• 发微博评论：

• 热点微博评论的重要性和影响力不如原微博，可以考虑对其进行限流。

• 考虑采用：写入缓冲 + 消息队列 + 漏桶算法。

• 看微博评论：

• 很明显热点事件微博及其评论存在缓存热点问题，可以考虑多副本缓存。

• 由于原有的缓存架构已经采用了应用内的缓存，总体上来看缓存热点问题其实不一定很突出。

3.3 - 微博评论整体架构（热点）