写点什么

架构实战营模块五作业

作者:alan
  • 2022 年 1 月 15 日
  • 本文字数:818 字

    阅读完需:约 3 分钟

作业题目

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

【作业要求】

基于模块 5 第 6 课的微博实战案例,分析“微博评论”这个核心场景的业务特性,然后设计其

高性能高可用计算架构,包括但不限于如下内容:

1. 计算性能预估(不需要考虑存储性能);

2. 非热点事件时的高性能计算架构,需要考虑是否要拆分独立的服务;

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

【提示】

1. 分析方法对照“看微博”和“发微博”的案例。


作业内容

性能预估

发微博人均每天一条,看微博平均每条 100 次,微博评论介于这两者直接,预估为每条微博评论为 10 条,则每天评论总量为:

2.5 亿*10=25 亿条


微博评论和发微博看微博时间分布一致,都是集中在早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00,假设这几个时间段发微博总量占比为 60%,则这 4 个小时的平均微博评论的 TPS 计算如下:

25 亿 * 60% / (4 * 3600) ≈ 100 K/s。


高性能计算架构

服务拆分

考虑到微博评论数量的不确定性,热门微博的评论数量远远高于普通微博,故将评论拆分为独立的服务,以提升性能和可用性。

业务特性分析

微博评论和写微博类似,使用负载均衡。

架构分析

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

架构设计

1. 负载均衡算法选择

微博评论的时候依赖登录状态,可选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

微博评论和写微博类似,但业务复杂度更低,故按照一个服务每秒处理 1000 来估算,完成 100K/s 的 TPS,需要 100 台服务器,加上一定的预留量,最终为 120 台服务器。

负载架构图

多级负载架构基本和发微博一致,基本如下:


高可用计算架构

微博评论重要性和影响力不如原微博,当发生热点事件时,可以考虑对“微博评论”限流,尽量少丢弃评论请求,考虑用“漏桶算法”。

为降低对业务的影响,尽可能减少丢弃评论请求的数量,考虑将消息队列的长度尽可能设置大,提高系统冗余性。

其漏桶算法的高可用架构图和发微博高可用架构图基本一致,不再赘述。


用户头像

alan

关注

还未添加个人签名 2021.11.02 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块五作业