视频云面向海量用户的分布式视频处理技术

系统介绍

网易视频云支持面向海量用户的分布式视频处理,包含录制、转码、视频合成、截图等常用的视频处理任务。一方面视频云承载了众多网易内部视频应用的后台视频处理,一方面也渐渐以公有云的身份走入大家视野。

视频云的视频处理子系统需求模型如下所示:


视频云上层服务根据业务模型,向视频处理子系统发起视频处理任务,处理子系统根据任务类型调度到合适的worker节点做处理。在任务产生事件时,处理子系统会将事件回调通知给上层服务,如录制切片事件、视频转码完成事件。

在过去几年,视频云为网易内部视频应用提供了稳定可靠的大规模音视频处理服务,如青果、云音乐、教育产品。近两年,随着公有云服务模式趋于成熟,网易视频云渐渐以公有云的身份被大家所了解,与私有云相比,公有云的视频云要面临以下两个挑战:

1.  海量用户

2.  资源超售

在内部服务时代,视频云需要服务的应用数量有限,调度系统和回调系统压力较小,而且可以为一些应用定制特殊功能。而在公有云服务中,面向海量企业用户,调度系统承担的压力更重,在保障公平调度的基础上,需要实现调度能力的水平扩展。

在为内部应用提供服务时,为了保障各个应用的服务质量,一般不做处理资源超售,但是在公有云中,由于用户太多,资源闲置是一种常态,不超售会造成极度的资源浪费。因此,在保障公有云的服务质量前提下,最大限度的节约成本是视频云在公有云场景下需要攻克的重要课题之一。为了做好这一点,公有云提供了比以前更加细致的任务统计,资源监控,便于公有云的容量规划。

系统架构

视频云的视频处理系统架构如下图所示:


sdk:接口层,上层服务通过SDK向视频处理系统发起任务和事件回调

scheduler:调度子系统,又分为在线调度器和离线调度器

worker:任务执行器,一般包含10-1000个slot,每个slot对应一个处理任务

notifier:事件回调子系统,收集各个worker中的任务事件,并通知SDK

configserver:集群管理,元数据同步,任务统计和资源监控等

dashboard:可视化运维的WEB工具

以上模块和子系统的实现,满足了视频云对用户管理、任务调度、任务追踪、事件回调和文件存储等核心功能需求。在非功能性方面,视频云实现了调度子系统的高可用和水平扩展,worker宕机重试。configserver在架构中属于单点,通过主从架构实现高可用。

核心技术

FlickRpc框架

FlickRpc是视频云团队自主研发的一个通用rpc框架,是各个组件模块互相调用和通信的基础。FlickRpc采用了netty长连接和json通信格式,使用google的gson库实现json格式的序列化和反序列化,与grpc,avro一类的开源RPC框架相比,FlickRpc无需定义消息格式,可像使用本地方法一样调用RPC,并且 FlickRpc中不存在json反序列化与JAVA继承的冲突,更加简单易用;FlickRpc提供了同步调用和异步调用两种模式,可以通过静态上下文获取RPC远端信息;虽然FlickRpc是为视频云开发,但其本身是一个通用RPC框架,可以在任何系统中使用。

FlickRpc的使用极大简化了视频云在通信层的开发量,未来FlickRpc会独立开源。

灵活的调度模式

视频云视频处理系统有在线和离线调度器两种不同调度子系统,在线调度器适用于录制、截图以及在线视频合并等在线视频处理。这种任务的特点是具有很强的时效性,需要实时调度。例如录制任务,如果调度产生较大延迟,会导致录制内容丢失。

离线调度器适用于各种类型的转码业务,特点是任务可以积压,可以慢慢异步消费。如点播系统的视频转码,一个用户可以一次性提交很多待转码视频,只要在一个笼统的时间范围内完成即可,无需所有任务实时调度。

离线调度器是视频云超售的基础,因为只有允许一定的任务积压,才能在保证服务可靠的前提下节约资源成本。

租约与高可用

configserver和其他组件通过租约的方式实现元数据同步和高可用,以离线调度器高可用为例,如下图所示:


调度器A和调度器B负责调度不同用户的离线任务,A和B在启动时会向configserver注册,并获取元数据和租约信息,以及他们各自需要调度哪些用户。A和B每隔一段时间(5s-60s)会向configserver续租,如果A在某个时间宕机,一段时间后configserver会发现A持续多个周期没有续租,为了保障用户调度的高可用,configserver需要将A负责的调度任务交由相邻节点B继续执行,为此configserver会更新B的租约,在下次B续租时可以更新到新的租约和元数据,并触发reload。

通过租约机制,可以实现不同组件的元数据同步,调度器的水平扩展和主从模式等。

负载均衡

一个视频处理集群中,可以部署多个worker group,任务参数中可以指定在哪个worker group中执行,worker group的划分使视频云可以在容量规划中因地制宜,例如录制任务需要大量的IO操作,因此录制任务的worker group需要配备SSD和千兆网络,而录制过程几乎不会耗CPU资源,可以在CPU配备上节约成本,而转码任务反之。

在一个worker group内,任务调度在没有超过worker slot上限的前提下,采用取模哈希的方式满足负载均衡,当worker调度到的任务数到达slot上限,会从调度器中剔除,直到新的slot空闲出来。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270

推荐阅读更多精彩内容