|
|
51CTO旗下网站
|
|
移步端
  • 震情之下,如何设计百万并发的IM系统?

    不久前随着武汉新型肺炎疫情的蔓延,有的是教育单位也提供了“停车不停机”的在线直播教学服务,这也是一大直播互动场景。

    笔者:鹿呦呦 来源:博客园| 2020-02-06 08:03

    不久前随着武汉新型肺炎疫情的蔓延,有的是教育单位也提供了“停车不停机”的在线直播教学服务,这也是一大直播互动场景。

    图表来自 Pexels

    IM 系统之高并发场景

    IM 系统中,高并发多见于直播互动场景。比如直播间,在直播过程中,听众会给主播打赏、送礼、发送弹幕等,尤其是出名直播间,几十万、上百万人口之局面一点也不奇怪。

    直播互动场景具有这样的性状:年产量峰值具有“短时间快速聚集”的突发性、年产量随着开播和竣工而可以动荡,故此会带来很大的高并发压力。

    IM 系统之高并发解决方案

    网关全量转发

    咱们先看两张图:

    可以看出这两张图很像,但也有不同的处。

    地方的向往是一般聊天场景的蓝图:

  • 他家通过网关机进入直播间。
  • 网关会保存、保护所有进入直播间用户之在线状态。
  • 他家 A 发送一枝弹幕消息,历经一系列处理。
  • 穿过网关机维护的客户在线状态,查询出同一直播间其他用户之网关机,名将消息投递到那些网关机上。
  • 网关机将消息推送给用户之装备。
  • 也就是:穿过维护一个全局的“在线状态”,逻辑层在肯定好接收人后来,交通过这个“在线状态”查询接收人无处的网关机,名将消息投递给这台网关机,说到底由网关机通过长连接进行投递。

    题材来了!如果是一番 10w 人口之直播间,每发送一枝信息,就要对这个“在线状态”拓展 10w 先后之询问,更何况是多人口、高频的信息发送呢?

    下的向往是基于上面的流程进行规范化后的蓝图,更适用于高并发聊天场景:

  • 他家通过网关机进入直播间,会在每台网关机本机维护“在线状态”。
  • 他家 A 发送一枝弹幕消息,历经一系列处理,投递给消息队列,而每台网关机均订阅了这个大局的信息队列,故此都能接受消息。
  • 网关机通过本机维护的客户在线状态,名将消息推送给用户之装备。
  • 其一多极化的骨干就是:不再去精准地承认这个直播间的客户在哪些网关机上,而是将以此直播间的信息全量投递给网关机,再由网关机将消息下推给本机连接的客户设备,也就是副推服务不依赖外部状态服务。

    微服务拆分

    对一切工作进行拆分:

  • 基本服务:如发弹幕、点赞、打赏等。
  • 非核心服务:如直播回放、先后三方系统之同步等。
  • 基本服务通过 DB 副库或者消息队列的措施与非核心服务解耦依赖,避免被直接影响。

    对基本服务开展梳理:轻而易举出现瓶颈点的劳务和中心不会有瓶颈的劳务。轻而易举出现瓶颈的长连接入服务独立布置,并且和用户发送消息的航空操作拆分成各自独立的大道,这样能够使消息上行通道、和推送下行通道互相隔离。

    机动扩缩容

    直播互动场景的监察指标一般可以分为两大类:

  • 工作性能指标,比如直播间人数、发消息和信令的 QPS 与耗时、信息收发延迟等。
  • 机械性能指标,重点是通用化的机械性能指标,包括带宽、PPS、系统负载、IOPS 等。
  • 穿过收集业务性能指标或者机器性能指标,重组模拟线上直播间数据来开展压测,找出单机、地方资源、依托服务的瓶颈临界点,制订应当的接触自动扩缩容的指标监控阈值,贯彻国产化。

    智能负载均衡

    扩容可能会出现旧机器和新机械对于新增储量负载不均的题材。

    对于长连接入服务前端的载荷均衡层来说,大多数都使用普通的 Round Robin 书法来部署,并不管后颖的长连接入机器是否已经承载了众多连接。

    这样会导致持续新的连接请求还是均匀地分配到旧机器和新机械上,导致旧机器过早达到瓶颈,而新机械没有把充分运用。

    这是因为负载均衡层支持自定义的平衡算法只能在某一台负载均衡机器上生效,无法真正形成全局的布置和人均。最好的措施是接管用户连接的进口,在最南端入口来开展全局调度。

    比如,在成立长连接前,客户端先通过一个入口调度服务来查询本次连接应该连接的进口 IP,在这个入口调度服务里根据现实后端接入层机器的切实可行工作和机械的性质指标,来实时计算调度的权重。

    负载低的机械权重值高,会把入口调度服务作为优先接入 IP 下发;负载高的机械权重值低,持续新的连接接入会相对更少。

    总结

    地方的组成部分应对高并发的行动,不仅仅可以用于直播互动场景,也可用于其他工作场景,而滥用什么政策往往是根据工作需求而定。

    比如上面提到的全量网关转发,假如有 50 台网关节点,原本每台网关节点只要求取 1 条信息,如今却要求取 50 条信息,其中有 49 条是杯水车薪的。

    为了避免每条消息都查询用户之在线状态,整整的信息都发送给所有的网关节点,会造成每台网关机器的话务量成倍数加强和自然资源之浪费,但这是应对高并发的一个有效方法。

    如果是点对点场景,采用全局在线状态来规范投递是更好的取舍,如果是帮聊和直播的面貌推荐使用一切网关来订阅全量消息的措施,而利用什么办法根据要求来衡量。

    【编纂推荐】

    1. 最佳全面的权力系统设计方案面世了
    2. 平头哥宣布开源RISC-V基础MCU芯片设计平台
    3. 一篇文章教你如何设计一个百万级的信息推送系统
    4. 详解:如何设计出健壮的秒杀系统?
    5. Sweet Home 3D绽开源码室内设计
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • 震情  计划  IM系统
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    Python使用场景实战手册

    Python使用场景实战手册

    Python使用场景实战手册
    共3章 | KaliArch

    22人口订阅学习

    一步到位玩儿透Ansible

    一步到位玩儿透Ansible

    Ansible
    共17章 | 骏马金龙1

    205人口订阅学习

    云架构师修炼手册

    云架构师修炼手册

    云架构师之必不可少技能
    共3章 | Allen在路上

    141人口订阅学习

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微



      
         
         
         
         
         
         
         
          
         
         


      1.