疫情之下,如何设计百万并发的IM系统?
近期随着武汉新型肺炎疫情的蔓延,很多教育机构也提供了“停课不停学”的在线直播教学服务,这也是一大直播互动场景。
IM 系统的高并发场景
IM 系统中,高并发多见于直播互动场景。比如直播间,在直播过程中,观众会给主播打赏、送礼、发送弹幕等,尤其是明星直播间,几十万、上百万人的规模一点也不稀奇。
直播互动场景具有这样的特点:流量峰值具有“短时间快速聚集”的突发性、流量随着开播和结束而剧烈波动,因而会带来很大的高并发压力。
IM 系统的高并发解决方案
网关全量转发
可以看到这两张图很像,但也有不同之处。
上面的图是普通聊天场景的流程图:
用户通过网关机进入直播间。
网关会保存、维护所有进入直播间用户的在线状态。
用户 A 发送一条弹幕消息,经过一系列处理。
通过网关机维护的用户在线状态,查询出同一直播间其他用户的网关机,将消息投递到这些网关机上。
网关机将消息推送给用户的设备。
也就是:通过维护一个全局的“在线状态”,逻辑层在确定好接收人后,通过这个“在线状态”查询接收人所在的网关机,将消息投递给这台网关机,最后由网关机通过长连接进行投递。
问题来了!如果是一个 10w 人的直播间,每发送一条消息,就要对这个“在线状态”进行 10w 次的查询,更何况是多人、高频的消息发送呢?
下面的图是基于上面的流程进行优化后的流程图,更适用于高并发聊天场景:
用户通过网关机进入直播间,会在每台网关机本机维护“在线状态”。
用户 A 发送一条弹幕消息,经过一系列处理,投递给消息队列,而每台网关机均订阅了这个全局的消息队列,因而都能收到消息。
网关机通过本机维护的用户在线状态,将消息推送给用户的设备。
这个优化的核心就是:不再去精准地确认这个直播间的用户在哪些网关机上,而是将这个直播间的消息全量投递给网关机,再由网关机将消息下推给本机连接的用户设备,也就是下推服务不依赖外部状态服务。
微服务拆分
对所有业务进行拆分:
核心服务:如发弹幕、点赞、打赏等。
非核心服务:如直播回放、第三方系统的同步等。
核心服务通过 DB 从库或者消息队列的方式与非核心服务解耦依赖,避免被直接影响。
对核心服务进行梳理:容易出现瓶颈点的服务和基本不会有瓶颈的服务。容易出现瓶颈的长连接入服务独立部署,并且和用户发送消息的上行操作拆分成各自独立的通道,这样能够使消息上行通道、和推送下行通道互相隔离。
自动扩缩容
直播互动场景的监控指标一般可以分为两大类:
业务性能指标,比如直播间人数、发消息和信令的 QPS 与耗时、消息收发延迟等。
机器性能指标,主要是通用化的机器性能指标,包括带宽、PPS、系统负载、IOPS 等。
智能负载均衡
小结
作者:鹿呦呦
编辑:陶家龙、孙淑娟
出处:https://www.cnblogs.com/sunshineliulu/p/12258610.html
精彩文章推荐: