上海聊天室最佳实践

在技术的迭代更新下，面对大型、超大型的直播场景，大规模边缘聊天室成为新热潮。

作者 | 张超责编 | 王子彧

出品 | CSDN（ID：CSDNnews）

当前直播成为一种流行趋势，带货直播，网红带货，明星在线演唱会等，进一步使得直播聊天室变成了一个当前必备的能力，面向大型，超大型的直播场景，技术上也在不断的进行迭代更新。

大规模边缘聊天室如何工作？

简单介绍一下整体的策略，主要将创建和断开时发生的事情分成了两大类，一类是需要同步去执行的动作，另外一类是可以进行异步处理的，则放入到异步队列进行处理。策略本身比较简单，但是真正在执行的过程中能够做到，而且能够随着版本的迭代一直保持策略则显的比较困难，为了达到该目标，我们坚持着一个原则，凡是要添加到同步逻辑中的内容，需要给明相应的理由，并且需要团队内部同步讨论，否则只能采用异步队列的方式，这里并不是说异步队列的事情不需要审核或者讨论，而且同步的需要明确的针对性的处理，这样才能保证同步逻辑的清晰以及策略的可持续性。

如何进行消息路由的选择？

多级路由

基于上面的分级注册的逻辑，可以看出消息的下发也是分级进行下发的，这种设计上减少了每层的下发的难度，举个例子如果有200IMS，10个Edge，则极端情况下IDC需要分发的数量为10个，每个Edge的分发数量为20个，如果只有一级的话，则IDC需要分发200个请求，这个看着不是一个很大的数字，但是不要忘记这个仅仅为一条消息的分发量，而如果有5000请求则是200*5000=1，000，000则有百万级别的分发量，通过分级的方式能够有效的降低各个层级的复杂度，同时也能尽量减少跨机房，跨地区的调用，进一步降低风险。分级分发虽然带来了好处，也使得路径的维护变得相对复杂很多。

消息推拉结合

聊天室的场景，大部分场景下是采用直接推送消息的方式。大型的聊天室消息的过滤，筛选以及丢弃的策略的方式也是非常复杂的问题。至于消息到投递阶段之后，直接推消息给客户端，这样消息的即时性确实得到了保证，但是客户端的情况是不同的，机器的配置不同，机器当时的运行状态不同，网络状况也是不同的，所以在这种情况，需要支持客户端能够根据自己的情况进行拉取一定数量的消息，这样能够更加灵活的适应不同的场景。这些策略虽然说这简单，但是真正的落实到线上的服务，还是有很多的细节点需要考虑，真正做到稳定还是比较困难的，毕竟这种特定的场景期望很好的监控也是比较困难的。我们也是先从简单的固定模式的推拉方式进行处理，后续根据具体的情况进行更加细节性的调优。

固定路由

针对一些明确大型直播的场景需求，也提供了一种简单的路由方式，从上述的聊天室路由管理，可以看出出问题的情况还是可能存在的，所以针对已知特别大的聊天室场景，该场景的话，可以认为能够覆盖到所有的 IMS 服务，所以聊天室的分级注册就显得有点多余，所以聊天室级别的注册变更为节点的注册，依赖系统的服务注册发现默认就完成相关的内容，这样整个事情就变得非常的简单高效了。

这种方式有其在这种超大型聊天室的优势，也存在其自身的瓶颈点，所以的消息不管是否在本节点有用户加入了该聊天室，消息都会投递到该节点，故而每个 IMS 都要处理所有的消息，尽管很多的消息是没有下发投递的需求。方案没有万能的，所以这两种处理方式是互补的，并不是互斥的。

大规模边缘聊天室 VS 中心集群

大规模边缘聊天室的方案，相较于传统的中心集群式的聊天室，从技术的大的架构是没有本质的区别，依然是多级路由，消息推拉结合的方式。

不同的点在于部署的形态不同，而恰恰是这些的不同使得很多东西发生了变化。大规模边缘聊天室的方式，增加了边缘的连通性，能够在更加靠近用户的地方进行就近部署，达到解决最后五公里的目的。并且能够利用各个机房的资源，从而达到百万，千万级别甚至更高量级的用户数量。大规模边缘聊天室的方案在实施的过程中，对成本的降低也起到了关键作用，由于中心机房一般保证可用性和稳定性，一般采用的都是 BGP 的网络，成本相对边缘机房的非 BGP 网络要贵很多。系统整体可用性的角度，大规模边缘聊天室相比于中心集群式的聊天室，对于机房故障的容灾性更好。当然这里主要介绍了大规模聊天室的优点，任何一种方案都不是全能的，有其优点就有其自身的劣势。大规模边缘聊天室部署形态复杂，对于运维体系的要求相对较高，服务间网络稳定性也比较难以保障，所以一般适用于对大规模的，公开的聊天室，对于比价多精细玩法的场景，或者小规模不太适合，反而增加了很多的不确定性。

大规模边缘聊天室 VS CDN方式

针对大规模聊天室，曾考虑过是否可以使用业界比较成熟的 CDN 分发技术。在具体的实践过程中发现，针对这种小包，而且不会重复分发的场景，这里指的是同一个消息，不太会被一段时间不断的获取，聊天室的场景一般是当时收到了就收到了，如果没有收到，后续也不太期望需要收到消息。而且 CDN 的方案都是将消息聚合后，客户端定时拉取的方式，消息存在重叠性，延时性等不能满足客户的需求。

技术难度上，加入1000万的聊天室，每10s重新刷新一次消息，也有将近100W的 QPS 请求，这对于 CDN 系统也是一个非常大的调整，而且即使接入多家的 CDN 也会存在比较高比例的超时。更何况10S的延时，对于有些场景已经能够明显感知到了。

大规模聊天室相对于集中式，单中心的方案，不仅仅在服务的稳定性，承载的用户量级上有了显著的提升，而且在成本上也能有大幅的降低，同时用户体验也变得更好。至于业界一直尝试的 CDN 的聊天室方案同样存在着本身的局限性，不同于音视频消息单个内容相对较小，瞬时性访问量较大，重复访问的概率几乎没有等特定，使得 CDN 的实践方案无法满足该场景的需求。如2022卡塔尔世界杯期间，环信针对运营商客户对于世界杯的直播聊天室进行专业改造，并且帮助客户实现千万级聊天室的技术支持。解决了客户对于世界杯赛事直播海量用户在线的需求，通过架构的调整，能够同时支撑1800万用户同时在线，消息的处理能力达到了5000 QPS，消息的下发量达到了4000万 /秒的级别。环信整体方案不仅能够支持到如此大规模的量级，而且成本也能够比肩 CDN 的方案，机器能够进行高效的扩缩容。

?ChatGPT 带火的「提示工程师」岗，不用写代码，也能获得年薪数百万？

?CSDN 亮相 2023 全球人工智能开发者先锋大会

?ChatGPT 火爆，程序员会不会被取代？答案都在这里！

本站部分内容由互联网用户自发贡献，该文观点仅代表作者本人，本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规等内容，请举报！一经查实，本站将立刻删除。