评论微博计算性能预估

1. 用户量预估

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

2. 关键行为

写评论、回复他人评论、删除自己的评论

看评论

3. 性能预估

（1）写评论、回复他人评论、删除自己的评论

由于绝大部分微博用户看/评论微博的对象是大 V 和明星，因此我们假设看微博的用户有 10%会进行评论，那么平均一条微博评论人数有 10 次，则评论微博的次数为：2.5 亿 * 10 = 25 亿。

大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，大部分人评论微博的时间段和发微博的时间段基本重合，因此评论微博的平均 TPS 计算如下：25 亿 * 60% / (4*3600) = 100K/s。

（2）看评论

由于绝大部分微博用户看微博评论的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，评论与微博一同请求，则观看微博评论的次数为：2.5 亿 * 100 = 250 亿。

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

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

4. 是否拆分独立的服务

写评论和看评论业务区别较大，比如写评论不能用缓存，看评论很依赖缓存。拆分为写评论服务和看评论服务。

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

1. 写评论、回复他人评论、删除自己的评论

（1）业务特性分析

都是写操作，希望及时能看到，因此不能用缓存，可以用负载均衡。

（2）架构分析

请求量达到十亿级别，秒并发十万，要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

（3）架构设计

负载均衡算法选择

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

业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上一定的预留量，250 台服务器差不多了。

2. 看评论

（1）业务特性分析

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

（2）架构分析

请求量达到百亿级别，秒并发百万，要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

（3）架构设计

负载均衡算法选择

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

业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博评论的请求进入系统，则请求 QPS 为 1000K/s * 10% = 100K/s，由于读取微博评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量为 120 台。

3. 微博高性能计算方案 - 整体架构设计

任务分配 - 双机房、三机房

任务分解 - 写评论、看评论

拆分不同服务

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

看微博评论的多级缓存整体架构

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

1. 写评论

热点事件突发，评论量会显著上升。由于在发布评论业务中，引入了写缓冲，系统不会有宕机的危险，但用户体验会下降，因为能刷到自己评论的时间会等更久。

2. 看评论

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