网站框构分析 一

Facebook用户量大的问题由它的分布式缓存系统主要解决，剩下的天然是开源的mysql更合适了

上图是Facebook的photo访问服务图，实际上你能够看见，数据库是在最末端，Cache层已经服务了90%的需求，对于热点图片命中率接近100%，不是说数据库已经不重要了，而是这种重要性下降了，数据库并非直接与用户进行交互，中间隔了好几层高速Cache，在这种状况下，用本身定制的（注意是定制的）免费的Mysql已经足以知足这汇总需求，何须再去花更多的钱了？

\n

同时，Facebook上全部用户进行读的操做远大于其写的操做，所以Cassandra这样的写很是快的NoSQL数据库，Facebook并无采用。

Craigslist使用了Mongodb，Amazon使用了SimpleDB，Facebook使用了HBase；58同城根据本身的业务特色，在分类信息，电子商务，社会化网络等领域，除了使用自有存储技术以外，也在使用Redist，Mongodb，Hbase等开源存储技术。
最牛B的数据库Oracle，在阿里内部已经彻底用不了了，替代成为本身开发的OceanBase和改造过的MySQL；IBM的小型机，一直是高性能计算的标志，但已经彻底由阿里本身定制的硬件代替；EMC的存储设备在工业界应用也很普遍，但在阿里也去掉了；阿里内部有个专门的团队在对Linux内核进行优化和修改，定制出适合阿里的Linux系统；支付宝天天百亿级的交易额，几千万笔交易，也必须有独特的安全解决方案

本文是整理的关于优酷、YouTube、Twitter及JustinTV几个视频网站的架构或笔记，对于无论是视频网站、门户网站或者其它的网站，在架构上都有必定的参考意义，毕竟成功者的背后总有值得学习的地方，虽然有些文章的发表时间有点久了，可是看看对开阔视野仍是有帮助的。

优酷视频网站架构

1、网站基本数据概览
据2010年统计，优酷网日均独立访问人数（uv)达到了8900万，日均访问量（pv）更是达到了17亿，优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商。
硬件方面，优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主，存储阵列以戴尔MD1000为主，2007的数据代表，优酷网已有1000多台服务器遍及在全国各大省市，如今应该更多了吧。
2、网站前端框架
从一开始，优酷网就自建了一套CMS来解决前端的页面显示，各个模块之间分离得比较恰当，前端可扩展性很好，UI的分离，让开发与维护变得十分简单和灵活，下图是优酷前端的模块调用关系：

这样，就根据module、method及params来肯定调用相对独立的模块，显得很是简洁。下面附一张优酷的前端局部架构图：

 
3、数据库架构
应该说优酷的数据库架构也是经历了许多波折，从一开始的单台MySQL服务器（Just Running）到简单的MySQL主从复制、SSD优化、垂直分库、水平sharding分库，这一系列过程只有经历过才会有更深的体会吧，就像MySpace的架构经历同样，架构也是一步步慢慢成长和成熟的。
一、简单的MySQL主从复制:
MySQL的主从复制解决了数据库的读写分离，并很好的提高了读的性能，其原来图以下：

其主从复制的过程以下图所示：

可是，主从复制也带来其余一系列性能瓶颈问题：
-写入没法扩展
-写入没法缓存
-复制延时
-锁表率上升
-表变大，缓存率降低
那问题产生总得解决的，这就产生下面的优化方案，一块儿来看看。
二、MySQL垂直分区
若是把业务切割得足够独立，那把不一样业务的数据放到不一样的数据库服务器将是一个不错的方案，并且万一其中一个业务崩溃了也不会影响其余业务的正常进行，而且也起到了负载分流的做用，大大提高了数据库的吞吐能力。通过垂直分区后的数据库架构图以下：

然而，尽管业务之间已经足够独立了，可是有些业务之间或多或少总会有点联系，如用户，基本上都会和每一个业务相关联，何况这种分区方式，也不能解决单张表数据量暴涨的问题，所以为什么不试试水平sharding呢？
 
三、MySQL水平分片（Sharding）
这是一个很是好的思路，将用户按必定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增长，只要简单地配置一台服务器便可，原理图以下：

如何来肯定某个用户所在的shard呢，能够建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，以下图所示：

可是，优酷是如何解决跨shard的查询呢，这个是个难点，据介绍优酷是尽可能不跨shard查询，实在不行经过多维分片索引、分布式搜索引擎，下策是分布式数据库查询（这个很是麻烦并且耗性能）
 
