架构 -- 模块 5

已知：

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、对于大多数读评论的情况，缓存机制可以覆盖。可以使用多副本缓存提升效率，极端情况下可以使用令牌桶对评论进行限流访问。