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

时间 2019-11-09

标签并发实时直播研发实践繁體版

原文原文链接

直播间特色

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

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

云巴系统设计中，多层结构意味着一个基本业务逻辑的完成须要经历多个模块（如图上所示）。服务器

云巴多层结构设计有三个主要特色：架构

全部模块都可独立运行，互不干扰。任一模块在运行的过程当中，无需依赖其余模块。除此之外，还会对全部模块设立在线监控，从而实现生产状态下的实时告警。同时，模块独立运行还可以达到持续集成的效果；并发
细粒度扩容，包括但不限于对接入进行扩容等；ide
使用「隔离」。顾名思义，系统能够为用户指定特定的路径，也能够在某些路径出现问题之后，强行从系统里摘除路径，达到「隔离」效果。微服务

虽然近期微服务已一个新兴事物的身份被普遍讨论，但其实，微服务能够算是一个老概念了。架构设计

好比Erlang/OTP就是一个成熟已久的典型微服务架构。其做为微服务架构的特色就在于业务逻辑很是简单的同时，并发量也很是高。设计

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

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

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

长链接任务即为，当一个长链接接入时，系统会建立一个任务来管理和维持长链接；

一样地，请求任务则是，当一个用户请求（好比发送一条弹幕）产生时，就会建立一个任务来管理该请求。

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

好比，一个用户进入了一个直播间，则能够视为订阅（subscribe）了该直播间；

进入以后在直播间发送弹幕，视为向这个直播间发送（publish）了一条消息；

而因为进入直播间的用户都已经订阅过该直播间，因此其余用户都看到了这条弹幕。

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

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

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

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

返回全部的分片任务。

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