4、缓存策略

貌似大的系统都对“缓存”情有独钟，从http缓存到memcached内存数据缓存，但优酷表示没有用内存缓存，理由以下：
避免内存拷贝，避免内存锁
如接到老大哥通知要把某个视频撤下来，若是在缓存里是比较麻烦的
并且Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存致使效率也比较低下。
但为什么咱们访问优酷会如此流畅，与土豆相比优酷的视频加载速度略胜一筹？这个要归功于优酷创建的比较完善的内容分发网络（CDN），它经过多种方式保证分布在全国各地的用户进行就近访问——用户点击视频请求后，优酷网将根据用户所处地区位置，将离用户最近、服务情况最好的视频服务器地址传送给用户，从而保证用户能够获得快速的视频体验。这就是CDN带来的优点，就近访问，有关CDN的更多内容，请你们Google一下。

这是一个完整的PDF：http://www.blogkid.net/qconppt/youkuqiudanqconbeijing-090423080809-phpapp01.pdf

转自：http://www.kaiyuanba.cn/html/1/131/147/7541.htm

YouTube网站架构

YouTube发展迅速，天天超过1亿的视频点击量，但只有不多人在维护站点和确保伸缩性。这点和PlentyOfFish相似，少数人维护庞大系统。是什么缘由呢？放心绝对不是靠人品，也不是靠寂寞，下面就来看看YouTube的总体技术架构吧。
平台
一、Apache
二、Python
三、Linux(SuSe)
四、MySQL
五、psyco，一个动态的Python到C的编译器
六、lighttpd代替Apache作视频查看

状态

一、支持天天超过1亿的视频点击量
二、成立于2005年2月
三、于2006年3月达到天天3千万的视频点击量
四、于2006年7月达到天天1亿的视频点击量
五、2个系统管理员，2个伸缩性软件架构师
六、2个软件开发工程师，2个网络工程师，1个DBA

Web服务器

1，NetScaler用于负载均衡和静态内容缓存
2，使用mod_fast_cgi运行Apache
3，使用一个Python应用服务器来处理请求的路由
4，应用服务器与多个数据库和其余信息源交互来获取数据和格式化html页面
5，通常能够经过添加更多的机器来在Web层提升伸缩性
6，Python的Web层代码一般不是性能瓶颈，大部分时间阻塞在RPC
7，Python容许快速而灵活的开发和部署
8，一般每一个页面服务少于100毫秒的时间
9，使用psyco(一个相似于JIT编译器的动态的Python到C的编译器)来优化内部循环
10，对于像加密等密集型CPU活动，使用C扩展
11，对于一些开销昂贵的块使用预先生成并缓存的html
12，数据库里使用行级缓存
13，缓存完整的Python对象
14，有些数据被计算出来并发送给各个程序，因此这些值缓存在本地内存中。这是个使用不当的策略。
    应用服务器里最快的缓存将预先计算的值发送给全部服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，而后发送。

视频服务

1，花费包括带宽，硬件和能源消耗
2，每一个视频由一个迷你集群来host，每一个视频被超过一台机器持有
3，使用一个集群意味着：
   -更多的硬盘来持有内容意味着更快的速度
   -failover。若是一台机器出故障了，另外的机器能够继续服务
   -在线备份
4，使用lighttpd做为Web服务器来提供视频服务：
   -Apache开销太大
   -使用epoll来等待多个fds
   -从单进程配置转变为多进程配置来处理更多的链接
5，大部分流行的内容移到CDN：
  -CDN在多个地方备分内容，这样内容离用户更近的机会就会更高
  -CDN机器常常内存不足，由于内容太流行以至不多有内容进出内存的颠簸
6，不太流行的内容(天天1-20浏览次数)在许多colo站点使用YouTube服务器
  -长尾效应。一个视频能够有多个播放，可是许多视频正在播放。随机硬盘块被访问
  -在这种状况下缓存不会很好，因此花钱在更多的缓存上可能没太大意义。
  -调节RAID控制并注意其余低级问题
  -调节每台机器上的内存，不要太多也不要太少

视频服务关键点

1，保持简单和廉价
2，保持简单网络路径，在内容和用户间不要有太多设备
3，使用经常使用硬件，昂贵的硬件很难找到帮助文档
4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具
5，很好的处理随机查找(SATA，tweaks)

