2008年1月的归档

　　昨天在QQ上遇见三弟。
　　三弟询问何日归，我叹机票，火车票皆不可求。
　　三弟告之：三十载不遇，家乡雪，路面冰，高速封，吾虽思君，但劝君留京，待春暧花开再返乡。
      吾思乡之心如江之涌起... ....　至今时不能平。
      念老父老母安好，叩拜。

大概两个月前就在网上down下了这部书，并一口气读完。正值blog迁移，故现在才浓重推荐。此书是对于web前端的性能优化不可多得的一部好书，其可实践性极强，作者是原Yahoo!的首席性能官(Chief Performance Officer):Steve Souders，现已经跳至google。
　　在Yahoo，有一支性能小组，叫：Yahoo!'s Exceptional Performance team，翻译成中文就是是特别性能小组，他们主要是致力于以最佳的实践来提高Web性能。好像前段时间他们来过中国参加了CSDN的开发者大会，可惜俺未能参加，要是早知这一出演讲讨论，肯定要前往倾听了。Steve Souders就是这支小组的team leader。
　　书中，Steve Souders提出了一个performance golden rule，与其说是黄金法则，到不如说这是一个目前各网站所常见的一个表象：80-90 ％的用户等待时间是来自于前端的网页加载。
      而《High Performance Web Sites》就是介绍如何去减少这80~90%的等待时间的一部优化手册。此书即适合前台开发者(html,js,css)，也适合后台开发者。此书在yahoo的开发者网站有Html版本，具体可查阅http://developer.yahoo.com/performance/rules.html 。
　　如果您对后台的构架或性能更感兴趣，那在我前面介绍Flickr构架时，所提到的《Building Scalable Web Sites》就更值得一看了。

相关资料：
http://www.bytebot.net/blog/archives/2007/04/25/federation-at-flickr-a-tour-of-the-flickr-architecture
http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/slides/public/IanFlint_YahooCommunitiesArchitecture.pdf
http://gocom.primeton.com/modules/newbb/item43643_43643.htm
还推荐一本fickr的资深构架师 Cal Henderson 的大作《Building Scalable Web Sites》

    　截止到2007年11月13日，Flickr 用户上传的图片已经达到20亿，Flickr必须每天处理海量更新的图片，还有不断增加的用户，竟然还能不断发布新的功能，同时也保持着良好的应用性能。从Cal Henderson 的书中，我能感觉Flickr的成功是与他们坚实的技术和构架密不可分的。

平台
      ok，先来看看他们的平台：
　　 PHP
          MySQL
          Shards (这是个新名词，还是叫"碎片"吧，"指的是将应用的数据横向拆分，也就是说如果有几千万的用户信息，那么这些用户信息可以被分布在多个数据库服务器上")
          用Memcached做缓存layer
          对Html和图片用squid反向代理
          RedHat Linux
          Java，Perl，用Pear处理xml和email
          Apache
          ImageMagick ，SystemImager ，Ganglia(分布式监控程序)，Subcon(用于管理和发布集群机器的配置文件)，Cvsup(用于在网络中分发和更新文件)

