编者按&＃xff1a;随着交互方式的升级&＃xff0c;直播技术成为目前备受关注的领域之一。直播提供了多种用户互动的方式&＃xff0c;譬如 实时弹幕、打赏礼物等&＃xff0c;这对当下的直播应用来说是必不可少的。云巴 CEO 张虎在本次实践日上&＃xff0c;分享了如何实现一个极高并发的直播实时弹幕系统的经验&＃xff0c;探讨高并发实时直播弹幕研发的技术难题和解决方案。以下是他演讲的内容。
演讲嘉宾&＃xff1a;张虎&＃xff0c;云巴创始人。 JPush 创始人&＃xff0c;原 CTO&＃xff0c;创意并主导开发的系统为过万开发者、过亿终端用户提供了推送服务。Oracle VM 的创始团队成员&＃xff0c;早在 2007 年就开始基于 Xen 做开发。
直播间的特点
直播间与聊天室的区别很小&＃xff0c;但直播间的人数不像聊天室那样受到限制。传统的聊天室&＃xff0c;比如 QQ 群、微信群&＃xff0c;一般是 500 人、 1000 人的规模&＃xff0c;但直播间需要的却是人越多越好。
人数限制如何形成的&＃xff1f;
直播间不能限制人数是硬性的业务需求。早期聊天室之所以限制人数并不是因为业务需求&＃xff0c;而是技术瓶颈的原因。一个聊天室由单服务器和单进程完成&＃xff0c;单服务器意味着 CPU 资源和带宽都是有限的&＃xff0c;单进程意味着一次消息群发时&＃xff0c; ON 的时间复杂度&＃xff0c;即遍历列表越长&＃xff0c;遍历时间延迟就会越大。如果做一个实验&＃xff0c;就会发现早期 300 人的延迟是最好的&＃xff0c;后来服务器更新&＃xff0c;硬件质量越来越好&＃xff0c;延迟也更低&＃xff0c;(所以人数限制)是一个技术限制&＃xff0c;就像早期的网络游戏&＃xff0c;一个区大概有 200 人在线&＃xff0c;这也是一个技术限制。一台物理机在 200 人的时候体验还可以&＃xff0c;如果人数过多&＃xff0c;体验便会很糟糕。
直播间面临的挑战
如果要支持万级、几十万级的实时互动是很有挑战的&＃xff0c;必须要跨服务器、多进程并发。如果在这种高并发的情况下&＃xff0c;仍然使用单进程的做法&＃xff0c;那么最后一个收到消息和第一个收到消息的时间跨度非常大&＃xff0c;跨服务器主要解决单一服务器接入数量限制的问题&＃xff0c;如果一个直播间不能跨多个服务器&＃xff0c;用户在线数量就会受到物理上的限制和单一服务器的吞吐限制。带宽是有限制的&＃xff0c;CPU 是有限制的&＃xff0c;不可能无限的放大。众所周知 CPU 的主屏基本都是上限的&＃xff0c;在现阶段如果想做的话&＃xff0c;必须要突破这两个限制(单一服务器接入数量限制和单一服务器发布消息吞吐限制)&＃xff0c;第一需要跨服务器&＃xff0c;第二减少循环的规模&＃xff0c;降低延迟&＃xff0c;使用多任务或多进程。聊天室或直播间的人数是可以切片处理的&＃xff0c;假设它里面有 4 万人&＃xff0c;可能 1 分片 500 人&＃xff0c;这样就能降低规模&＃xff0c;即每一个进程需要面临的规模其实只有 500 &＃xff0c;当然进程数比较多&＃xff0c;也需要管理多进程的任务。
云巴实时系统的设计
从两个角度来介绍云巴的系统设计&＃xff1a;多层结构和微服务化。它们具有一定的关连性&＃xff0c;多层结构意味着一定要有服务化。
多层结构是指一个基本的业务逻辑的完成&＃xff0c;需要经过很多模块。例如接入云巴的系统&＃xff0c;接入服务器(也可称为前端服务器)接进来&＃xff0c;它并不处理业务逻辑&＃xff0c;它仅仅是对接入的请求进行验证&＃xff0c;确认是否有权限、SL 密钥是否正确、编解码以及确认请求的内容。再通过一个内部的消息队列进行部署。如下图所示&＃xff0c;这个消息队列是一个集群&＃xff0c;每个机房都有一个自己的集群&＃xff0c;所以接入服务器其实是很多集群&＃xff0c;它可以跨多个机房去部署&＃xff0c;通过内部的消息队列把消息转入主逻辑。例如它发现一个登陆的请求&＃xff0c;主逻辑会去确认登陆时需要做什么&＃xff0c;其中一个重要的事情是修改路由表。假设有一个客户端&＃xff0c;它从北京或者广州的机房接进来&＃xff0c;主逻辑发现已登陆成功&＃xff0c;它便会修改全局路由表&＃xff0c;其他的逻辑就可以通过这个全局路由表看到这件事。再举例&＃xff0c;如果做一个订阅动作&＃xff0c;需要从接入端发一个订阅请求&＃xff0c;通过 MQ 转到主逻辑&＃xff0c;主逻辑会修改订阅关系&＃xff0c;且这个订阅关系也是一个独立的全局都可以访问的服务。
发消息的时候也会涉及几个方面&＃xff0c;例如在一个直播间发一个消息&＃xff0c;推送端要知道这个直播间有哪些人在线&＃xff0c;才能把消息有效的分发出去&＃xff0c;如果想知道在线的人在什么位置&＃xff0c;就需要读全局路由表和订阅关系。另一个方面&＃xff0c;离线消息的保存。例如每个人都希望能收到主播更新的消息&＃xff0c;但某些人可能因为不在线而无法收到消息&＃xff0c;这时就会需要离线消息。如果某个主播的关注量很大&＃xff0c;有近几十万的粉丝&＃xff0c;这种情况下存一个离线消息的延迟会很大。云巴做了一个设计——别名的存储&＃xff0c;这是为了帮助客户的帐号系统和云巴的帐号系统做一个预设&＃xff0c;每个客户或者主播都有自己的 UID &＃xff0c;显然大家不愿意分享自己的 UID&＃xff0c;云巴可以通过别名把客户的 UID 跟自己内部的 UID 做绑定&＃xff0c;并且支持安卓和 iOS 的推送。
多层结构的特点
多层结构有优点与缺点&＃xff0c;其中最主要的优点&＃xff0c;即每一个模块都可以独立运行&＃xff0c;例如接入、主逻辑或者里面任意一个逻辑、节点&＃xff0c;多层结构都可以独立运行。编好之后运行&＃xff0c;不需要依赖于任何其他的模块&＃xff0c;有输入就可以得到输出。在这样的情况下&＃xff0c;不管是开发、测试、部署还是后期的运维&＃xff0c;都可以极大地提高效率。例如定位一个问题时&＃xff0c;只需要看每一个模块的输入和输出&＃xff0c;通过输入检查输出是否按照预期的行为输出&＃xff0c;定位问题后找出问题最上游的模块进行解决。如果该模块的问题被解决后逻辑仍有问题&＃xff0c;就看它下游的模块。云巴给所有模块定义了一个在线监控的点(称为环回测试)&＃xff0c;即定期通过每个模块接受的输入检查输出是否正确&＃xff0c;且还回测试是在线的(生产状态中的)。如果环回测试报警了&＃xff0c;则意味着那个模块的生产业务逻辑出问题了。
第二个优点&＃xff0c;开发可以很容易地做持续集成。例如发一个新版本&＃xff0c;模拟测试环境跟直接生产还是有差距的。这时候可以挑一台机房&＃xff0c;在机房加一台服务器&＃xff0c;把免费用户 1% 的流量导上去&＃xff0c;观察该模块一周内是否可以正常运作&＃xff0c;这是很有说服力的测试。针对这个云巴很容易做到&＃xff0c;因为云巴的每个逻辑基本都是切开的&＃xff0c;加一个点的时候它其实只有一个模块&＃xff0c;即这 1% 的流量从新加的节点上去&＃xff0c;所以它对开发也会有很大的帮助。举个具体的例子&＃xff0c;早期的时候这个结构里很多都是用 Node.js 写的&＃xff0c;后来发现它更适合用来做网站。最早云巴是从主逻辑开始做迭代&＃xff0c;把主逻辑换成 Erlang &＃xff0c;但团队的人都是第一次用 Erlang &＃xff0c;当时很担心上线有问题&＃xff0c;所以采取了上述方法。刚开始导几十分之一的流量上去&＃xff0c;一周后发现运作情况不错&＃xff0c;就慢慢的增加&＃xff0c;直到最后所有的模块全部被替换。另外&＃xff0c;上线的时间一般选在上午&＃xff0c;因为夜晚人容易困倦&＃xff0c;如果出问题了做及时调整的效率会很低。
第三个优点&＃xff0c;细粒度扩容。可以对接入扩容&＃xff0c;加一台服务器&＃xff0c;再导一些流量过去&＃xff0c;这就完成了扩容。如果发现服务器有问题&＃xff0c;把流量撤走即可。
第四个优点&＃xff0c;隔离问题。如果想要有效的跟踪定位到客户报的问题&＃xff0c;可以强制它(用户)从某一条有三至五台服务器的路径走&＃xff0c;在跟用户相关的信息上设置一些钩子&＃xff0c;这样可以从这三至五台服务器里收集信息&＃xff0c;从而能够看到关键性的用户&＃xff0c;甚至可以做性能的测量。所谓的隔离是指&＃xff0c;可以指定哪些用户从哪些路径走&＃xff0c;或者是哪些路径出问题之后&＃xff0c;可以把哪些路径摘除掉。发现问题最重要的不是解决问题&＃xff0c;而是隔离问题&＃xff0c;因为解决问题的周期是很难控制的。云巴作为一个线上系统&＃xff0c;客户等待的时间不能太长&＃xff0c;如果发现有介入或者问题&＃xff0c;第一步并不是思考如何解决问题&＃xff0c;而是先确认线上是否有闲置的服务器&＃xff0c;把客户切入到闲置的服务器&＃xff0c;再检查原来的点出了什么问题&＃xff0c;这样可以很好的控制处理问题的时间周期。
微服务化
其实微服务是一个比较老的概念&＃xff0c;观察 OTP 的框架&＃xff0c;它的诞生就是为了做微服务。S(Superviser)代指监控者&＃xff0c;W(Worker)指工作进程&＃xff0c;在 OTP 里是一个海量进程组成的进程数&＃xff0c;一个应用就是一整个进程树&＃xff0c;S 即该进程树的根。S 下面还继续监控 S 和 W。按照上图的设计&＃xff0c;下面的 S 和 W 数量是可以无限大的。所以 OTP 里用了海量的微服务&＃xff0c;任何一个应用的逻辑均做成这样&＃xff0c;具体的业务均由 W 完成&＃xff0c;这个 W 是一个 RPC Service 。 举例说明&＃xff0c;写一个很简单的逻辑&＃xff0c;收到请求后查询 Redis&＃xff0c;再返回结果。
用这个设计是如何完成的&＃xff1f;首先暴露一个 RESTful API 接口&＃xff0c;外面发一个请求给 W&＃xff0c;假设这个 W 连接了 Redis&＃xff0c;再转 Redis 的请求给 W &＃xff0c;该 W 再去真正的访问 Redis&＃xff0c;再返回把结果转发给 W&＃xff0c;最后把结果给客户端。云巴会把 HTTP 相关的、 Redis 相关的 分别做成一个独立的树&＃xff0c;里面可能有 50 多个 W&＃xff0c;可以用来做负载均衡和高可用&＃xff0c;如果出现了任何问题&＃xff0c;都可以直接撤掉之前的 W 再重建。所以在 OTP 的微服务框架里&＃xff0c;业务逻辑很简单&＃xff0c;并且可以做到很大的并发量&＃xff0c;即业务逻辑封装成一个 RPC service &＃xff0c;RPC service 部署为一个 OTP Worker。
轻量级任务
长连接的维持其实很简单&＃xff0c;把任何一个存在于系统里的连接定义为一个轻量级的任务&＃xff0c;由这个任务维持连接的心跳、观察它的动作或管理它的登陆和消息。任何一个用户发给系统的请求&＃xff0c;均由一个任务来处理。假设用户需要加入一个直播间&＃xff0c;这个动作就可以用一个任务来处理&＃xff0c;用户发了一个加入直播间的请求&＃xff0c;它就会去检查是否有权限&＃xff0c;最后会返回一个结果检查用户的动作是否成功&＃xff0c;这里会涉及到很多模块的操作&＃xff0c;并且它是一个极大并发。直播平台业务量的增加是很难控制的&＃xff0c;云巴的方法是确认目前的硬件资源是否能支撑现有的业务需求。如果不能支撑&＃xff0c;可以通过增加硬件资源来扩大池子(例如处理订阅频道和发布消息的池子)&＃xff0c;这样做的情况下&＃xff0c;不需要知道每一个具体的任务是什么&＃xff0c;只要确认任务池跟硬件资源的水位线差距是多少。如果水位线超过 80%&＃xff0c;可以增加硬件资源扩大池子&＃xff0c;在下一次的调度时&＃xff0c;即可找到闲置的资源来处理任务。
任务与运行位置无关
根据上述场景加一台硬件后&＃xff0c;就可以调度新任务&＃xff0c;它的表象是可以动态地把任务接入到不同的物理机&＃xff0c;具有能够随时扩容系统里任何一个点的优势。因为不同的模块承受的压力不同&＃xff0c;大部分的直播应用最大的压力来源于发布消息。如果想做到任务运行跟位置无关&＃xff0c;那么所有的数据都需要独立存储&＃xff0c;即存在一个独立的集群&＃xff0c;有一个单一的路口&＃xff0c;即使将来扩展到 50 台机器&＃xff0c;还是可以使用同样的方式访问。任务运行时&＃xff0c;数据相当于从第三方里读出来&＃xff0c;不会在扩容里会出来。
海量消息发布过程
举例说明&＃xff0c;一个几万级量级的过程要达到实时&＃xff0c;需要做很多预备性的处理&＃xff0c;例如在订阅关系和路由的数据上分片&＃xff0c;或者是一个直播间里有 4 万人&＃xff0c;想一次性读出 4 万个 UID &＃xff0c;它的延迟很明显&＃xff0c;如果数量更多延迟就会更明显&＃xff0c;所以并不能仅用一个包就把它读出来。正如上述所说&＃xff0c;每一个 UID 都有一个自己接入点的路由信息&＃xff0c;是一个比较长的数据&＃xff0c;想做到一次性读出来&＃xff0c;一定要做分片。修改这些数据时需要也准备好分片&＃xff0c;下一步再进行切分任务发布执行。
如果用户列表里有 4 万个 UID&＃xff0c;一定要把它切开&＃xff0c;现在的做法是每片切到 200 个 UID&＃xff0c;这意味着需要用更多的任务来处理一次发布&＃xff0c;总体消耗比较大&＃xff0c;因为任务的创建本身是有消耗的。这时需要找一个平衡点&＃xff0c;因为每个分片足够小时&＃xff0c;最大延迟也会足够小&＃xff0c;但如果分片太小了&＃xff0c;又会面临任务规模变大的问题。
发布过程
一般过程(一)
所谓的一般过程&＃xff0c;实际上是一个很典型的聊天室的做法&＃xff0c;遍历列表里的每一个 UID&＃xff0c;读取路由&＃xff0c;逐一发消息。
一般过程(二)
这个过程用了很多接入服务器&＃xff0c;但没有做路由器的管理。它不管直播间的用户是从哪里接过来的&＃xff0c;仅仅简单地给每个服务器发命令&＃xff0c;每个服务器再进行判断 UID 是否加入直播间(是否订阅频道)&＃xff0c;它需要每台接入服务器管理订阅关系。但这里存在一个同步的问题。
云巴的消息发布
类似于 Map/Reduce &＃xff0c;这里有三个重要的点&＃xff0c;第一个是任务可以切分。第二个是不论任务的数据被分发到哪一个处理节点上&＃xff0c;数据都是没有问题的。另外&＃xff0c;任务逻辑的运行跟位置没有相关性。第三个是需要有一个发布任务&＃xff0c;汇聚所有分发出去的反馈结果&＃xff0c;再返回给客户端。
这个发布过程的再大优点&＃xff0c;是有效控制最大延迟。假设直播间里有 4 万人&＃xff0c;以用户收到的最后一个消息为准来评估延迟的时长&＃xff0c;所有程序的调优参数均以此作为指标&＃xff0c;即延迟控制在 200 ms 以内。第二个优点&＃xff0c;平行扩展。极大并发量时&＃xff0c;简单地往里面加服务器即可&＃xff0c;一样可以将延迟控制在 200 ms 以内。如果要控制发布过程的延迟&＃xff0c;加入的服务器需要专门用来处理发布消息&＃xff0c;这样就可以控制住最大的延迟。
京公网安备 11010802041100号