架构实战营模块五作业

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

计算性能预估

用户量预估

1. 2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)。

用户行为建模和性能估算

【发评论】

1.微博的用户行为数量应该是看微博>评论微博>发微博。评论微博是在看的时候就可能会评论，应该数量是比发微博多的。评论微博一般也不改。

2.一个用户只能同时评论一个微博，发一条评论，但可能会在一个微博下面连续评论多条。

3.假设平均每个用户每天发 10 条评论，可以评估出评论微博的次数为 25 亿。

评论微博的时间段和看微博的时间段和发微博的时间段基本重合，因此评论微博的 TPS 计算如下：

25 亿/3 / (4*3600) ≈ 50K/s

【看评论】

1.看微博评论和看微博差不多，非登录用户也可以看。

2.假设看微博的用户行为数量是看微博的 10%，根据第 6 课看微博的 qps 1000K/s，可以评估出看微博评论 qps 100K/s，可以复用看微博的架构，将评论数据和微博数据放在一起缓存。

非热点事件时的高性能计算架构

业务特性分析

1.评论微博是写操作，但是能用写缓冲，因为评论并不是微博里特别重要的内容，有一部分评论有延迟、看不到也没关系，用户也不太容易感知到。评论微博一般也不改。但是用户自己发的评论是需要立即能看到的。

2.评论微博比发微博的频率更高，流量仅次于看微博，所以也需要负载均衡架构。

架构分析

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

2.评论微博的 TPS 有 50K/s，所以要使用缓存架构，但是不像看微博量那么大，而且主要是文字内容，考虑到 TPS 很高，还是要使用多级缓存架构，层级不用像看微博那么多，CDN 缓存可以不用考虑。

3.评论数据的读写都可以在缓存上操作，然后同步到数据库中。

4.要支持互相评论的这种数据，要在应用内缓存做，cdn 缓存和 web 容器缓存都做不到这点。

架构设计

1.负载均衡算法选择

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

2.业务服务器量估算

评论微博涉及几个关键的处理:数据写入缓存(依赖缓存系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，因此按照一个缓存服务每秒处理 1000 来估算，完成 50K/s 的 TPS，需要 50 台服务器，加 20%的预留量，需要 60 台服务器。

评论微博缓存架构

热点事件时的高可用计算架构

微博热点事件用户行为建模和性能估算

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统造成很大压力。

【评论微博】

造成热点事件的微博自己只有 1~2 条，但是用户围观后会有很多评论，会有持续不断评论的情况。而且可能平时不评论的用户也会参与评论，假设有 20%的用户在事件发生的一小时内评论。

微博热点事件业务特性分析

【评论微博】

和看微博的场景一样，绝大部分请求都落在热点微博上。

微博热点事件计算高可用架构分析

热点事件微博存在缓存热点问题，对热点缓存有读有写。微博评论重要性和影响力不如原微博，评论有一定的延迟也没关系，可以使用多副本缓存和消息队列结合的方式。写评论使用消息队列，看评论使用缓存。

微博热点事件计算高可用架构示意图