微博评论高性能高可用架构设计

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

计算性能估算

用户量估算

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。这里以 2.5 亿日活估算用户量。

用户行为建模和性能估算

本次作业设计常见是微博评论，包括发评论和看评论两个场景

1. 发评论

• 发评论前都必须是看微博。假设平均每天每人发 1 条微博，则每天有 2.5 亿条微博

• 绝大部分微博用户看微博的对象是大 V 和明星，假设平均一条微博观看人数有 100 次，看微博次数为：2.5 亿 * 100 = 250 亿

• 再假设只有十分之一的人会发评论，发一条评论，则 250 亿 / 10 = 25 亿

• 大部分的人看微博的时间为一天 4 小时看了 60%的总量，计算得发微博的 TPS：25 亿 * 60% / (4 * 3600) ≈ 100K/s

1. 读评论

• 假设每条微博观看的次数是 100，则观看微博的总次数为 2.5 亿 * 100 = 250 亿次

• 假设有五分之一的人看完微博后会浏览评论，则评论的观看次数为 250 亿 / 5 * = 50 亿

• 读评论的时间跟看微博的时间重合，读评论的 QPS 为：50 亿 * 60% / (4 * 3600) ≈ 200K/s

微博评论高性能计算架构设计

整体架构

1. 发评论和读评论分配到不同的服务。

2. 评论跟微博正文的不同之处是，允许评论发布时不用立刻看到，还有评论按照热度进行排序时，不要求排序精确。虽然读写评论的请求量大于读写微博，但根据这个特点，架构设计要适当考虑。

3. 任务分配给多机房。

发评论

1. 发评论是一个写操作场景，不能使用缓存，可以使用负载均衡。

2. 用户量过亿，采用多级负载均衡架构，覆盖 DNS -> F5 -> Ngnix -> 网关的多级负载均衡。

3. 负载均衡架构算法选择，参考发微博的架构设计，采用“轮询”或者“随机”算法就可以了。

4. 业务服务器数量估算

• 参考发微博的评估，发评论的处理包括内容审核、数据写入存储、数据写入缓存。但发评论与发微博一个不同点是，不要求发了评论要立刻看到，可以采用写缓冲技术（Buffer），用消息队列先把评论请求缓冲起来。

• 有写缓冲技术，一个服务的每秒处理的请求可以有所提升，假设提升两倍，每秒处理 1000 来估算，完成 100K/s 的 TPS，需要 100 台服务器，假设一定预留，120 台差不多。

读评论

1. 读评论是典型的读场景，采用缓存架构，由于请求量很大，负载均衡架构也需要。

2. 用户量过亿，采用多级负载均衡架构。

3. 请求量有 50 亿，采用多级缓存架构，App 内缓存+分布式缓存。

4. 大部分人不会所有评论都看，只会看最热门的几条评论，所以每次请求时，只请求最热门的前 20 条评论。

5. 负载均衡算法选择，选择“轮询”或者“随机”算法

6. 业务服务器估算

• 评论按照热度进行排序，缓存架构模式属于结果缓存，但是这个排序结果不需要太精确；分布式缓存一致性写操作方案采用先写存储后写缓存的方式，以提高读的性能。在缓存的评论允许与存储系统有一定时期的不一致。

• 评论按照热门排序，缓存可以只缓存最热门的 Top 条评论。如大多数人只会看前 20 条，预留空间，可以只缓存最热门的前 50 条评论。

• 评论的变化要比微博频繁，这里不考虑用 CDN 进行缓存。评论可以缓存在 APP 或者浏览器的缓存里面，这里占了大部分流量，假设有一半的流量是在客户端本地缓存就能读取，剩下一半才请求系统。请求读评论是读操作，只需要读缓存就可以了，每台机每秒请求按照 1000 来算，则 200K/s * 50% / 1000 = 100 台，按照 20%的预留量，最终机器 120 台。

负载架构图

缓存架构图

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

热点事件行为建模和性能估算

某个热门微博，可能会导致大量的评论发布和流量，短时间给系统造成压力。

1. 发评论

这里按照上面的假设不变，就是有十分之一浏览的人会发评论。由于热门微博的人浏览量很大，发评论的量随之也很大。因为受到看微博数量影响，很难预估。

1. 读评论

同上，也很难预估。

热点事件微博评论高可用架构分析和设计

1. 发评论

评论发表后不需要立刻看到，尤其是热门事件评论较多的情况。发评论采用写缓冲（buffer）的方式，采用大的消息队列，把写请求缓冲起来，后续处理。

1. 读评论

读评论有两个技术点：

• 一是读评论的请求次数，按照上面的假设，看微博的人数有 10 分之一的人会读评论，读评论的第一次请求（打开评论）数要比读微博低。可以参考课程里面读微博的高可用设计，热点事件使用“多副本缓存”。

• 二是热点事件的评论数较多，缓存保存有限，可以采用多级缓存保存的机制：应用内缓存保存前 20 条最热门的缓存，分布式缓存保存前 100 条，剩下请求的评论才落到存储系统。按照人的行为习惯，一般浏览前 20-30 条评论就不会再浏览下去，很少有全部评论都会看的情况。