数据库     

       中心数据库中存储像user这样的表，但只存储它们里的主键id和具体应该指向哪个分布数据库的指向信息。每个Shard存储40W的用户数据，大多数数据会存储两次，比如，一个评论的发表，它是介于被评论对象和发起评论对象之间的数据，这种数据，flickr会存储两次，通过事务来同步执行：打开第一个事务(transaction)，写数据，打开第二个事务，写数据;如果两个事务都正常执行了，则第一个事务提交(commit)，如果第一个事务提交成功，则第二个事务提交。这个流程，如果遇到服务器down机，其实还是有可能出现只提交了一次的情况。
     
       Flickr的搜索功能有两个结果返回来源，一个是Flickr自身的Shards机器，另一个是Yahoo的web搜索，用户自己的tag搜索走的是Flickr自己的Shards方式，其它的就是走的Yahoo的web搜索了，这个改进肯定是在被Yahoo收购之后的事了。

      看资料，Flickr的服务器确实够强：EMT64 w/RHEL4, 16G的内存，（我目前正在维护的项目其配置最好的机器内存也才8G），6块15K RPM硬盘组成的RAID-10盘阵（羡慕...）。用户数据目前有12TB，当然这不包括图片，图片内容比这点数据要多的去了。都是2U的机器，每个数据库shard存有120G的数据，也就是说Flickr有10台数据库shard机器。



  数据备份

      Flickr这种提供图片服务的web2.0网站，数据尤其重要，所以他的备份工作显的格外重要：
      采用定时任务，从各个数据库shard机器中非并行的备数据（也就是避免同时开始备份任务），当然也有热备份。每天晚上会扫描数据库集群生成快照(Snapshots)，Flickr给出的经验中告诫，备份数据时，不要在删除（写入）大文件的时候立即进行写（删除）操作，这会损害性能。
     
       图片是以文件的形式存储。一旦文件上传，应用服务会生成几种不同的size文件，完成之后，这些图片信息和图片的指向信息就被存进数据库。汇集数据也相当快，因为是在各自的shard上并行执行，10台shard并行响应速度可想而知。每个shard的最大连接数的是400个每秒，或者是设置成每个服务器+其相应的shard共 800个连接。最大45线程，因为目前还不会出现有超过45个用户同时并发的情况。


Tag标签

      Tag是web2.0的特征，但tag不适合用传统的关系数据库来描述，Denormalization（反向规格化）和缓存是解决生成大量tag以控制在毫秒级的唯一方法 （Cal Henderson 的结论），为了实现毫秒级的大量tag生成，flickr的数据增加了一倍；还要写额外的程序去产生这些资料，而且还有额外的程序来保证数据间的一致性。可见高性能是和离复杂度分不开的。
 
     他们的一些数据视图是后台离线计算的，把结果存储到MySQL中。因为其中有一些关系很复杂的运算，他们采取了利用服务器空闲的cpu来执行这些耗资源的程序。这可又是一复杂的处理。
 
      另外，Flickr还实现了业务连贯性计划(Business Continuity Planning)，以保证业务的不间断，让所有的数据都及时能写到数据层（db,memcache等），不会有服务挂起的情况。这个涉及到具体的业务流程了，但应该也属于构架很重要的一部分，但关于这方面的资料Flickr透露的还太少，可以因为这个太涉及业务流程了吧。

总结
      我在这里只是总结了Flickr构架的整体概念，他们本身的发展历程就是一个很好的学习素材。我相信任何一个做web2.0的有志人士，都不会是想只停留在一个原始的无序阶段，无论您的模式怎样，最终都得有一个好的构架来支撑。好的构架就好比肥沃的土壤，业内各种乱飞的模式也只是一个个的种子而以。我曾听一个朋友提到过当年联众怎么没有独霸国内的在线小游戏市场的事，我想和他当年土壤很有关系吧。

　　要开年会了，终于可以去泡温泉了，有大半年没泡过了，心中真是期待呀。
　　将来一定要去新疆，头顶上下着雪，然后泡在天然温泉里，打个小盹，这个愿望一定要实现。在没实现这个愿望之前，还是去泡泡室内的人造泉吧。
　　嗯，这次年会的部门小品，俺在幕后贡献力量了，负责道具统筹，兄弟们，搬桌子了。

     YouTube增长的十分迅猛，它成立于2005年2月，一年后的2006年3月，每天已经有3000万的视频服务请求，到了2006年7月，已经达到每天近1亿的视频访问，但负责整个网站维护的人数却并没有我们想象中的那么多。比较可信的说法是：2个系统管理员，2个软件构架工程师，2个开发工程师，2个网络工程师，1个DBA。
    
