高并发系统实战课
徐长龙
前微博架构师、极客时间架构师
11663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语&结课测试 (2讲)
高并发系统实战课
15
15
1.0x
00:00/00:00
登录|注册

18|流量拆分:如何通过架构设计缓解流量压力?

树形热迁移切片法,迁移数据到新服务器
分片内服务实时计算更新
数据分片,根据用户id进行hash拆分
实时汇总更新数据,最终汇总累加结果
将点赞流量随机压到不同的写缓存服务上
客户端合并用户互动动作
预判卷展示正确答案和解析,异步缓慢提交用户答题结果
提前设定发送动作生效后再弹出题目
预加载下载题目数据
客户端随机延迟几秒后请求服务端拉取题目数据
分发到多个聊天内容分发服务器,客户端批量拉取数据
大数据实时计算分析用户输入,压缩整理重复内容
将聊天内容放入分布式队列传输
延缓用户进入直播的方式来动态扩容
提前将直播安排到相对空闲的服务器群组
按主播过往预测用户量
调度服务分配资源,将新来的房主分配到空闲的服务集群
评估服务器支持的在线人数
通过设置房间数量上限限制服务器服务用户数量
HttpDNS临时调度用户流量
Kubernetes动态扩容服务
周期压力测试
自动化运维
服务器统一调度系统
分布式存储
分布式实时计算
分布式队列
降低实时性,暂存数据在客户端
使用队列合并修改或做网关限流
打赏&购物:服务端分片及分片实时扩容
点赞:服务端树形多层汇总架构
点赞:客户端互动合并
答题:瞬时信息拉取高峰
聊天:信息合并
全国直播
游戏创建房间
CDN如何识别本地静态数据更新
调度服务
动态容器
分布式服务
服务降级:分布式队列汇总缓冲
不可预估用户量的服务
可预估用户量的服务
思考题
基础建设
流量拆分:如何通过架构设计缓解流量压力?

该思维导图由 AI 生成,仅供参考

你好,我是徐长龙。
今天,我会以直播互动为例,带你看看读多写多的情况下如何应对流量压力。
一般来说,这种服务多数属于实时互动服务,因为时效性要求很高,导致很多场景下,我们无法用读缓存的方式来降低核心数据的压力。所以,为了降低这类互动服务器的压力,我们可以从架构入手,做一些灵活拆分的设计改造。
事实上这些设计是混合实现对外提供服务的,为了让你更好地理解,我会针对直播互动里的特定的场景进行讲解。一般来说,直播场景可以分为可预估用户量和不可预估用户量的场景,两者的设计有很大的不同,我们分别来看看。

可预估用户量的服务:游戏创建房间