缩略图服务

1，作到高效使人惊奇的难
2，每一个视频大概4张缩略图，因此缩略图比视频多不少
3，缩略图仅仅host在几个机器上
4，持有一些小东西所遇到的问题：
   -OS级别的大量的硬盘查找和inode和页面缓存问题
   -单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让 Ext3容许大目录，但在一个文件系统里存储大量文件不是个好主意
   -每秒大量的请求，由于Web页面可能在页面上显示60个缩略图
   -在这种高负载下Apache表现的很是糟糕
   -在Apache前端使用squid，这种方式工做了一段时间，可是因为负载继续增长而以失败了结。它让每秒300个请求变为20个
   -尝试使用lighttpd可是因为使用单线程它陷于困境。遇到多进程的问题，由于它们各自保持本身单独的缓存
   -如此多的图片以至一台新机器只能接管24小时
   -重启机器须要6-10小时来缓存
5，为了解决全部这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：
   -避免小文件问题，由于它将文件收集到一块儿
   -快，错误容忍
   -更低的延迟，由于它使用分布式多级缓存，该缓存与多个不一样collocation站点工做
   -更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库

1，早期
   -使用MySQL来存储元数据，如用户，tags和描述
   -使用一整个10硬盘的RAID 10来存储数据
   -依赖于信用卡因此YouTube租用硬件
   -YouTube通过一个常见的革命：单服务器，而后单master和多read slaves，而后数据库分区，而后sharding方式
   -痛苦与备份延迟。master数据库是多线程的而且运行在一个大机器上因此它能够处理许多工做，slaves是单线程的而且一般运行在小一些的服务器上而且备份是异步的，因此slaves会远远落后于master
   -更新引发缓存失效，硬盘的慢I/O致使慢备份
   -使用备份架构须要花费大量的money来得到增长的写性能
   -YouTube的一个解决方案是经过把数据分红两个集群来将传输分出优先次序：一个视频查看池和一个通常的集群
2，后期
   -数据库分区
   -分红shards，不一样的用户指定到不一样的shards
   -扩散读写
   -更好的缓存位置意味着更少的IO
   -致使硬件减小30%
   -备份延迟下降到0
   -如今能够任意提高数据库的伸缩性

数据中心策略

1，依赖于信用卡，因此最初只能使用受管主机提供商
2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议
3，YouTube改成使用colocation arrangement。如今YouTube能够自定义全部东西而且协定本身的契约
4，使用5到6个数据中心加CDN
5，视频来自任意的数据中心，不是最近的匹配或其余什么。若是一个视频足够流行则移到CDN
6，依赖于视频带宽而不是真正的延迟。能够来自任何colo
7，图片延迟很严重，特别是当一个页面有60张图片时
8，使用BigTable将图片备份到不一样的数据中心，代码查看谁是最近的

学到的东西

1，Stall for time。创造性和风险性的技巧让你在短时间内解决问题而同时你会发现长期的解决方案
2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别
3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。建立本身的网络将花费太多时间和太多money
4，Keep it simple！简单容许你更快的从新架构来回应问题
5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不只仅是得到更多的写性能
6，Constant iteration on bottlenecks：
   -软件：DB，缓存
   -OS：硬盘I/O
   -硬件：内存，RAID
7，You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人。
   With a good team all things are possible。

转自：http://www.kaiyuanba.cn/html/1/131/147/7540.htm

Twitter网站架构

1、twitter网站基本状况概览
截至2011年4月，twitter的注册用户约为1.75亿，并以天天300000的新用户注册数增加，可是其真正的活跃用户远远小于这个数目，大部分注册用户都是没有关注者或没有关注别人的，这也是与facebook的6亿活跃用户不能相提并论的。
twitter每个月有180万独立访问用户数，而且75%的流量来自twitter.com之外的网站。天天经过API有30亿次请求，天天平均产生5500次tweet，37%活跃用户为手机用户，约60%的tweet来自第三方的应用。
平台：Ruby on Rails 、Erlang 、MySQL 、Mongrel 、Munin 、Nagios 、Google Analytics 、AWStats 、Memcached
下图是twitter的总体架构设计图：
 
2、twitter的平台
twitter平台大体由twitter.com、手机以及第三方应用构成，以下图所示：