　目前YouTube所使用的平台:
　　Apache
      Python
      Linux(Suse)
      MySQL
      psyco，一个动态的 python->C 编译器,用于为python提速
      lighttpd，用于视频内容
 　　
      YouTube使用NetScaler 进行负载均衡和缓存静态内容，Apache 使用 mod_fast_cgi，请求是由一个Python应用服务器来单独处理. 应用服务器请求多个数据库和其它的资源来获取数据，再把数据组装成一个Html页面。其构造极具可扩展：可以通过增加机器来扩充大规模需要的Web层。

       系统中Python不构成瓶颈，大部分的时间是花费在远程调用上 (RPC)，并且Python 适合快速灵活的开发和部署，这一点于市场竞争很关健。通常每个页面的服务时间小于 100 ms 。它还使用 psyco, 一个动态的 python->C 编译器 ，使用JIT编译器的方法，以优化内部循环。 在对CPU占用率比较高的应用，如加密应用，他们使用C来进行处理。为一些处理代价比较高的请求预先生成并缓存HTML。 在数据库中实现Row级别的缓存。缓存Python对象等。

YouTube的视频存储：

　   每个视频都存储在一个小型集群中，所以每个视频都至少存储在一个以上的机器上，更多的磁盘来存储内容意味着更快的速度。如果一台机器down掉，其它的机器可以补上，还可以做到联机备份.
       因为Apache会有多的开销，所有服务器使用lighttpd做为视频文件的web server，使用 epoll 处理 fds. 
       比较受欢迎的视频会移到CDN上，点击量很少的内容(一天1-20个 views的那种)会存储在相应标识的服务器上.


YouTube的缩略图处理

      对每个视频都有四张缩略图与之对应，这些缩略图都是专门由单独的服务器来提供web访问，这里就会遇到存储大量小文件所遇到的问题，文件系统也像是一个数据库，对于大文件到无所谓，但对于大量的零碎小文件，磁盘的I/O可受不了，何况每个目录所能存储的文件数也有一个极限，为此YouTube使用了Linux里的页面缓存和索引节点缓存，为了突破目录的存储文件数限制，在Ext3下，将文件转移到了多层次的目录结构上，目前在2.6内核下可以将Ext3的大目录处理能力提高100倍。但是，将大量文件存储在一个文件系统下仍然不是一个太好的方法。

　　一个页面显示60个缩略图，在每秒高请求的情况下，这样的高负荷Apache不太适合：在前端的Apache使用反向代理squid，刚开始还算凑合，但随着负荷的增加性能下降的很明显，从能处理每秒300个请求下滑到每秒20个。于是YouTube尝试用lighttpd，但lighttpd的单线程性能实在说不过去，又通过安装多线程的mod来让lighttpd支持高并发，但每个线程又有各位独立的缓存，就这导致安装一个存储大量图片的机器要消耗24小时，重启一次也要消耗6~10个小时以填充缓存。

　　为了解决这个问题，他们使用了Google的BigTable，一个分布的数据存储：避免了小文件存储的问题，速度够快，容错也不错，还有较低的延迟，因为它使用了一个分布式多级高速缓存，并能跨越不同的站点。

     
YouTube数据库

       早年：
       使用MySQL存储元数据，像用户信息，tags和视频描述。
       用一个包含10块硬盘的RAID 10 Volume盘阵存储数据，由于当时经济拮据，不得不租用硬件和使用信用卡购买硬件。他们也经历了从单一服务器到一个主服务器和多个副服务器的转变经历，然后数据库分区，再解决共享问题。这时遇到的问题是：主服务器是多线程大机器，它可以处理大量的任务，但副服务器是配置不太好的机器（我怀疑可能就是普通PC）只是用来单线程的工作，所以导致副服务器的响应严重滞后，因为缓慢的I/O导致了更新数据时的缓存丢失。使用replicating architecture复制构架，也只是用大量的money换来一点点的写入性能。他们的一个解决办法就是考虑数据的优先级，把数据分成两大类：一个是视频数据池，一个是通用数据群，这样的好处是让观看视频的应用得到更多的资源，而社会网络化这样的相对不太重要的功能能被路由到小容量的集群中。

