Twitch(Justin.tv)的技术架构

Twitch的直播模式完全不同于YouTube等点播批处理方式,直播对技术要求更高更难,这也是目前国内电视直播还依赖有线网络的原因,而互联网上的电视直播业务在直播效果上要大打折扣,而Twitch则是在利用互联网技术实现流畅不间断直播上探索了一条成功道路。

8月25日,亚马逊宣布,公司将以9.7亿美元 (约合人民币59.7亿元)的价格收购全球最大的游戏视频直播商TwitchInteractive(以下简称Twitch)。此前谷歌还一度准备收购Twitch。

Twitch的前身是Justin.tv,于2011年正式推出,主营业务是做在线的视频游戏直播和数字视频直播。精选游戏包括《DOTA2》、《星际争霸2》和《魔兽世界:潘达利亚的迷雾》等。截至2014年4月7日,Qwilt统计美国在线流媒体视频流量中有43.6%都来自Twitch。今年2月,Twitch的峰值互联网流量在全美排名第四,仅仅次于视频点播巨头Netflix 谷歌和苹果,比Hulu、亚马逊、Facebook都高。

Twitch直播视频和是YouTube的批处理视频不同是:后者将所有视频存储在磁盘上,稍后根据要求进行重播,而直播视对频视频存储写和视频读播放是同时进行的,因此需要一个完全不同的体系架构。下面是其技术堆栈:

Usher - 这是其核心系统,用来实现对视频流播放的业务逻辑服务器
Twice - 可定制的web缓存系统(http://code.google.com/p/twicecache/)
XFS - 文件系统 将视频以秒为单位存储该系统中,
HAProxy - 软件负载平衡.
LVS stack 和 ldirectord - 保证高可用性.
Ruby on Rails - 应用服务器
Nginx - web 服务器
PostgreSQL - 存储用户和其他元数据
MongoDB - 用于存储用户操作事件实现内部分析
MemcachedDB - 用于处理高密集写操作如浏览数量
Syslog-ng - 日志服务
RabitMQ - 用于 job 系统.
Puppet - 用于构建服务器.
Git - 源码控制.
Wowza - Flash/H.264 视频服务器, 许多定制的模块使用Java编写
S3 - small image storage.

为什么视频直播那么困难?好像只需要大量的带宽,让这一切在内存中,围绕流进行视频组合就可以了,其实没那么简单。是什么让视频直播有如此这样的挑战力?

1. 视频不能像打嗝一样存在中断, 如果视频超过网络容量哪怕几分之一秒,每一个观众在同一时刻将看到屏幕上显示“正在缓冲...“。拥有网络容量是非常重要的。

2.需要CDN实现溢流overflow Usher会处理这个逻辑,一旦用户量超过最大容量,新的播放者将被发往CDN服务器。

3.当观众快速发现任何问题就会立即交谈聊天。用户期望能够优雅地处理这些问题。他们必须等到一台服务器上的每个人观众完成浏览后才能让这台服务器维护模式。这是一个非常缓慢的维护过程。会话必须从未中断。通常的网站可以有许多错误只是很少人会注意到,而直播系统则不同。

下面看看Twitch如何应对这些挑战?
他们最大的问题是控制快闪的人群,所谓快闪人群,就是当很多人在同一时间想看同样的事情。这是一个庞大的传入流量。因此,他们需要创建一个方法来在所有的视频服务器和数据中心之间实现实时适应性负载。该机制是Usher。

Usher是一个他们开发的软件,用来管理负载平衡 授权和播放等其他业务逻辑。Usher对每个流视频都要计算出有多少服务器在发送它们,这样确保最佳负载。 它实时决定如何在这些服务器之间复制流,复制依据的规则有:
所有服务器的单独负载
优化的延迟
一个流在哪些服务器上
用户的IP地址,这样能够分辨用户来自哪个国家
根据路由route数据库寻找离用户IP最近的ISP.
根据请求来自的数据中心,试图将这个请求发往同一个数据中心的视频服务器。

使用这些优化指标可以引导优化每个发往服务器的请求,以保证更好的延迟和性能优化。他们还有很多的监控调校表盘和非常细粒度的控制。

每个服务器可以充当一个边缘服务器(该服务器的视频直接发送到观众)和源服务器(视频从一个广播流进该服务器)。基于一个流可适用一台服务器或网络中的每台服务器上的负载策略,不断进行动态的调整。

服务器之间复制流的连接如同树形结构,流的数量不断被取样,如果某个流的新增浏览有快速增加,这个流就会被复制到其他服务器,这个过程不断重复,构建出一个树形(banq注:根据构造定律树形是最有效生命系统特征),最终可能涵盖了某个网络中所有服务器,这个过程每三秒执行一次。

整个视频流从其源服务器到拷贝到其他服务器直至复制到用户都时刻在内存中,其中没有任何磁盘存储。

使用 RTMP协议(视频流播放协议),每个流都需要一个独立的会话,这会带来昂贵的开销,但是广播多播和P2P技术没有使用, 很多下游的ISP不支持多播,只是利用多播在内部服务器进行视频复制,内部带宽相当廉价,但是也没有太多好处,因为无法细粒度控制在服务器间复制。

Usher根据HTTP请求,决定哪个服务器来处理请求的视频,而视频服务器一般是被动的,Usher在其之前控制整个服务器的拓扑结构。

视频流不是来自磁盘,视频是归档存储在磁盘,源服务器会被挑选出来处理一个上传进来的新的视频流,记录这个流在本地磁盘,每一秒视频被保存和归档,归档存储服务器是使用XFS文件系统。架构能够处理数千个并发流视频传入写。每个视频流缺省保存7天,视频文件可能跨磁盘分区保存。

从其他重量协议迁移到HTTP流协议是快乐的,能够使用现有技术进行很好地扩展,但是有一个问题必须积极面对,就是延迟和实时性问题,通常人们认为不超过5-30秒就是实时的了,但是这个不适用成千上万人实时通讯交互,不能有1/4秒的延迟。

以上是介绍了视频广播复制系统,他们还有一套Web架构(细节点击标题看英文),两个架构图如下:



我感觉就是一个负载平衡,有啥特别。。。