刚毕业那会儿，来青岛挺勤快的。之后俺家 Laura 从青岛辞职后，我就一趟没来过。这次借着开会的机会算是故地重游。地面 30 摄氏度，海风吹来，凉快极了。相比之下，杭州好像一个大蒸笼，就这个热，据说在全国的”火炉”评比中还排不上号呢。
下午跟着大家一起去石老人海滨浴场，这个石老人浴场其实离真正的石老人还有好远呢。沙滩还算凑合。中国北方海岸线上的沙滩估计都这样。天气不热，人可真多。没带泳裤，买条便宜一点的，20，要更衣的吧? 5块，游泳后总要冲一下的水吧? 冲水? 10块。浴场不收门票，倒也便宜你不到什么地方去。这样做生意倒也很有意思
晚上去什么啤酒街吃饭，我有痛风，平时不能喝啤酒，不能吃海鲜，今天稍微破点例。其他几个朋友都是南方人，胃口大开。回来的路上出租车司机问:
“吃的好?”
“还不错”
“那我就不说啥了”
“啊? 这里不好嘛?”
“都是政府的炒作，东西太贵，坑你们游客呢，我们吃都去老城区那边”
晕！
–EOF–
今天总算看到 FeedBurner 显示的订阅数字超过 5000 个了。算是我这个 Blog 的一个里程碑吧，自我虚荣一下。虽然这个数字里面有很大的重复订阅量。通过这个 Blog 分享了一些信息，也认识了不少朋友，这是让人快乐的事情。
很早以前我写过一篇 《Blog 写给谁》 很清楚的说明了自己写 Blog 的角度。既然这样，我写的东西肯定带有很大的个人倾向，我自己的立场。写这个东西没有谁给我发工资，还要自己掏钱买空间，域名续费什么的，容易么? 我不能保证所有文章都是墙头草，谁都不得罪，我也不能保证总写技术，也不能保证总写一些技术概述(这类东西读者多，被抄袭的也多)，我喜欢写影评，那就写点，觉得没价值简单看个标题就过去好了，没必要看完了觉得不爽，非要表达一下自己的情绪，要知道我这个破 Blog 速度是出奇的慢。
最近有几篇还出现了一点不那么和谐的声音。也有人留言告诉我”应该”怎么做，怎么写。有语言洁癖的同学其实大可不看，风花雪月的你可以去看郭敬明，去看老徐，来这里浪费时间干嘛? 从小到大都被当作棋子儿，走别人划的印走惯了? 身体刚不那么柔软了，就开始想给别人划印了?
有些人可能看到我总结的玩意儿后觉得有点参考价值，就转载了一下。有的人注意到我每篇文章前面的声明，保留了版权信息和出处，在当前的网络文化下，我只能表示”欣赏”。而有些人给改头换面之后再来个 “CTRL+C / CTRL+V”, 这是我最厌恶的方式。如果你觉得内容真的有用的话，直接收藏地址不就成了嘛? 不知道 del.icio.us 还不知道雅虎收藏+、百度搜藏么? 还不知道的话，你 IE 上不是还有个收藏夹么? 非把内容弄到你那一亩三分地干嘛? 再说了，如果是技术信息，我以后还有更新怎么办? 你在那里不是误导别人么? 对于不遵守我的版权声明的转载一律视为抄袭者。这样的人我这个 Blog 不欢迎!
MT4 正式发布之后将重新设计一下模版。目前的模版拼拼凑凑的，问题不少，留言问题其实也和模版相互关联有关。尝试彻底解决一下。目前的空间还存在不少安全问题，真没准儿哪天直接给人一窝端了。如果真是这样，我还省心了。:)
–EOF–
在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。
Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)
简单的说 YouTube 的数据流量, “一天的YouTube流量相当于发送750亿封电子邮件.”, 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,”每天有10亿次下载以及6,5000次上传”, 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.
YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)
视频的缩略图(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 上做文章,应用程序控制查找机制)
YouTube 也用 Memcached.
很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?
–EOF–
请移步观赏.
–EOF–