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

一、用户行为建模和性能估算

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。

发评论性能估算

假设平均每人每天发 5 条评论,则每天的发送量约为 10 亿条, 评论的集中时间和发微博看微博的时间段一致

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

10 亿 * 60% / 14400 约等于 4 万/s

看评论性能估算

这里的看评论一般是指评论列表,而且绝大多数人只会看第一页评论, 所以这里假设看评论的次数和看微博的次数一致都是每人每天 100 次左右,看评论的时间和发评论、看微博的时间段基本一致,TPS 计算如下：

250 亿 * 60% / 14400 约等于 1000K/s。

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

发评论高性能计算架构设计

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡

负载均衡的算法可以采取轮询和随机

按照一台机器 500/s tps 来算, 大概需要 80 台机器, 算上预留量 100 台机器左右

看评论高性能计算架构设计

看微博是一个典型的读场景,适合 多级缓存架构 + 多级负载均衡架构

负载均衡的算法可以采取轮询和随机

缓存架构中 CDN 是重点,负责缓存热门微博的评论列表,基本只需要缓存列表的第一页即可

这里假设 CDN 承载了 90%的用户流量,剩下的 qps 大约是 100k/s, 因为查询操作业务简单,按照一台机器承载 1000/s qps 来算, 大概需要 100 台机器, 算上预留量大概 120 台机器左右

评论多级负载均衡架构

评论多级缓存架构

三、微博评论高可用计算架构设计

因为发评论和看评论都用到了负载均衡, 也属于高可用计算架构, 在此基础上, 发评论可以采取漏桶算法进行限流,尽可能少丢数据

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

对于发评论来说, 一条微博下的评论数量是有限的, 热点事件的问题并不突出

对于看评论, 可以考虑“多副本缓存”, 每个应用内部也有缓存, 也很好的起到了副本的作用