模块五作业

设计微博系统中”微博评论“的高性能高可用计算架构。

参考微博用户报告 ：

看评论

写评论

1.2 用户行为建模和性能估算

1.2.1 写评论

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 5 条微博评论，则微博每天的发送量约为 12.5 亿条。

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

8.5 亿* 70% / (4 * 3600) ≈ 40 K/s。

1.2.2 看评论

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

4.5 亿* 100 =450 亿。

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

450 亿* 70% / (4*3600)≈2187 K/s。

翻页看非首页评论的平均 QPS 预计为看首页热门评论 QPS 的十分之一，记 100K/s。

2. 发评论非热点事件时的高性能计算架构

2.1 业务特性分析

发微博评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。考虑到微博评论写入的时效性要求不高，可以采用消息队列作为缓冲，异步消费微博评论写请求。2.2 架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 App/Browser -> DNS -> F5/LVS -> Nginx -> API 网关的多级负载均衡。2.3 架构设计

2.3.1 负载均衡算法选择

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

2.3.2 业务服务器数量估算

假设一个服务器的处理能力是 500 每秒，则处理 50k/s 的 TPS 需要 100 台服务器，加上一定量的预留量，共 120 台。

2.3.3 发微博评论的多级负载均衡架构

3. 看评论非热点事件时的高性能计算架构

3.1 业务特性分析

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

3.2 架构分析

1. 用户量过亿，应该要用多级负载均衡架构；

2. 请求量达到 250 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。3.3 架构设计

3.3.1 负载均衡算法选择

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

3.3.2 业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博热门评论的请求进入系统，则请求 QPS 为 1000K/s * 10% = 100K/s，此外翻页读取微博的 QPS 需求估算为 100K/s，考虑到所有翻页读取微博的请求全部回源，则总 QPS 为 200K/s， 由于读取微博评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 200 台，按照 20%的预留量，最终机器数量为 240 台。

3.3.3 读微博评论的多级负载均衡架构

3.3.4 读微博评论的多级缓存架构

此处需要注意 CDN 缓存刷新策略，热门评论列表 CDN 缓存可以采用设置 TTL 刷新，但点赞数需要用异步刷新的方式缓存到 CDN 作为单独副本，TTL 刷新时间比评论列表短。另外当有用户删除评论或者微博发布者开启评论精选，则需要具备手动 by id 刷新微博评论列表缓存或者刷新是否展示评论列表的标志位。

4. 热点事件微博评论高可用计算架构设计

4.1 写微博评论

用消息队列实现写缓冲，当队列堆积到达到上限的时候开始丢弃消息。

此处也可以考虑使用 NSQ 作为消息队列组件，在热度起来的时候通过容器的 HPA 机制或者手工干预做到队列的弹性扩容

4.2 读微博评论

读微博评论的缓存本身采用多副本缓存方案。

1. 写入的时候，缓存的 Key 加上编号，写入到多个缓存服务器；

2. 读取的时候随机生成编号组装 Key，然后读取。

当然，为了应对不可预估的热 key 导致的集群负载过高的情况（即使包含 CDN 边缘节点），可以增加熔断和降级机制，即完全不刷新最新评论的 CDN 副本，或者 CDN 侧对评论读请求进行限流（基于目前集群负载的动态限流）。