相信很多玩对战游戏的伙伴都有类似经历,就是联网玩游戏要先创建房间。这种设计主要是通过设置一台服务器可以开启的房间数量上限,来限制一台服务器能同时服务多少用户。
我们从服务器端的资源分配角度分析一下,创建房间这个设计是如何做资源调配的。创建房间后,用户通过房间号就可以邀请其他伙伴加入游戏进行对战,房主和加入的伙伴,都会通过房间的标识由调度服务统一分配到同一服务集群上进行互动。
这里我提示一下,开房间这个动作不一定需要游戏用户主动完成,可以设置成用户开启游戏就自动分配房间,这样做不但能提前预估用户量,还能很好地规划和掌控我们的服务资源。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何通过架构设计来缓解流量压力,特别是针对直播互动服务的情况。首先,文章讨论了可预估用户量的服务,以游戏创建房间为例,通过设置服务器可以开启的房间数量上限来限制一台服务器能同时服务多少用户,并通过调度服务进行资源分配。接着,文章讨论了不可预估用户量的服务,如全国直播,提出了预测用户量、延缓用户进入直播、聊天信息合并、瞬时信息拉取高峰等解决方案。此外,还介绍了针对点赞的客户端互动合并和服务端树形多层汇总架构的设计。文章还提到了服务降级的操作,通过队列将修改合并或做网关限流,以及对强一致实现分片、调度等。最后,文章指出了实现可动态调配的高并发的直播系统所需的基础建设,包括分布式服务、动态容器、调度服务等支撑。整体而言,本文通过具体的场景分析和解决方案,为读者提供了架构设计缓解流量压力的实用建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(7)

  • 最新
  • 精选
  • 黄堃健
    老师,在树形热迁移切片中,对于有状态的数据,对于相同的用户,通过什么方式保证主从的数据的强一致? 是不是像etcd的采用线性读之 ReadIndex来保证?

    作者回复: 你好,堃健,树形主要功能是拆分了分片的读写压力,如果分片很多,那么如Redis基本只有一个主库对外服务,从库多数是用来备份恢复使用,所以不存在同步问题,如果我们切片存在主从服务,并且业务场景严格要求强一致性,那么需要主从需要使用ReadIndex方式保证一致,但是性能不佳(极其少见这个需求落到数据层部署设计上),常见的多数是最终一致性配合原子操作就足够了。

    2024-03-12归属地:广东
  • 黄堃健
    老师,你好。 文中提到请注意,这个方式只适合用在疯狂刷屏的情况,如果用户量很少可以通过长链接进行实时互动。 那么问题来了:在聊天时,如何感知实时刷屏? 正常聊天和实时刷屏让客户端去区分吗?那么又如何让聊天信息和刷屏信息统一起来

    作者回复: 你好,堃健,用户发送上来的信息会先用队列进行汇总,这时就可以通过监控队列堆积情况来进行度量

    2024-02-23归属地:广东
    2
  • 小达
    有个问题,像直播这种场景,如果客户端观看人数很多,比如同时100w人在线,是需要维护100w个客户端到服务器的长连接吗?这样感觉服务器会不会扛不住

    作者回复: 你好,是可以做到的,目前服务器性能很强的,我记得 360 做过一个分享一台服务器就能维持 100 万连接,加上推送实时性以及稳定性需要 20 万或者更少用来剩下空间做冗余,刚想起来再补充下,人多在线的直播会把推送改为拉取,那样更好做去重计算

    2023-04-25归属地:广东
  • 普通熊猫 ଘ(੭ˊ꒳​ˋ)੭✧
    chrome从54版本开始,用户刷新页面的时候,只要缓存不过期,都是从memory cache或disk cache中直接加载。只有过期的资源,才需携带ETag或Last-Modified送审web server,以获取更新的资源。 由于存储成本很低,目前CDN上的静态资源存储模式已逐渐演变为:只增加,不修改,永不过期。通过在资源名称中嵌入digest值,可以做到每一份新的资源都拥有不同的文件名。而且天然防止预测文件名称,在一定程度上避免了CDN上的资源被扫描的可能性。 摘自《29.五级缓存论》: https://mp.weixin.qq.com/s/087cUV5MrXsDQZcZUnB0nQ

    作者回复: 你好,熊猫,这个是没问题的,但是这个多数是对于js文件和静态文件的,如果我们的是数据,服务端刷新数据的时候,我们是期望本地cache在没到期的时候也有办法刷新。:)

    2023-03-15归属地:北京
  • 若水清菡
    既然 CDN 能够缓存我们的静态数据,那么它是如何识别到我们本地的静态数据有更新的呢? 一般情况下静态数据的更新需要使用cdn的文件或目录刷新接口进行刷新,cdn通过文件的创建时间和修改时间来匹配文件是更新还是新增,对同名文件进行回源拉取后在边缘节点下发更新操作,对新增文件进行回源拉取然后下发边缘节点操作。

    作者回复: 你好,若水清菡,一般来说会有集中方式其中有http304方式检测,expire超时检测,etag检测等~

    2023-01-24归属地:北京
  • LPF
    老师,针对IM这种1 V 1读写的状况,我们该如何去进行流量拆分呢?直接读写怼数据库是不是会蹦啊

    作者回复: 你好,LPF,这种数据主要是产生后不会修改的数据,可以说产生后就是归档,读取并发不高,个人理解扔类似对象存储append挺好的,辅助查询服务即可

    2023-01-19归属地:河南
  • brqi
    既然 CDN 能够缓存我们的静态数据,那么它是如何识别到我们本地的静态数据有更新的呢? 可以通过MD5一下缓存文件,对比md5值就知道变化了,可以采用 文件名称+文件md5值来判断,降低MD5值冲突风险

    作者回复: 你好,brqi,感谢交流,这个思路没问题,我们继续深入下,什么时候CDN会知道我们更新资源了~

    2022-12-22归属地:北京
    6
收起评论
显示
设置
留言
7
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部