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