高并发实时直播弹幕研发实践
直播间特点
聊天室限制人数的原因
应对万级以上的实时互动
跨服务器是为了解决单一服务器接入数量限制、发布消息吞吐限制等问题； 多进程并发则是为了充分利用多核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以内。除此以外，还能够扩大任务池，提升系统并发能力。
