公告：youtube买赞平台 --youtube流量
在旧金山可扩展性的控制技术讨论会上，YouTube 的 Cuong Do 做了有关YouTube Scalability的调查报告。音频文本在 Google Video 上有(门牌号)，可是亚洲地区使用者看不出。
单纯地说 YouTube 的统计数据网络流量, "六天的YouTube网络流量相等于推送750亿邮件.", 2006 年中就有最新消息说每星期 PV 少于 1 亿,那时? 更生硬了,"每晚有10万次浏览和6,5000次上载", 真伪Licharre无论, 确实是非同寻常的海量统计数据. 亚洲地区的网络应用领域,但从信息量上看,怕是多于 51.com 有那个体量. 但控制技术上和 YouTube 就不乐意比了.
Web 伺服器
YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 伺服器有部分是 Apache， 用 FastCGI 模式。对于音频文本则用Lighttpd。据我所知，MySpace 也有部分伺服器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(亚洲地区用 Lighttpd 站点不多，豆瓣用得比较舒服。)
音频
音频的缩略图(Thumbnails)给伺服器带来了很大的挑战。每个音频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为那个带来的磁盘 IO 请求太大。YouTube 控制技术人员启用了单独的伺服器群组来承担那个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable，这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。
出于冗余的考虑，每个音频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同文本的伺服器。最火的音频放在 CDN 上，这样自己的伺服器只需要承担一些"漏网"的随机访问即可。YouTube 使用单纯、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。
统计数据库
YouTube 用 MySQL 存储元统计数据--使用者信息、音频信息什么的。统计数据库伺服器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。
最初的 DB 多于 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的多于Bebo,参见这里). 在可扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",那个不是统计数据库层面的表分区，而是业务层面的分区(在使用者名字或者 ID 上做文章,应用领域程序控制查找机制)
