写点什么

架构 -- 模块 5

作者:李某人
  • 2022-11-16
    天津
  • 本文字数:970 字

    阅读完需:约 3 分钟

已知:

2022 年 6 月末微博月活 5.82 亿,日活 2.52 亿,同比增加 700 万。

早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00。4 个小时为微博使用的高峰期。

性能估算:

估计每人每天平均浏览 100 条微博,单条微博浏览评论比按 80:1 估计,微博全天的流量 60%集中在高峰期 4 个小时。

则 2.52 亿*100/80 = 3.15 亿。即预估每日新增评论数约为 3.15 亿


315000000*0.6/(3600*4) = 13125,预估评论写入的峰值约为 13k,考虑到预估数据不准确并保留余量则估计活跃时段平均 tps 为 13k*1.5 约为 20k。


估计微博浏览评论比例 70% 则 2.52 亿*100*0.7*0.6/(3600*4),约为 735k,考虑估计误差,估算活跃时段平均 qps 为 800K。


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

由于评论具有明显的读多写少的特征且读写量差距很大,拆分服务可以保证性能。同时考虑读评论和读微博服务合并、写评论与发微博服务合并。

读评论

业务特性分析

评论一旦发出则不能修改,适合使用缓存架构,同时由于访问量巨大,负载均衡也很需要。

架构分析

用户量过亿,需要使用多级负载均衡架构

请求量超过 170 亿,需要使用多级缓存架构,由于评论不变的特性,优先使用 CDN 缓存。

架构设计

1、由于不登录微博也可以访问部分评论,因此请求发送给任意服务器即可,选择轮询或随机算法

2、假定 CDN 可以阻挡 90%的请求流量,则实际服务需要处理的 qps 为 80K,已知单台服务处理性能为 1000/s 则需要 80 台服务器(qps 估算时已经考虑余量)


写评论

业务特征分析

评论需要数据入库,写入场景,不使用缓存,但是需要使用负载均衡。

架构分析

要用多级负载均衡架构,覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

架构设计

1、评论发布时需要关联用户信息和被评论的微博信息,均在缓存中保存,因此直接使用轮询或随机的算法即可。

2、写操作服务器估算处理性能为 500/s,因此 TPS 为 20K 的写请求,需要使用 40 台服务器(估算 TPS 时已经保留余量,且由于新评论容错率更低,因此余量比例比读评论更高)


热点事件高可用计算架构

业务特性分型

1、热点事件的评论写请求绝大部分仅关联到指定的一条热点微博

2、热点微博的评论发出后通常会淹没在更多的评论中,实时性要求相对更低。

架构设计

1、写评论时可以使用漏桶算法或者消息队列等方式减少请求丢失,同时考虑前端限制单个用户评论的频率。

2、对于大多数读评论的情况,缓存机制可以覆盖。可以使用多副本缓存提升效率,极端情况下可以使用令牌桶对评论进行限流访问。


用户头像

李某人

关注

还未添加个人签名 2019-05-21 加入

还未添加个人简介

评论

发布
暂无评论
架构--模块5_架构训练营_李某人_InfoQ写作社区