微博评论高性能高可用方案设计

一、性能需求估算

用户量预估

用户量：

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

关键行为

• 发评论：支持回复楼层、楼中楼

• 读取评论：按照时间、热度排序

有热点突发事件

用户行为建模和性能估算

发评论

微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博，则微博每天的发送量约为 2.5 亿条。假设每条微博评论为 3 条，则评论数为 7.5 亿条。

大部分的的人发微博在早上 8：00-9：00，中午 12：00-13：00，晚上 20：00-22：00，假设这几个时间段的评论数占比 60%，则这 4 个小时平均发评论的 TPS 计算如下：

7.5 亿 60%/(43600) 约等于 30K/s

看评论

由于绝大部分用户看评论的对象是大 V 和明星，因此假设平均一条评论的观察人数有 100 次，则观看次数为：

7.5 亿*100 = 750 亿。

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

750 亿 60% /(43600) = 3000K/s

热点事件

热点事件是指某个大 V 或者明星，虽然只有一两条微博，但因其大量用户在短时间内评论和访问评论。

• 发评论造成热点事件的微博可能就 1-2 条，假设有 10%的用户会在 60 分钟内评论

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

性能需求汇总

• TPS 约等于 30K/s

• QPS 约等于 3000K/s

二、评论高性能架构设计

发评论

• 业务特性分析发评论是一个典型的写操作，因此不能使用缓存，可以使用负载均衡和 CDN 动态加速。

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

• 架构设计

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

2. 业务服务器估算发评论设计几个关键的处理：内容审核、数据写入存储、数据写入缓存，因此按照一个服务器每秒处理 500 来估算，完成 30K/s 的 TPS，需要 60 台服务器，加上一定的预留量，选择 65 台服务器。

发评论多级负载均衡架构：

看评论

• 业务特性分析看评论是一个典型的读场景，由于评论发了不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡也需要。

• 架构分析用户量过亿，应该使用多级负载均衡架构和 CDN 服务

• 架构设计

1. 负载均衡算法选择游客可以直接看评论，因袭将请求发送给任务服务器都可以，选择轮询或者随机算法

2. 业务服务器数量估算假设 CDN 的命中率在 98%，剩下的 2%读评论系统请求进入系统，则请求 QPS 为 3000K/s * 2% = 60K/s,由于读评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1K/s,则机器数量为 60 台，按照 20%的预留量，最终机器为 80 台。

多级负载均衡架构

多级缓存架构

整体架构设计

评论业务

• 任务分配

• 双机房

• 三机房

• 任务分解

• 将发评论和看评论分拆到不同服务

App 解析的时候优先使用 DNS 解析，如果 DNS 出现不精准，或者劫持等情况，使用 HTTPDNS 进行解析。

三、热点事件设计

• 业务特性分析

• 发评论和一般的发评论类似

• 看评论热点事件发生后，绝大部分评论都落在了热点事件的那一条微博下的评论

• 架构设计分析

• 发评论可以考虑对评论进行限流，由于评论最好不要丢弃，因此尽可能少的丢弃请求，考虑用漏桶算法

• 看评论热点事件的评论也可能存在热点问题，可以使用多副本缓存，由于原来的架构本身已经采用了应用内的缓存，总体上来看，缓存热点问题不一定很突出

发评论漏桶算法

热点评论

所有副本的生成时间和失效时间添加一个随机值，避免同时生成，同时失效。预留方式可以添加热点 key 缓存。以系统判断为辅助。人工执行操作。在内存中使用 hashmap 统计每个 key 的访问频次，使用滑动窗口统计，在每个窗口中维护一个 hashmap，之后统计所有未过去的 bucket，汇总所有 key 的数据，然后使用小堆计算 topk，进行热点识别。