架构实战营模块五作业 - 微博评论高性能高可用架构

评论微博用户行为建模和性能估算

【用户量】

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

【评论微博】

评论微博一般是在看微博的基础之上，经评估观微博的次数为：2.5 亿*100=250 亿。假设评论微博是每 100 次才有一次评论，那评论微博每天的量大约是 2.5 亿条。大部分人的评论时间是早上 8：00 ~ 9：00 、中午 12：00 ~ 13：00、晚上 20：00 ~ 22：00，假设这段时间的评论数量占到微博总评论数量的 60% 那么，这 4 个小时平均发微博评论的 TPS 计算如下：2.5 亿*60%/(4 * 3600) ≈10K/s

业务特性分析

评论微博是一个典型的写操作，因此不能用缓存，可以使用负载均衡。

架构分析

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

架构设计

1、负载均衡算法选择

评论微博的时候被评论的微博，这种关系都持久化在数据库中，因此评论微博的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2、业务服务器数量估算

评论微博与发微博类似，同样涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 10K/s 的 TPS，需要 20 台服务器，加上一定的预留量，25 台服务器。

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

事件热点

1、针对事件热点，建议可以使用类似于 Kafka 这类消息中间件对热点事件进行一个缓冲，起来削峰的效果。

2、要么就是在架构层针对这种突发事件能支持弹性伸缩来支撑这种热点事件。

3、做兜底策略，如熔断、限流、降级，确保关键核心业务可用。