Twitch作为游戏直播网站的领导者，主要采用了什么技术？

Twitch是一个面向视频游戏的实时流媒体视频平台，由Justinkan和Emmetshear联合创建，是Justin.专注于游戏相关内容的TV独立运营网站。据其内部分析师介绍，Twitch每月访问量超过3800万，游戏玩家超过2000万聚集在该平台上，每个访问用户每天平均停留时间为1.5小时。该网站支持28个国家和地区的语言，包括中文简体和繁体。Twitch的直播模式与YouTube等点播批处理方式完全不同。直播对技术的要求更高、更困难，这也是国内电视直播仍然依赖有线网络的原因。互联网上的电视直播业务大大降低了直播效果，Twitch探索了利用互联网技术实现流畅、不间断直播的成功之路。Twitch直播视频不同于YouTube的批处理视频:后者将所有视频存储在磁盘上，然后根据要求重播，直播视频同时存储和*视频存储和视频阅读，因此需要完全不同的系统结构。以下是其技术堆栈：Usher-它的核心系统是Twice-可定制的web缓存系统，用于实现视频流*的业务逻辑服务器(http://code.google.com/p/twicecache/)XFS-文件系统将视频以秒为单位存储在系统中，HAProxy-软件负载平衡.LVSstack和ldirectord-保证高可用性.RubyonRails-应用程序服务器Nginx-web服务器PostgresQL-存储用户和其他元数据MongodB-存储用户操作事件的内部分析MemcachedB-处理浏览量Syslog等高密度集写操作-ng-Job系统用于日志服务RabitMQ-.Puppet-用于构建服务器.Git-源码控制.Wowza-Flash/H.264视频服务器，许多定制模块使用Java编写S3-smallimagestorage.跟着YouTube等厂商的脚步，现在连游戏直播服务Twitch都是"开始"弃用Flash改用HTML5。根据官网的消息，Twitch已经完成了第一步，将旧的Flash模块改为HTML5 Javascript的组合重新设计了*控制界面。根据官网的消息，Twitch已经完成了第一步，将旧的Flash模块改为HTML5 Javascript的组合重新设计了*控制界面。由于这是第一步，这意味着Twitch视频本身仍然是基于Flash的架构，因此需要逐步将*器从内到外完全替换为HTML5基础。新界面可以在Channel页面上看到，并逐渐推送给用户，所以看到界面变得不同，不要认为网站错了。有一个问题:为什么视频直播这么难？似乎只需要大量的带宽，让这一切都在内存中，围绕流进行视频组合，其实并没有那么简单。是什么让视频直播如此具有挑战性？1.视频不能像打嗝一样中断。如果视频超过网络容量，即使是几分之一秒，每个观众也会同时在屏幕上看到“缓冲”.“。拥有网络容量非常重要。2.CDN需要实现溢流overflowusher来处理这一逻辑。一旦用户数量超过最大容量，新的*器将被发送到CDN服务器。3.当观众迅速发现任何问题时，他们会立即交谈。用户希望能够优雅地处理这些问题。服务器维护模式必须等到服务器上的每个观众完成浏览。维护过程非常缓慢。会话必须从未中断。一般情况下，网站可能会出现很多错误，但很少有人会注意到，而直播系统则不同。我们来看看Twitch是如何应对这些挑战的。他们最大的问题是控制闪光人群。所谓闪光人群，就是很多人同时想看同样的事情。这是一个巨大的传入流量。因此，他们需要在所有视频服务器和数据中心之间创建实时适应负载的方法。这种机制是Usher。Usher是他们开发的管理负载平衡授权和*等其他业务逻辑的软件。Usher计算每个流视频中发送多少服务器，以确保最佳负载。它实时决定如何在这些服务器之间复制流量。复制依据的规则包括：所有服务器的单独负载优化延迟哪些服务器上的用户IP地址，以便区分用户来自哪个国家，根据路由route数据库找到最接近用户IP的ISP.试图将该请求发送到同一数据中心的视频服务器。使用这些优化指标可以指导优化每个服务器的请求，以确保更好的延迟和性能优化。它们还有大量的监控调整表盘和非常细粒度的控制。每个服务器都可以充当边缘服务器(服务器的视频直接发送给观众)和源服务器(视频从广播流入服务器)。不断动态调整一台服务器或网络中每台服务器上的负载策略。服务器之间复制流的连接就像树形结构，流量不断取样。如果一个流量的新浏览量迅速增加，流量将被复制到其他服务器中。这个过程将重复并构建一个树形(banq注释：根据结构定律，树形是最有效的生命系统特征)，最终可能涵盖某个网络中的所有服务器，每三秒执行一次。从源服务器到复制到其他服务器，再到复制到用户，整个视频流始终存储在内存中，没有任何磁盘存储。使用RTMP协议（视频流*协议），每个流都需要一个独立的对话，这将带来昂贵的成本，但广播和P2P技术没有使用，许多下游ISP不支持多广播，只是使用内部服务器视频复制，内部带宽相当便宜，但没有太多好处，因为细粒度控制在服务器之间。根据HTTP请求，Usher决定哪个服务器来处理请求的视频，而视频服务器通常是被动的，Usher控制整个服务器的拓扑结构。视频流不来自磁盘。视频存储在磁盘中。源服务器将被选择来处理上传的新视频流。记录本地磁盘中的流量。视频每秒都被保存和归档。归档存储服务器使用XFS文件系统。该架构可以处理数千个并发流视频传输写作。每个视频流缺省保存7天，视频文件可以跨磁盘分区保存。从其他重量协议转移到HTTP流协议是快乐的，可以利用现有技术进行良好的扩展。然而，有一个问题必须积极面对，那就是延迟和实时问题。人们通常认为不超过5-30秒是实时的，但这不适用于成千上万人的实时通信交互，也不能有1/4秒的延迟。以上是视频广播复制系统的介绍，它们还有一套Web架构，两个架构图如下：