前言

词汇表

1. 业务背景

2. 约束和限制

3. 总体架构

3.1 架构分析

从微博评论功能的整体复杂度来看，微博评论是属于业务复杂度不高但质量复杂度较高的系统，主要体现在：

1）微博评论主要是评论写入操作，写入后与该条微博关联，其他用户或评论微博本人可以查看到该条微博，但可以不需要实时其中涉及评论内容审核、微博评论写入存储和同步到缓存，业务流程简单，周期短。

2）根据日活数量和看微博次数，可以很容易推断出微博评论次数以及微博写入的 TPS 较高，且微博评论支持图文评论，因此对系统计算和存储高性能、高可用方面要求较高，挑战较大，并且热点事件的不可预估性更加剧了系统的质量保障难度。

3）微博评论实时要求不高，用户对评论实时性的容忍度相对较高，所以计算性能上可以考虑限流和排队方案。

4）客户都希望自己的评论提交后能被看到，所以丢失评论的容忍度不会太高，所以计算和存储需要高可用方案。

5）客户访问微博时，需要关联获取微博评论，因此请求量较高，需要多级缓存架构。

3.1.1 微博评论高性能 - 非热点事件

1） 用户量估算

【用户量】

月活 5.11 亿，日活 2.24 亿

【关键行为】

评论微博

查看微博评论

2）用户行为建模和性能估算

【评论微博】

根据看微博的次数估算，假设平均每条微博观看人数中有 20%的人会评论微博，因此评论微博的次数为:

2.5 亿 X 100 X 20%= 50 亿

大部分人评论微博和发微博的时间段基本重合，因此评论微博的 TPS 估算如下:

50 亿 X 60% / (4*3600) = 250K/s

【查看微博评论】

假设平均每条微博有 20 条评论，而 20 条按分页查询通常 5 条一页，因此查看次数为：

2.5 亿 X 100 X (20/5) = 1000 亿

大部分人查看微博评论和发微博的时间段基本重合，因此评论微博的 QPS 估算如下:

1000 亿 X 60%/ (4*3600) = 4000K/s

3）架构分析

对于微博评论，需要采用多级负载均衡架构；

对于查看微博评论，由于 QPS 很高需要用多级负载均衡架构和多级缓存架构，尤其是 CDN 缓存应对微博评论查询，是缓存设计的核心。

4）架构设计

评论微博的时候依赖登录状态，登录状态都是保存在分布式缓存中，因此评论微博的时候，将请求发送给任意服务器就可以，因此负载均衡算法采用“轮询”或者“随机”算法。

微博评论涉及：内容审核，数据写入存储，数据写入缓存，因此按照每台服务器每秒处理 500 来估算，完成 250K/s 的 TPS，需要 500 台服务器。

查看微博评论，要用多级负载均衡架构。请求量较大，QPS 达到百万级别，并且评论一旦发布后不能修改，因此需要用多级缓存架构，而 CDN 是缓存设计的核心。如果 CDN 能承载 90%的用户量，那么剩下的进入到系统的请求为：400K/s, 对于读请求的处理速度，单台服务器可以达到 1000/s 英雌需要 400 台服务器，按照 20%预留，最终为 480 台。

3.1.2 微博评论高可用 - 热点事件

1） 用户量估算

同上

2）用户行为建模和性能估算

【评论微博】

由于是热点事件用户评论的次数和微博评论条数很难预估，主要取决于事件的影响力和影响范围有关。

【查看微博评论】

热点事件会导致单条微博及其评论被大量难以预估的用户访问以及重复访问，访问有可能集中发生在某个不确定的时间段，也有可能持续大量的高并发访问。

3) 架构分析

【评论微博】

微博评论实时性要求不高，所以可以进行限流，但用户对评论丢失容忍度较低，我们需要最大限度保障评论都能写入存储成功。所以可以考虑写缓冲漏桶算法，如 Kafka。

【查看微博评论】

避免热点事件带来缓存热点问题，要考虑分布式多副本缓存，将一个热点事件的所有评论根据 HASH 分片存入不同的缓存副本集，并且每个副本集又采用多副本缓存，保障性能和可用，如 Redis Cluster 架构。

另外也需要考虑查看限流，最好是滑动时间窗口限制 QPS。

3.2 总体架构

3.2.1 多级负载均衡架构

3.2.2 多级缓存架构

3.2.3 热点事件高可用架构

基于 3.2.1 和 3.2.3 架构基础上需要引入 Kafka 作为漏桶写缓冲，搭配 kubernetes 容器管理平台实现弹性扩缩容，应对热点事件评论不可预估的 TPS，并采用多副本缓存应对热评的请求。

4. 详细设计

4.1 核心功能

4.2 关键设计

4.3 设计规范

5. 质量设计

6. 演进规划