其中流量主要以手机和第三方为主要来源。
Ruby on Rails：web应用程序的框架
Erlang：通用的面向并发的编程语言，开源项目地址：http://www.erlang.org/
AWStats：实时日志分析系统：开源项目地址：http://awstats.sourceforge.net/
Memcached：分布式内存缓存组建
Starling：Ruby开发的轻量级消息队列
Varnish：高性能开源HTTP加速器
Kestrel：scala编写的消息中间件，开源项目地址：http://github.com/robey/kestrel
Comet Server：Comet是一种ajax长链接技术，利用Comet能够实现服务器主动向web浏览器推送数据，从而避免客户端的轮询带来的性能损失。
libmemcached：一个memcached客户端
使用mysql数据库服务器
Mongrel：Ruby的http服务器，专门应用于rails，开源项目地址：http://rubyforge.org/projects/mongrel/
Munin：服务端监控程序，项目地址：http://munin-monitoring.org/
Nagios：网络监控系统，项目地址：http://www.nagios.org/
3、缓存
讲着讲着就又说到缓存了，确实，缓存在大型web项目中起到了举足轻重的做用，毕竟数据越靠近CPU存取速度越快。下图是twitter的缓存架构图：

大量使用memcached做缓存
例如，若是得到一个count很是慢，你能够将count在1毫秒内扔入memcached
获取朋友的状态是很复杂的，这有安全等其余问题，因此朋友的状态更新后扔在缓存里而不是作一个查询。不会接触到数据库 
ActiveRecord对象很大因此没有被缓存。Twitter将critical的属性存储在一个哈希里而且当访问时迟加载 
90%的请求为API请求。因此在前端不作任何page和fragment缓存。页面很是时间敏感因此效率不高，但Twitter缓存了API请求
在memcached缓存策略中，又有所改进，以下所述：
一、建立一个直写式向量缓存Vector Cache，包含了一个tweet ID的数组，tweet ID是序列化的64位整数，命中率是99%
二、加入一个直写式行缓存Row Cache，它包含了数据库记录：用户和tweets。这一缓存有着95%的命中率。
三、引入了一个直读式的碎片缓存Fragmeng Cache，它包含了经过API客户端访问到的sweets序列化版本，这些sweets能够被打包成json、xml或者Atom格式，一样也有着95%的命中率。
四、为页面缓存建立一个单独的缓存池Page Cache。该页面缓存池使用了一个分代的键模式，而不是直接的实效。
4、消息队列
大量使用消息。生产者生产消息并放入队列，而后分发给消费者。Twitter主要的功能是做为不一样形式(SMS，Web，IM等等)之间的消息桥
使用DRb，这意味着分布式Ruby。有一个库容许你经过TCP/IP从远程Ruby对象发送和接收消息，可是它有点脆弱 
移到Rinda，它是使用tuplespace模型的一个分享队列，可是队列是持久的，当失败时消息会丢失 
尝试了Erlang 
移到Starling，用Ruby写的一个分布式队列 
分布式队列经过将它们写入硬盘用来挽救系统崩溃。其余大型网站也使用这种简单的方式
5、总结
一、数据库必定要进行合理索引
二、要尽量快的认知你的系统，这就要你能灵活地运用各类工具了
三、缓存，缓存，仍是缓存，缓存一切能够缓存的，让你的应用飞起来。

 

JustinTV网站架构

Justin.TV每个月有3000万个独立访问量，在游戏视频上传领域战胜了YouTube ，他们天天每分钟新增30个小时的视频，而YouTube只有23。

下面从Justin.TV的实时视频系统使用到的平台，他们的架构细节，从他们身上应该学到的东西等几个方面逐一展开。

使用到的平台

• Twice —— 代理服务系统，主要用缓冲优化应用服务器负载
• XFS —— 文件系统
• HAProxy —— 用于TCP/HTTP负载平衡
• LVS stack and Idirectord —— 高可靠性
• Ruby on Rails —— 应用服务器系统
• Nginx —— web服务器系统
• PostgreSQL —— 数据库，用于用户和meta数据
• MongoDB —— 数据库，用于内部分析
• MemcachedDB —— 数据库，用于存放常常要修改的数据
• Syslog-ng —— 日志服务系统
• RabitMQ  —— job系统
• Puppet —— 建立服务
• Git —— 源代码管理
• Wowza —— Flash/H.264视频服务器和许多Java写的custome modules
• Usher —— 播放视频流的逻辑控制服务器
• S3 —— 用于存储小型镜像

Justin.TV的一些统计数据

