10 | 自动智能扩缩容：直播互动场景中峰值流量的应对
该思维导图由 AI 生成，仅供参考
业务形态区别和技术挑战
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文从业务形态和技术层面分析了直播互动与传统即时消息场景的区别，并提出了应对高并发压力的解决方案。在业务形态上，直播互动的流量峰值具有突发性，且房间规模庞大，导致消息下推的并发峰值巨大。针对这一挑战，文章提出了在线状态本地化和微服务拆分两种解决方案。在技术层面上，通过自动扩缩容和智能负载均衡等方式，实现了对高并发流量的有效处理。文章强调了自动扩缩容作为互联网公司标配的平衡服务处理能力和资源成本的基础设施的重要性，同时指出这些技术不仅适用于直播互动场景，也具有普适性。总的来说，本文为直播互动场景中的高并发应对提供了有益的参考，对于从事相关技术领域的读者具有一定的借鉴意义。
《即时消息技术剖析与实战》，新⼈⾸单¥59
全部留言(40)
- 最新
- 精选
钢老师，直播回放是如何保持播放进度与聊天内容在时间上同步的，用什么技术实现的作者回复: 可以通过插帧的方式来解决。视频流每隔一定帧数内，插入服务器的时间戳，聊天内容也埋入服务器的时间戳。回放视频时到达相应的时间戳，获取跟这个时间戳相匹配的消息在页面上渲染出来即可。
2019-09-18222- 饭团长链接在服务器缩容的时候需要做： 1)需要告诉网管机，自己准备停止接入新的链接！ 2)在最后一个链接断掉后后才能退出 短链接 和 长链接比 变化实效性要高很多
作者回复: 是的，实际上也不需要等到最后一个长连断开哈，对于剩余的少量的长连接可以采取强制断开方式，等待客户端断连重连即可。
2019-09-18220 - 淡蓝小黑文中提到【通过这个优化，相当于是把直播消息的扇出从业务逻辑处理层推迟到网关层】和 您回复我的【业务层在把消息扇出给到网关机时，就已经具体到接收人了，所以不需要通知网关机来进行变更。】 这两条不冲突吗？(我看唯一的区别是文中说的是直播间场景，您回复我的是群聊场景，还是说群聊和直播间是用不同的模式扇出消息的？)，其实我想问的是，用户加入直播间，网关机本地维护【本机某个直播间有哪些用户】这个数据的话，当用户离开直播间，加入另一个直播间时，业务处理层还要通知网关层更新本地维护的那个数据，有可能会出现数据不一致的情况，导致用户加入新直播间了，但由于网关层数据没有更新，用户收到不到新直播间的消息。
作者回复: 嗯，这是个好问题，我们来理一理。 先想一想群聊和直播的使用场景，对于直播场景来说，房间和房间之间是隔离状态，也就是说每次用户进入到一个房间，都需要通过信令告诉网关机自己当前连接的是哪个房间，这样网关机才不会推错消息。正是通过这个加房间的信令，网关机有机会来维护一个 房间 - 用户 -连接的关系，因此对于直播间消息，我们的消息给到网关机时只需要按房间维度来pub消息就可以；但是对于群聊来说，群和群之间不是隔离状态，我们的长连接对于任何群的消息都是需要推送的，因此在app打开建立好长连后，客户端不需要再告知自己当前进入了哪个群，所以网关机在建立长连时只能建立一个 用户 - 连接的映射，所以对于群聊我们需要在提交给网关机时扇出成用户维度才可以。 理解了上面说的就不难解答你的问题，用户离开直播间加入另一个直播间都会通过长连通道下发一个退出旧直播间信令和加入新直播间信令（或者一个切换房间信令），这多个信令都是被长连接那一台网关机接收到并处理的，所以不存在需要多网关机同步数据的问题哈。
2019-09-26212 
yic老师，为了避免每条消息都查询用户的在线状态，所有的消息都发送给所有的网关节点，这样也会造成每台网关机器的流量成倍数增长吧。这样，是不是会影响消费者推送消息的速率呢？毕竟，如果有50台网关节点，原来每台网关节点只需要取1条消息，现在却需要取50条消息，其中有49条是无效的。作者回复: 是的，所以这个需要一个权衡，如果业务场景大部分都是点对点场景那么使用全局在线状态来精确投递是更好的选择，如果是群聊和直播类似扇出较大的场景推荐使用所有网关来订阅全量消息的方式。
2019-11-1527
Derek对于高在线的房间，做全量网关转发是合适的，到对于低在线，极端情况就是2个人，这种方式有点浪费，而其实绝大部分大型直播平台，低在线占绝对比例。作者回复: 嗯，看具体业务的在线率和网关机数量吧。低在线直播间本来没量也不是重点，我们的重点是要解决那少数几个高热度、高并发的直播间的问题。
2019-09-264
卫江思考题：基于长连接与web的服务缩容的区别。本质的区别是长连接与短链接的问题，基于长连接就意味着服务器在内核中保存了一些连接状态，而为了更好的扩缩容保持服务的无状态是最好的，因为这些状态会在服务回收后消失，当然了基于web的服务，我们可能也会在应用层保存用户的session等信息，不过这一块可以放在外部存储，比如缓存，所以，基于长连接的服务缩容一定会造成连接信息的丢失，从而触发客户端断线重连以及建立长连接的整个流程。作者回复: 是的，对于长连接的网关服务，我们缩容是只需要禁止新的建连请求接入，已存在的长连接尽量等用户自动断开后关闭，对于剩余的少量的长连接可以采取强制断开方式，等待客户端断连重连即可。
2019-09-184
蒙老师你好我有一个问题和想法： 消息扇出时，全量推送网关，这块能否继续优化？ 我的想法是，客户端按直播间归类，相同直播间的客户在相同网关(需要考虑扩缩容)，这样推送给网关时只需要推送网关所有直播间的消息。不知道是否可行？作者回复: 相同直播间的客户在相同网关的话需要考虑热点过于集中的问题，对于人数较多的直播间，这一块可能容易成为瓶颈。
2020-02-1823- 鱼向北游不知道老师还关注不关注这个留言，想问老师个问题，上面说的直播间那个把消息直接广播扇出过各个网关再由各网关来判断这个消息该推给哪个用户。感觉这个没法对网关做到水平扩容呀，因为即使扩容了，扩容网关所收到的消息也是全量的广播消息，压力一点都不会分摊，前阵子做过压测，用这种架构在原网关达到瓶颈后，新添加机器后，新添加的机器在没有用户连接的情况下光分拣消息判断消息不该发，这个操作已经占用到新机器70%的资源了，新机器承载不了多少新量，在这种广播模式下反而是用户都集中在某台或某几台机器上效果会更好
作者回复: 扩容网关机收到的是扇出前的单条房间维度的消息呀，扇出是在网关机的逻辑里实现的，扇出完就推送出去了。分拣消息慢这一块可以优化一下，在用户上线时在网关机以房间维度建立当前房间的本地用户连接列表，下推时直接获取连接列表就可以了。我们线上下推qps实际能到千万级别，绝大部分机器都是弹性扩容的。
2019-11-0533 - 钢听到老师在回复同学的“监控当前总连接数、每秒建连数、close_wait的连接数、Send-Q、Recv-Q、backlog队列、重传率、pps、带宽使用情况“，深感自己不足，tcpip协议详解这本书没啃下来，老师有推荐的有关网络的书籍吗
作者回复: 个人感觉还是需要理论结合实际来学习哈，平时没事的时候可以用wireshark抓点包来分析研究一下，印象和理解都会不一样的。推荐一下林沛满的两本wireshark的书吧。。
2019-09-182 
晴天通过类似redis的pub/sub实现服务端与客户端长连接消息投递，和队列记录长连接的服务端ip对应客户端标识；这2中方式哪一种应用的更为广泛？作者回复: 直播和聊天室场景第一种使用更多，点对点的也有很多使用第二种的，对于网关服务器不太多的业务，个人倾向都使用第一种。
2019-09-182
