标题：环信：基于大规模边缘计算的千万级聊天室技术实践

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

相对于集中式，单中心的方案，不仅仅在服务的稳定性，承载的用户量级上有了显著的提升，而且在成本上也能有大幅的降低，同时用户体验也变得更好。

至于业界一直尝试的CDN的聊天室方案同样存在着本身的局限性，不同于音视频消息单个内容相对较小，瞬时性访问量较大，重复访问的概率几乎没有等特定，使得CDN的实践方案无法满足该场景的需求。

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

大型边缘聊天室的工作过程非常的简单，用户 UserA 加入聊天室 X，用户 UserB 也加入聊天室 X，此时用户 UserA 向聊天室发送消息 hello,服务端接收到该消息后，会向 UserA 发送一个接收成功的回应，服务端同时会将消息进行扩散到所有在同一个聊天室中的人，此示例中为 UserB。

2、场景简单化但制作不简单每个环节都需要额外关注1.

如何稳定，高效的保持住百万甚至千万的长连接2.

如何进行聊天室成员状态的维护3.

如何进行消息路由的选择3、如何稳定超大规模的连接？

主要通过两个方向来解决这个问题，单机的连接数和集群的规模。

1.

单机负载关于单机连接的提升上，单机的连接数支撑虽然可以达到很高的数值，但是也要考虑是否为有效连接，因为高负载的连接和低负载的连接是完全不同的概念，且不说其他的业务逻辑，单纯其中的心跳保持逻辑，就会造成 CPU 和 IO 非常大的负担，这些还是完全没有谈及业务逻辑的基础上，故而在单机负载上，一般采用的是不超过 10W 的单机负载。

2.

集群规模集群的水平扩展能力决定了集群的规模，下图是服务端的整体部署结构：上图中绿色的区域为负责客户端长连接的区域，所有的 IMS（IM Server）提供的服务完全相同，而且相互之间完全没有任何的依赖关系；上图中的黄色是部署在 IDC 中，主要服务聊天室的路由管理以及消息的路由分发。

IMS 可以认为是可以无限水平扩展的架构设计，所以集群的规模可以认为是无限的。

集群的规模上来了，尤其是在边缘侧的负载调度又称为了一个新问题，基于公司稳定而高效的边缘调度方式，通过客户端和服务端的完美配合实现高效，用户无感的连接体验。

4、关键：连接承载的瞬时数量对于长连接的场景，连接保持固然重要，连接能够承载的瞬时数量也是非常关键的指标。

而这个点也同样的是单机和集群的两个不同维度的问题，集群的角度则和上面的连接保持大致相同，而针对单机的连接创建和断开，则比单纯的保持住连接要复杂一些，需要考虑到登录时的鉴权问题，聊天室的特定场景，还需要考虑退出时的聊天室清理工作。

简单介绍一下整体的策略，主要将创建和断开时发生的事情分成了两大类，一类是需要同步去执行的动作，另外一类是可以进行异步处理的，则放入到异步队列进行处理。

策略本身比较简单，但是真正在执行的过程中能够做到，而且能够随着版本的迭代一直保持策略则显的比较困难，为了达到该目标，我们坚持着一个原则，凡是要添加到同步逻辑中的内容，需要给明相应的理由，并且需要团队内部同步讨论，否则只能采用异步队列的方式，这里并不是说异步队列的事情不需要审核或者讨论，而且同步的需要明确的针对性的处理，这样才能保证同步逻辑的清晰以及策略的可持续性。

5、如何进行成员状态的维护？

聊天室属于多人聊天的一种特定的形态，消息仅仅扩散到在线的用户，用户离线则自动退出聊天室，并且再次上线后也不会接收到离线时的消息。

至于像是一些断网了重新连接后还能继续观看直播的场景，进去时能够看到一些历史消息的情况，则是通过其他的手段实现自动订阅，拉取历史的能力。

成员的分级管理

发布时间：2025-08-03 09:20:59
来源：阅天下
链接：https://www.haidaliao.com/html/54449.html