• 有覆盖全美的4个数据中心
• 在任什么时候候都有2000多个同时流入的数据流
• 天天每分钟新增30个小时的视频
• 每个月有3000万个独立访问量（不计同一用户屡次访问）
• 每秒实时的网络流量在45G左右

实时视频结构详述

实时视频结构

1.使用了P2P和CDN

通常人认为，只须要不断提升带宽，把传来的数据都放入内存，不断的接收数据流就能够了，事实并不是如此。实时视频要求不能打断，这就意味着你不能够超负荷的使用带宽。YouTube只须要让播放器缓冲一下，就能够用8G的带宽解决10G通道的需求，但在实时视频里，你不能缓冲，若是在信道上的流量超过了它的传输能力，哪怕只是一瞬间，那么全部的正在看的用户在那一刻都会卡。若是你在它的极限能力上再加入了一点儿负载，全部人马上就会进入缓冲状态。

Justin.TV使用了点对点的结构来解决这个问题，固然他们也有更好的解决办法，CDN（内容分发网络）即是之一。当用户的流量负载超过Justin.TV的负载能力时，Justin.TV便很巧妙的将超标流量引入到一个CDN中去，Usher控制着这个处理逻辑，一旦接到了超标用户的负载请求，Usher便马上将这些新用户转发到CDN中去。

2.100%可用时间和维护的矛盾

实时视频构建的系统既要保证100%的可用时间，又要保证机器能够进行维护。与通常网站不一样，通常网站维护时出现的问题只有少数人会发现、关注，而实时视频网站不一样，用户很快就会发现维护时带来的任何问题，而且互相传播的很是快。这就使得没有什么问题能够隐瞒用户，面对如今用户的挑剔，你必须避免维护时出问题。对一个服务器维护时，你不能主动结束用户的进程，必须等待全部在这个服务器上的用户本身结束服务才能开始，而这个过程每每很是缓慢。

3.Usher与负载均衡

Justin.TV遇到的最大的麻烦是即时拥塞，当大量的用户同时看同一个栏目的时候，便会忽然产生突发网络拥塞。他们开发了一个实时的服务器和数据中心调度系统，它就是Usher。

Justin.TV的系统在突发的高峰拥塞上作了不少。他们的网络每秒能够处理大量的链入链接。用户也参与了负载均衡，这也是Justin.TV须要用户使用Justin.TV本身的播放器的缘由之一。至于TCP，因为它的典型处理速度就是百kbps级的，因此也不用对TCP协议作什么修改。

相对于他们的流量，他们的视频服务器看来来有些少，缘由是他们能够使用Usher把每一个视频服务器的性能发挥到最好，负载均衡能够确保流量从不会超过他们的负载极限。负载大部分是在内存中，所以这个系统可让网络的速度发挥到极限。服务器他们是一次从Rackable(SGI服务器的一个系列)买了一整套，他们作的仅仅是从全部预置的里面作了下挑选。

Usher是Justin.TV开发的一款定制化软件，用来管理负载平衡，用户认证和其余一些流播放的处理逻辑。Usher经过计算出每一个流须要多少台服务器提供支持，从而分配资源，保证系统处于最优状态，这是他们的系统和别家不一样之处。Usher一般会从下面几个指标计算、衡量某个流媒体所须要的服务器：

• 每一个数据中心的负载是多少
• 每一个服务器的负载是多少
• 延迟优化的角度
• 当前这个流可用的服务器列表
• 用户的国家（经过IP地址得到）
• 用户是否有可用的对等网（经过在路由数据库中查询IP地址得到）
• 请求来自于哪一个数据中心

Usher使用这些指标即可以在服务净成本上来优化，把服务放在比较空闲的服务器上，或者把服务放在离用户较近的服务器上，从而给用户带来更低的延迟和更好的表现。Usher有不少个能够选择的模式从而达到很细的控制粒度。

Justin.TV系统的每一个服务器均可以作边缘服务器，直接为用户输出视频流，同时每一个服务器也能够作源服务器，为其余服务器传递视频流。这个特性，使得视频流的负载结构成了动态的，常常改变的一个过程。

4.服务器造成了加权树

服务器之间由视频流的拷贝而产生的联系和加权树很是类似。数据流的数量常常被系统取样、统计，若是观看某个视频流的用户数量飞速上涨，系统便将其拷贝不少份到一些其余的服务器上去。这个过程反复执行，最终就造成了一个树状的结构，最终会将网络中全部的服务器都画在里面。Justin.TV的视频流从源服务器出发，被拷贝到其余服务器，或者拷贝到用户的整个过程当中，都处于内存中，没有硬盘路径的概念。

