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

用户行为建模和性能估算

• 发评论

假设平均每人每天发表 20 次评论，则微博每天的评论发送量约为 50 亿条。

大部分的人发评论集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发评论总量占比为 60%，则这 4 个小时的平均发评论的 TPS 计算如下:

50 亿 * 60% / (4 * 3600) ≈ 200 K/s。

• 看评论

由于评论本身不是单独存在的，只能通过看微博的方式进行查看，并且可以分页，因此我们假设每条微博平均查看 50 页的评论，则看评论的次数为：

250 亿（观看微博的次数） * 50 = 7500 亿

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

7500 亿 * 60% / (4*3600) = 50000K/s。

高性能计算架构设计

发评论

业务特性分析

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

架构分析

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

架构设计

1. 负载均衡算法选择

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

2. 业务服务器数量估算

发评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，因此按照一个服务每秒处理 500 来估算，完成 200K/s 的 TPS，需要 400 台服务器，加上一定的预留量，480 台服务器即可。

看评论

业务特性分析

看评论是典型的读场景，由于发送后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

架构分析

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

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

架构设计

1. 负载均衡算法选择

任何人都能看微博及评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法

1. 业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下的 10%的读请求进入系统，则请求 QPS 为 50000K/s * 10% = 5000K/s。读取逻辑较为简单，用户也不太关注具体的分页，因此可以存在分页误差，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 5000 台，按照 20%的预留量，最终机器数量为 6000 台。

整体架构设计

任务分配

双机房，三机房

任务分解

将发评论和看评论没必要分拆到不用的服务，发评论可以先直接存储到缓存中，再同步到数据库中，可以在一个服务中完成，可以降低存储的复杂度

评论的多级负载均衡整体架构

评论的多级缓存架构

微博评论热点事件高可用计算架构设计

用户行为建模和性能估算

【转发和回复评论】

评论的转发会远低于微博的转发，假设有 0.1%的围观用户会在事件发生后 60 分钟转发或者回复评论

【看评论】

与看微博相同，很难预估

业务特性分析

【转发评论】

转发评论与转发微博为同一业务，转发的微博重要性和影响力不如原微博及评论。

【发评论】

发的评论仅在微博下可见，重要性低于转发。

【回复评论】

回复的评论不会直接显示，需要进一步展开，因为重要性远远低于原评论

【看评论】

热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。因而会导致该微博的评论的请求量会随之极大的增加。

架构设计分析

【转发评论】

本质上是转发微博，在转发微博中中处理

【发评论】

发的评论仅在微博下可见，重要性和影响力不如原微博，可以考虑对“转发微博”限流，由于转发能带来更好的传播，因此尽量少丢弃请求，考虑用“漏桶算法”。

【回复评论】

与转发评论类型，重要性和影响力更低，处理方式可以一致。

【看评论】

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

架构示意图