Twitch是一个面向视频游戏的实时流媒体视频平台，由Justin Kan和Emmett Shear联合创立，它是Justin.tv旗下专注于游戏相关内容的独立运营站点。根据其内部分析师透露，Twitch每月的访问量超过3800万，有超过2000万个游戏玩家汇聚到这个平台，每个访问用户在网站的日平均停留时间为1.5小时。网站支持28个国家和地区的语言，包括中文简体和繁体。

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

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.

跟着 YouTube 等一众厂商的脚步，现在连游戏直播服务 Twitch 也"开始"弃用 Flash 改用 HTML5 了。根据官网的消息，Twitch 目前已经完成了第一步骤，先将旧的 Flash 模块改成了 HTML5 + Javascript 的组合，重新设计了播放控制界面。既然说到这是第一步，这代表了其实 Twitch 的视频本身还是以 Flash 为基础的架构，所以接下来才是要渐渐地将播放器完全置换为从里到外都是 HTML5 基础。新的界面已经可以在 Channel 页面上看到，并且已经逐步地向使用者开始推送，所以看到界面变得比较不同可别以为走错网站了喔。

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

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架构，两个架构图如下：