5.RTMP和HTTP

Justin.TV尽量的使用了Flash，由于它使用RTMP协议，对每一个视频流，系统都有一个独立的Session去维护它。因为使用这个协议，成本就至关高。因为ISP不支持下载流，于是没法使用多路广播和P2P技术。Justin.TV确实想过用多路广播在内部服务器之间拷贝数据流，然而因为他们的系统控制覆盖整个网络，并且内部有大量的很便宜的带宽能够使用，这样使用多路广播的技术就并无产生多少效益。同时，因为他们的优化算法是将每一个服务器上的流数都最小化，这就使得在很细的力度上作些事情会很是麻烦，甚至超过了他们能获得收益。

Justin.TV的Usher使用HTTP请求去控制某个服务器负载哪一个视频流，从而控制了服务的拓扑结构。Justin.TV在流数据上使用HTTP，但存在的一个问题是它没有延迟和实时方面的性能。有些人说实时的定义就是5-30秒，然而，面对数千人作实时视频的时候这显然不行，由于他们还须要实时的讨论，交流，这意味着延迟不能高于1/4秒。

6.从AWS到本身的数据中心

起初Justin.TV使用AWS，后来迁移到Akamai（云服务供应商），最后到了本身的数据中心。

离开AWS到Akamai的缘由有：1，成本；2，网速不能知足他们的需求。视频直播对带宽很是敏感，所以有一个快速的，可靠的，稳定的和低延迟的网络很是关键。使用AWS时，你不能控制这些，它是一个共享的网络，经常超负载，AWS的网速不会比300Mbps更快。他们对动态范围改动和云API很重视，然而在性能和成本问题上没有作什么。

3年前，Justin.TV计算他们每一个用户的成本，CDN是$0.135，AWS是0.0074，Datacenter是$0.001现在，他们的CDN成本下降了，但他们的数据中心的成本却仍然同样。

拥有多个数据中心的关键是为了可以接近全部的主要交换节点，他们选择国内最好的位置从而使得他们为国内最多的节点提供了入口，并且节约了成本，构建了这些数据中心后，他们就直接连入了这些其余的网络，从而就省去了以前处理这些中转流量的费用，还提升了性能，他们直接连入了他们所谓的"eyeball"网络，这个网络中包含了大量的cable/DSL用户，和"content"网络链接有些相似，Justin.TV的"eyeball"链接的流量主要来自终端用户，在大多数状况下，这些都是免费的，不用任何花一分钱，要作的就是连进来就行。Justin.TV有一个主干网，用于在不一样的数据中心传输视频流，由于要到一个可用节点的选拔过程是去找愿意和你作对等节点的过程，这一般是很困难的。

7.存储

视频流不是从磁盘造成，而是要存到磁盘上去。源服务器将一个传入的视频流在本地磁盘上复制一份，以后便将这个文件上传到长期存储器上，视频的每一秒都被录下来而且存档了。

存储设备和YouTube相似，就是一个磁盘库，使用XFS文件系统。这个结构用于记录经过服务器传播的广播。默认的视频流是保存7天，用户能够手动的设置，甚至你能够保存到永远（若是公司没有倒闭的话）。

8.实时转码

增长了实时的转码功能，能够将任何一种流式数据转化为传输层数据或者是代码，而且能够用新的格式将它从新编为流媒体。有一个转码集群，用来处理转换工做转，换的会话使用job系统进行管理。若是须要的转码服务超过了集群的处理能力，那全部的服务器均可以用做转码服务器。

Web结构

Web 结构

1.Justin.TV前端使用Ruby on Rails。

2.用Twice作缓存

系统个每一个页面都使用了他们本身定制的Twice缓存系统，Twice扮演的角色是轻量级反向代理服务器和模板系统的合并角色。思路是对每个用户，缓存每个页面，而后将每一个页面的更新再并入其中。使用Twice之后，每一个进程每秒能够处理150条请求，同时能够在后台处理10-20个请求，这就扩展了7-10倍以前的服务器能够处理的网页的数量。大部分动态网页访问都在5ms之内。Twice有一个插件结构，因此它能够支持应用程序的一个特色，例如添加地理信息。