　　现在：
　　实现了数据分区。分布式的读写，更好的本地缓存策略以减少IO，并减少了30%的硬件，避免了各服务器间的滞后，并且能方便的扩展数据库。

      ok，从YouTube的发展和他的构架中我们可以看到，在最初的开始就应该为将来长远的发展考虑，从应用的特点和服务重点方面去考虑整个构架和性能的扩展成本。并不断的找出系统中的瓶颈，每一次瓶颈的解决，对于用户的体验就是一次增强，对于瓶颈，要有可控的预见和分析：软件，缓存，操作系统，磁盘I/O，数据库，带宽... ...
      YouTube成功的另一个要素，是他有一支学科交叉的团队，我在前面提到过他们的人员构成，各有专攻，一个良好的团队，有什么事是不可能的！：Impossible is nothing.　

该文的作者曾有在硅谷工作或学习的经历，对硅谷成长起来的大公司是了知于心，虽然比不上市面上专业介绍这些公司的书籍，但基本上都写到了关键点上，推荐朋友们一读，希望还能介绍SUN,Oracle,EMC,Sysbase这些公司的文章：）

第六章----互联网的金门大桥（思科）（四） 第六章----互联网的金门大桥（思科）（三） 第六章----互联网的金门大桥（思科）（二） 第六章----互联网的金门大桥（思科）（一） 第五章----奔腾的芯（英特尔--Intel）（五） 第五章----奔腾的芯（英特尔--Intel）（四） 第五章----奔腾的芯（英特尔--Intel）（三） 第五章----奔腾的芯（英特尔--Intel）（二） 第五章----奔腾的芯（英特尔--Intel）（一） 第四章----计算机工业的生态链（三） 第四章----计算机工业的生态链（二） 第四章----计算机工业的生态链（一） 第三章----"水果"公司的复兴 （乔布斯和苹果公司）（四） 第三章----"水果"公司的复兴 （乔布斯和苹果公司）（三） 第三章----"水果"公司的复兴 （乔布斯和苹果公司）（二） 第三章----"水果"公司的复兴 （乔布斯和苹果公司）（一） 第二章----蓝色巨人（IBM）（六） 第二章----蓝色巨人（IBM）（五） 第二章----蓝色巨人（IBM）（四） 第二章----蓝色巨人（IBM）（三） 第二章----蓝色巨人（IBM）（二） 第二章----蓝色巨人（IBM）（一） 第一章----帝国的余辉（AT&T)（四） 第一章----帝国的余辉（AT&T)（三） 第一章----帝国的余辉（AT&T)（二） 第一章----帝国的余辉（AT&T)（一）

2005 - "the power of books" is part of the artwork collection of the University of Applied Arts / Vienna

    不说那些与朋友聚会的，只说单身一个人饮茶的，你想想看 这大中午时间，他们为什么独自在茶馆里，我的感觉是以最小的经济代价换取最大的生存空间，你想啊 一杯茶仅十几块钱欢乐的是一个人的安静，茶馆呢！又不像饭馆一样地吵闹，付出的消费也少，却可以得到最大限度的耳根清静，因此从经济学的角度看，这就是以最小的投入得到最大的产出。问：奇怪，既然要休息吧，为什么不待在家里要跑到茶馆里面来花钱买安静？答：这里有个性能价格比的问题，家里不花钱那么就不存在交易的质量保证，不花钱得到的东西性能就差劲，就好比你在街上，别人送给你一副耳机你无法使用，人家没有给你进行质量的承诺。你又不付出什么 自然不能抱怨。在家里就是这个样子。如果孩子哭了 你不能不让他哭，老婆骂你 你不能回嘴，爹妈要你干活儿 你不能午睡。总之 在家里 你不是一个独立的个体也不是一个主体，你只是一个附庸。在外面就不一样了，虽然你只付出了十几块钱的代价，但你得到的是超值的服务和精神上的绝对的领导地位。所以从这点上论证，茶馆要比家里休息好。