微博评论计算架构

1. 业务背景

微博用户看完微博时常也需要进行评论，针对绝大部分微博用户看微博的对象是大 V 和明星，他们的微博可能是常规微博、偶尔也可能是热点事件，对应的微博评论则可能是常规评论、也可能是热点评论。

2. 约束与限制

暂无

3. 总体架构

3.1 架构分析

3.1.1 性能估算

【用户量】

1. 2020 年 9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）

【关键行为】

发评论

看微博的 tps 为 1000k/s，假定 10%的用户都会进行评论，则发评论微博的 tps 为 100k/s。

看评论

看微博的 tps 为 1000k/s，假定 10%的用户会看评论，则看评论微博的 qps 为 100k/s。

3.1.2 评论微博高性能

【发评论-业务特性分析】

评论微博是写操作，由于评论完微博，评论内容通常也是被别人的评论给刷掉，所以它的及时性要求并不是很高，可以进行写缓冲操作。

【发评论-架构分析】

1、用户量过亿，应该要用多级缓存架构；

2、评论是及时性不高的写操作不设计多级缓存，但可以进行写缓冲。

【发评论-架构设计】

1、负载均衡算法选择

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

2、业务服务器数量估算

评论微博设计几个关键的处理：数据写入缓冲（依赖写入缓存系统），内容异步审核（以来审核系统），

数据异步写入存储（依赖存储系统），按照一个服务每秒缓存 10k 个请求的评论内容来估算，完成 100k/s 的 tps，需要 10 台的服务器，加上一定的预留量，大致安排 15 台服务器。

多级负载均衡架构

【看评论-业务特性分析】

看评论也是典型的读操作，业务特性基本类似于看微博。

【看评论-架构分析】

1、用户量过亿，应该要用多级缓存架构；

2、采用多级缓存架构。

【看评论-架构设计】

1、负载均衡算法选择

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

2、业务服务器数量估算

看评论虽然跟看微博都是读操作，但是看评论一般不进行 cdn 缓存，所以服务器集群需要承载 100k/s 的 qps，假定一台服务器可以处理 1000/s 的读评论请求，所以需要 100 台的服务器；

多级负载均衡架构

多级缓存架构

3.1.3 评论微博可扩展性

【业务特性分析】

评论微博，有着明显区别于发微博、看微博的业务特性，看微博属于读操作，发微博跟评论微博都是写操作，但是评论微博由于业务及时性并没有发微博那么高，评论微博采取了写缓冲操作流程，因此可将评论微博模块拆分成独立的服务，即评论服务。评论服务里面包含发评论和看评论，由于发评论一般是缓存操作跟异步处理操作，操作量较轻，所以看评论可以共用同一个服务。

【架构分析】

架构的可理解性（拆分形态/拆分力度）上也是合适的，同时，内外部也是平衡。

【架构设计】

独立的评论服务

3.1.4 评论微博高可用

【热点事件性能估算】

看微博的 tps 为 1000k/s，热点事件假定 100%的用户都会进行发评论，则发评论微博的 tps 为 1000k/s。

看微博的 tps 为 1000k/s，热点事件假定 100%的用户都会看评论，则看评论微博的 qps 为 1000k/s。

【热点事件架构分析】

热点事件无法进行预测，则采用预防。

发评论

在服务器承载范围内，采用尽量少丢失丢弃请求的方法，考虑用“漏桶算法”。

看评论

热点事件存在缓存热点问题，考虑用“多副本缓存”。

【热点事件架构设计】

3.2 总体架构

整体架构

整体多集负载均衡架构