不用触及应用服务器，便能自动缓存像用户名同样的数据。

Twice是一个为Justin.TV的需求和环境而定制化开发的。若是开发一个新的Rails应用，使用Varnish或许是一个更好的主意。

3.网络流量由一个数据中心服务，其余的数据中心为视频服务。

4.Justin.TV 对全部的操做都作了监控.每个点击，查看页面和每个动做都被记录下来，这样就能够不断提升服务。前端，网络呼叫或者一个应用服务器的日志消息都被转换成系统日志消息，经过syslog-ngto转发。他们扫描全部的数据，将它装入MongoDB，使用Mongo执行查询。

5.Justin.TV的API来自网站的应用服务器，它使用相同缓冲引擎，经过扩展网站来扩展他们的API。

6.PostegreSQL是他们最主要的数据库。结构是简单的主从结构，由一个主机和多个从属读数据库组成。

因为他们网站的类型，他们不须要许多写数据库，缓冲系统控制着这些读数据库。他们发现PostgreSQL并不擅长处理写操做，所以Justin.TV就是用MemcachedDB去处理那些常常要写的数据，例如计数器。

7.他们有一个聊天服务器集群，专门用来为聊天功能服务。若是用户进入了一个频道，用户就会有5个不一样的聊天服务器为他服务，扩展聊天功能要比扩展视频功能简单的多，用户能够被划分到不一样的房间，这些房间又由不一样的服务器负载。他们也不会让100,000我的同时在一块儿聊天。他们限制每一个房间200人，这样就能够在一个小组里进行更有意义的交谈。这同时对扩展也颇有帮助，这真的是一个很聪明的策略。

8.AWS用于存储文档镜像。他们没有为存储许多小镜像而开发专门的系统，他们使用了S3。它很是方便，并且很便宜，这就不用在他们上面花更多的时间了。他们的镜像使用频率很高，全部他们是可缓冲的，也没有留下什么后续问题。

网络拓扑结构设计

网络拓扑结构很是简单，每一个服务器机架顶都有一对1G的卡，每一个机架都有多个10G的接口，接口链接到外部的核心路由器。他们使用Dell Power Edge交换机，这些交换机对L3（TCP/IP）并非彻底支持，可是比L2（ethernet）要好的多。每一个交换机天天要传输20G的数据，并且很便宜。核心路由器是思科的6500的系列。Justin.TV想要将节点最小化，从而让延迟下降，而且下降每一个packet的处理时间。Usher管理着全部的接入控制和其余的逻辑，而不只仅限于网络硬件。

使用多个数据中心能够充分利用对等网的优点，把流量转移到离用户最近的地方。和其余的网络和节点的链接很是多。这样就有多个可选的传输途径，因此能够使用最好的那个路径。若是他们遇到了网络的拥塞，就能够选择一条别的路。他们能够经过IP地址和时间，找到对应的ISP。

开发和部署

他们使用Puppet服务器主机，有20中不一样种类的服务器。从数据库中出来的任何东西都要通过缓存器，使用Puppet他们能够把这个缓存器变成他们想要的任何东西。

他们有两个软件队伍。一个是产品队伍，另外一个是硬件基础设施队伍。他们的队伍很是小，大概每一个队伍只有7-8我的，每一个队伍都有一个产品经理。他们雇佣通常的技术员，但却雇佣了网络结构和数据库相关的专家。

他们使用了基于网络的开发系统，因此每一个新的改动都会在几分钟内完成。QA必须在变成产品以前完成，在这里一般须要5-10分钟。

Justin.TV使用Git管理源代码。Justin.TV喜欢Git的这个功能，你能够写一个程序副本，20-30行，而后它能够融合到其余人手里正在修改的副本。这个工做是独立的，模块化的。在你不得不撤销你提交的副本时，你能够很容易就修改或者撤销你的代码。每过几天每一个人都会试着将本身的代码副本融入到主代码中去消除冲突。他们天天对软件作5-15个修改，范围从1行代码中的bug到大范围的测试都有。

数据库模式经过手动更新完成。将他们复制的数据库副本迁移到一块儿就会造成一个最新的动态记录的版本。在把改动最终应用到产品以前会在许多不一样的环境下对其进行测试。

Puppet管理配置文件。每一个小的改动基本上就是一个实验，他们会追踪每一个对核心文件的改动的影响和以前的版本。这些测试很重要，由于经过它他们能够找出哪些改动是真正提升他们关心的指标。

