1. 性能估算

微博评论可以分为发表评论和查看评论两大操作。

2020.9 月微博日活为 2.24 亿，下面按照 2.5 亿估算。假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。

大部分人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，共 4 小时，发表评论和查看评论的操作也集中在这几个时间段，假设这几个时间段发表评论和查看评论总量占比为 60%。

1.1 发表评论

假设平均一条微博观看人数有 100 次，其中 10%的人会发表评论（包括对评论进行评论，对评论进行回复等），那么发表评论的 TPS 为：

2.5 亿*100*10%*60%/(4*3600)≈104K/s，按照 110K/s 进行估算。

1.2 查看评论

假设平均一条微博观看人数有 100 次，假设观看微博的人，同时会观看评论。评论按照发表时间，观看人数从 100 到 1 不等，假设每条评论平均有 50 人观看，那么查看评论的 QPS 为：

2.5 亿*100*10%*50*60%/(4*3600)≈5208K/s，按照 5300K/s 进行估算。

2. 架构设计

2.1 发表评论

一、业务特性分析

发表评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。由于发表评论到查看评论可以有一定的时间延迟，且高峰期发表评论的峰值较高，所以可以使用写缓冲的方式，以保证评论不丢失。

二、架构分析

1、由于用户量过亿，应采用 4 级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

2、由于发表评论的峰值较高，评论尽量不丢失，且从发表评论到查看评论可以有一定的时间延迟，所以在发表评论的时候，可以在后台服务中使用写缓冲。

三、架构设计

1. 负载均衡算法选择

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

2、写缓冲说明

在后台服务中处理发表评论请求的时候，可以使用写缓冲的方式进行限流，通过设置容量较大漏桶，缓存所有发表评论的请求，供后台服务匀速处理，防止在请求较多的情况下，后台服务出现雪崩效应，导致评论丢失。

3. 业务服务器数量估算

发表评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统）。按照一台服务每秒处理 500 请求来估算，完成 110K/s 的 TPS，需要 220 台服务器，加上一定的预留量，250 台服务器应该可以满足要求。

2.2 查看评论

一、业务特性分析

查看评论是一个典型的读场景，由于评论发表后不能修改，因此比较适合用缓存架构，但是由于同一条微博的评论会增加，所以要考虑缓存的更新。同时由于查看评论的请求量很大，所以也需要负载均衡架构。

二、架构分析

1. 由于用户量过亿，应采用 4 级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

2. 请求量超过每秒 500 万次，应该要用 5 级缓存架构，覆盖 本地缓存-> CDN 缓存 -> Web 容器缓存 -> 进程内缓存->分布式缓存。同时考虑缓存的刷新，以便及时查看新增的评论。

三、架构设计

1.负载均衡算法选择

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

2.缓存更新说明

在分级缓存中，分布式缓存、进程内缓存和 CDN 缓存比较重要。

（1）分布式缓存，在发表评论的时候，在将评论保存到数据库的同时，要更新分布式缓存。

（2）进程内缓存，查看评论服务主要是从分布式缓存中读取评论信息，并将评论缓存在进程内缓存中，为了及时查看新增的评论信息，将进程内缓存设置为定时更新，周期为 2 分钟。

（3）CDN 缓存，CDN 缓存中也会缓存评论信息，为了及时查看新增的评论信息，将 CDN 缓存设置为定时更新，周期为 5 分钟。

3. 业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的查看评论的请求进入系统，则请求 QPS 为 5300K/s * 10% = 530K/s，由于查看评论的处理逻辑比较简单，主要是读进程内缓存或分布式缓存。假设采用进程内缓存后单台业务服务器处理能力能提升 20%，为 1200/s，则服务器数量为 442 台，按照 20%的预留量，最终服务器数量为 530 台。

假设采用进程内缓存后，进程内缓存可以承载 50%的用户流量，那么剩下 50%的查看评论请求会进入分布式缓存，则请求 QPS 为 530K/s * 50% = 265K/s，假设分布式缓存单台 QPS 为 5 万计算，则服务器数量为 6 台，按照 20%的预留量，最终服务器数量为 8 台，组成集群，可以满足评论写入和读取的性能需求。

2.3 多级负载均衡设计

将服务拆分为发表评论和查看评论两大部分，并增加分布式缓存。

系统可以部署在多个中心。

2.4 多级缓存设计

CDN 缓存和进程内缓存分别设置不同的定时刷新时长，分布式缓存与数据库同步更新。

2.5 高可用设计

一、发表评论

发表评论的重要性和影响力不如原微博，可以考虑对发表评论进行限流，并尽量少丢弃请求，考虑用带缓冲的“漏桶算法”。

二、查看评论

热点事件微博存在缓存热点问题，可以考虑“多副本缓存”，由于缓存架构已经采用了“CDN 缓存、进程内缓存、分布式缓存”三类缓存实现了评论的缓存，总体上来看，缓存热点问题其实不一定很突出。