高并发实时直播弹幕研发实践

浏览: 34 发布日期: 2016-11-07 分类: erlang

高并发实时直播弹幕研发实践

直播间特点

聊天室限制人数的原因

应对万级以上的实时互动

跨服务器是为了解决单一服务器接入数量限制、发布消息吞吐限制等问题;
多进程并发则是为了充分利用多核CPU以及减小一个循环规模从而达到降低延迟的目的。

云巴实时系统的设计

云巴是基于MQTT协议实现的实时通信系统,采用Erlang/OTP的架构设计。简单地来说,云巴实时系统的设计包括多层结构微服务两个要点。

多层结构

云巴系统设计中,多层结构意味着一个基本业务逻辑的完成需要经历多个模块(如图上所示)。

云巴多层结构设计有三个主要特点:

  • 所有模块均可独立运行,互不干扰。 任一模块在运行的过程中,无需依赖其他模块。除此以外,还会对所有模块设立在线监控,从而实现生产状态下的实时告警。同时,模块独立运行还能够达到持续集成的效果;

  • 细粒度扩容,包括但不限于对接入进行扩容等;

  • 使用「隔离」。 顾名思义,系统可以为用户指定特定的路径,也可以在某些路径出现问题以后,强行从系统里摘除路径,达到「隔离」效果。

微服务化

虽然近期微服务已一个新兴事物的身份被广泛讨论,但其实,微服务可以算是一个 概念了。

比如Erlang/OTP就是一个成熟已久的典型微服务架构。其作为微服务架构的特点就在于业务逻辑非常简单的同时,并发量也非常高。

云巴采用的正是Erlang/OTP的架构设计,在微服务化的方面的体现则是将业务逻辑封装成一个RPC Service,以及RPC Service部署微一个OTP Worker。

云巴实时系统的特点

云巴实时系统的设计特点主要有:拥有海量轻量级任务、任务与运行位置无关以及水平扩展。任务与运行位置无关,这就意味着在任务池中,可以动态地把任务调度到不同物理机上,同时数据要存储在独立集群中。

海量的轻量级任务包括长连接创建的任务、用户请求产生时创建的任务。

长连接任务即为,当一个长连接接入时,系统会创建一个任务来管理和维持长连接;

同样地,请求任务则是,当一个用户请求(比如发送一条弹幕)产生时,就会创建一个任务来管理该请求。

对于云巴来讲,不论是用户加入了一个直播间还是发送了一条弹幕,都可以以Pub/Sub模型来实现。Pub/Sub模型中比较重要的词汇为「publish」、「subscribe」以及「unsubscribe」。

比如,一个用户进入了一个直播间,则可以视为订阅(subscribe)了该直播间;

进入之后在直播间发送弹幕,视为向这个直播间发送(publish)了一条消息;

而由于进入直播间的用户都已经订阅过该直播间,所以其他用户都看到了这条弹幕。

一旦用户退出了直播间,则视为取消订阅(unsubscribe)了直播间,再也收不到该直播间里面其他用户发布的弹幕了。

传统的消息发布过程

传统的消息发布过程有两种,第一种是遍历列表里的每一个UID,读取路由,逐一发送消息;

第二种是遍历每一台服务器,发送消息,然后将订阅关系保存在每一台服务器内。以上两种做法都有可能导致延迟过多的问题。

云巴的消息发布过程

在云巴,消息的发布过程为,首先在接收到任务请求后,会发布任务计算UID列表分片,对总任务进行分片处理。之后将分片任务分发给任务池,执行各个分片任务。最后,发布任务汇聚请求,返回所有的分片任务。

「分片」——「汇聚」设计的好处在于,可以有效控制最大延迟。目前云巴是将此整个过程控制在200ms以内。除此以外,还能够扩大任务池,提升系统并发能力。

云巴弹幕Demo

返回顶部