Justin.TV的将来

他们的目标是增长一个数量级。首先要切分他们的视频元数据系统，因为流数据和服务器的大幅增加，他们的元数据负载也指数级的爆发增加，所以，他们须要将其大范围进行切分，对于网络数据库，将使用Cassandra对其进行拆分。其次，为了灾后恢复，要对核心数据中心进行备份。

学到的东西

• 本身开发仍是购买。他们在这个问题上已经作了不少错误的决策。例如，他们起初应该买一台视频服务器而不是本身去作了一台。软件工程师喜欢将软件作的个性化，而后使用开源社区维护的东西却有不少益处。所以他们提出了一个更好的流程去作这个决定：1.这个项目是活动？仍是维护？仍是修补漏洞？2.有其余的人要用它么？你能向别人请教下该如何定义它？3.扩展性的问题，他们必须去作改变。4.若是咱们本身开发，咱们能够作到更快，更好，仍是咱们能够得到更多咱们须要的特性呢？ 就像使用Usher，他们考虑他们能否创造一个新的外部特性，而且和另一个系统交互。把Usher作为视频扩展性的核心针对相对笨拙的视频服务器来讲是一个很是好的决策的例子。
• 关注本身作的事情，不要在乎别人怎么干。他们的目标是有用最好的系统，最多的服务时间和最完美的扩展性。他们用了3年去开发能管理百万个广播并发的技术。
• 不要外包。你学到的核心价值在于经验，而不是代码或者硬件。
• 把一切都当作实验来作。对全部的东西都进行测量，局部测试，追踪，测量。这很划算。从一开始就作，使用优秀的测量工具。例如，他们在复制的URL上附加一个标签，而后就能够知道你是否分享了这个连接。他们从不测量的走到了现在高度测量。经过重写广播进程，使得他们的会话数量增加了700%。他们想要网站运行更快，响应更快，网页装载更快，视频服务更好，系统挤出的每一毫秒的延迟都带来了更多的广播者。他们有40个实验，若是他们但愿让一个用户变成一个广播者，对每一个实验他们都想要看一下广播后的留存率，广播的可用性，会话率，而后对每一个改动都作一个明智的决策。
• 最重要的一件事是理解你的网站如何共享服务，怎么优化它。他们经过减小共享的连接在菜单中的深度，成功的提升了500%的分享率。
• 使用公共的构建模块和基础设施意味着系统将马上识别什么是重要的，而后执行。具备网络能力很重要，这也是他们应该从开始就关注的地方。
• 让系统忙起来。使用系统的全部能力，为何要把钱放在桌子上呢？构建能够经过应答对系统进行合理的分配的系统。
• 对不重要的事情不要浪费时间。若是它很是方便而且不用花费多少，就没有必要在它上面花费时间。使用S3去存储镜像就是一个很典型的例子。
• 试着为用户想作的事情提供支持，而不是作你认为用户该这样使用的东西。Justin.TV的终极目标彷佛是把全部人都变成一个广播点。在用户实验时，经过尽量的走出用户的使用方式，他们试着让这个过程变得尽量简单。在这过程当中，他们发现，游戏是一个巨大的做用力。用户喜欢将Xbox截图出来，而且与你们分享，讨论它，颇有可能有些东西是你没想过要放在商务计划里的。
• 为负载峰值作设计。若是你只为了静态的状态作了设计，以后你的网站将会在峰值来临时垮掉。在实时视频上，这一般是一个大事，若是你陷入了这个麻烦，很快人们就开始传播对你不利的话。为峰值负载进行设计须要使用一个全部层次的技术。
• 让网络结构保持简单。使用多数据中心，使用点对点网络链接结构。
• 不要担忧将东西划分到更多的可扩展块中去。例如，与其使用一个100,000人的频道，不如将他们划分到更多的社会和可扩展的频道去。
• 实时系统不能隐藏来自用户的任何问题，这就是的说服用户你的网站很可靠变的很困难。因为他们和实时系统之间的联系是固定的，这会使的系统的每一个问题和故障都让你们知道，你藏不住。每一个人都会发现，而且每一个人都会经过交流传播发生了什么，很快，用户就会有一个你的网站有不少问题的感受。在这种状况下，和你的用户交流就变得很重要，从一开始就构建一个可信赖的，高质量的，可扩展的，高性能的系统，设计一个用户用起来尽量简单和舒服的系统。