近期随着武汉新型肺炎疫情的蔓延，很多教育机构也提供了“停课不停学”的在线直播教学服务，这也是一大直播互动场景。
图片来自 Pexels
IM 系统的高并发场景
IM 系统中，高并发多见于直播互动场景。比如直播间，在直播过程中，观众会给主播打赏、送礼、发送弹幕等，尤其是明星直播间，几十万、上百万人的规模一点也不稀奇。
直播互动场景具有这样的特点：流量峰值具有“短时间快速聚集”的突发性、流量随着开播和结束而剧烈波动，因而会带来很大的高并发压力。
IM 系统的高并发解决方案
网关全量转发
我们先看两张图：
可以看到这两张图很像，但也有不同之处。
上面的图是普通聊天场景的流程图：
- 用户通过网关机进入直播间。
- 网关会保存、维护所有进入直播间用户的在线状态。
- 用户 A 发送一条弹幕消息，经过一系列处理。
- 通过网关机维护的用户在线状态，查询出同一直播间其他用户的网关机，将消息投递到这些网关机上。
- 网关机将消息推送给用户的设备。
也就是：通过维护一个全局的“在线状态”，逻辑层在确定好接收人后，通过这个“在线状态”查询接收人所在的网关机，将消息投递给这台网关机，最后由网关机通过长连接进行投递。
问题来了!如果是一个 10w 人的直播间，每发送一条消息，就要对这个“在线状态”进行 10w 次的查询，更何况是多人、高频的消息发送呢?
下面的图是基于上面的流程进行优化后的流程图，更适用于高并发聊天场景：
- 用户通过网关机进入直播间，会在每台网关机本机维护“在线状态”。
- 用户 A 发送一条弹幕消息，经过一系列处理，投递给消息队列，而每台网关机均订阅了这个全局的消息队列，因而都能收到消息。
- 网关机通过本机维护的用户在线状态，将消息推送给用户的设备。
这个优化的核心就是：不再去精准地确认这个直播间的用户在哪些网关机上，而是将这个直播间的消息全量投递给网关机，再由网关机将消息下推给本机连接的用户设备，也就是下推服务不依赖外部状态服务。
微服务拆分
对所有业务进行拆分：
- 核心服务：如发弹幕、点赞、打赏等。
- 非核心服务：如直播回放、第三方系统的同步等。
核心服务通过 DB 从库或者消息队列的方式与非核心服务解耦依赖，避免被直接影响。
对核心服务进行梳理：容易出现瓶颈点的服务和基本不会有瓶颈的服务。容易出现瓶颈的长连接入服务独立部署，并且和用户发送消息的上行操作拆分成各自独立的通道，这样能够使消息上行通道、和推送下行通道互相隔离。
自动扩缩容
直播互动场景的监控指标一般可以分为两大类：
- 业务性能指标，比如直播间人数、发消息和信令的 QPS 与耗时、消息收发延迟等。
- 机器性能指标，主要是通用化的机器性能指标，包括带宽、PPS、系统负载、IOPS 等。
通过收集业务性能指标或者机器性能指标，结合模拟线上直播间数据来进行压测，找出单机、中央资源、依赖服务的瓶颈临界点，制定相应的触发自动扩缩容的指标监控阈值，实现自动化。
智能负载均衡
扩容可能会出现旧机器和新机器对于新增流量负载不均衡的问题。
对于长连接入服务前端的负载均衡层来说，大部分都采用普通的 Round Robin 算法来调度，并不管后端的长连接入机器是否已经承载了很多连接。
这样会导致后续新的连接请求还是均匀地分配到旧机器和新机器上，导致旧机器过早达到瓶颈，而新机器没有被充分利用。
这是因为负载均衡层支持自定义的均衡算法只能在某一台负载均衡机器上生效，无法真正做到全局的调度和均衡。最好的办法是接管用户连接的入口，在最外层入口来进行全局调度。
比如，在建立长连接前，客户端先通过一个入口调度服务来查询本次连接应该连接的入口 IP，在这个入口调度服务里根据具体后端接入层机器的具体业务和机器的性能指标，来实时计算调度的权重。
负载低的机器权重值高，会被入口调度服务作为优先接入 IP 下发;负载高的机器权重值低，后续新的连接接入会相对更少。
小结
上面的一些应对高并发的举措，不仅仅可以用于直播互动场景，也适用于其他业务场景，而选用什么策略往往是根据业务需求而定。
比如上面提到的全量网关转发，假如有 50 台网关节点，原来每台网关节点只需要取 1 条消息，现在却需要取 50 条消息，其中有 49 条是无效的。
为了避免每条消息都查询用户的在线状态，所有的消息都发送给所有的网关节点，会造成每台网关机器的流量成倍数增长和资源的浪费，但这是应对高并发的一个有效方式。
如果是点对点场景，使用全局在线状态来精确投递是更好的选择，如果是群聊和直播的场景推荐使用所有网关来订阅全量消息的方式，而采用什么方式根据需要来权衡。
