写点什么

架构训练营 模块五

作者:Geek_16d2b8
  • 2022 年 3 月 17 日
  • 本文字数:729 字

    阅读完需:约 2 分钟

【作业要求】

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

计算架构,包括但不限于如下内容:

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

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

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


1 微博评论计算性能评估

假设发一条微博,平均 20 个人评论,之前发微博的性能估算 TPS 是 10K/s,则发微博的 TPS 估算为 10*20=200K/s


2 微博评论高性能计算架构

负载均衡设计

微博评论也是典型的写操作,并且性能要求比发微博更高,所以同样要采用多级负载均衡,评论依赖登录状态发的微博 id,一般都交给分布式缓存维护,而且没有强一致性要求,实时性要求,也没必要指定到某个服务器根据微博 id 进行 hash 去提升并发冲突的问题。采用轮询或随机的策略就可以了。


业务服务器估算

由于评论微博实时性要求不高,可以采用漏铜算法变种(写缓冲)+批量读写方式提升单台服务器写性能,由于是写,缓存用不上,单台单条 500,加入每次处理 200 比单条记录时间要长 10 倍,500*200/10=5000,每秒处理 200K40 台差不多够了。


这里我认为没必要单独拆分一个服务,可以和发微博放到一个部署单元里面(都是处理写请求),采用缓冲后,和发评论对服务器资源相差不大。主要瓶颈在于网络带宽和缓冲区长度,数据库层面可以慢慢写。


负载均衡架构图和发微博一样,这里就不画了。


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

评论热点问题比较常见,特别是明星事件。只要缓冲区足够大(漏铜算法变种),应用处理不是瓶颈,主要防止热点耗光所有对网络带宽,可以考虑在接入层限流。限制同一用户请求频率。

这种场景不涉及到一致性问题,排队没必要使用,熔断主要用于查询。可以采用降级手段提升评论微博使用的网络带宽。

用户头像

Geek_16d2b8

关注

还未添加个人签名 2019.03.21 加入

还未添加个人简介

评论

发布
暂无评论
架构训练营 模块五_架构训练营5期_Geek_16d2b8_InfoQ写作平台