于敦德 2006-6-27 FeedBurner（以下简称FB，呵呵）我想应该是大家耳熟能详的一个名字，在国内我们有一个同样的服务商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600个源，到2005年4月份，流量已经增长到5Mbps，托管了47700个源；到2005年9月份流量增长到20M，托管了109200个源，而到2006年4月份，流量已经到了115Mbps，270000个源，每天点击量一亿次。 FB的服务使用Java实现，使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题，以及解决的方案。 在2004年8月份，FB的硬件设备包括3台Web服务器，3台应用服务器和两台数据库服务器，使用DNS轮循分布服务负载，将前端请求分布到三台Web服务器上。说实话，如果不考虑稳定性，给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题，单点问题将至少影响到1/3的用户。FB采用了监控的办法来解决，当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)来做监控。 FB碰到的第二个问题是访问统计和管理。可以想象，每当我们在RSS阅读器里点击FB发布的内容，都需要做实时的统计，这个工作量是多么的巨大。大量写操作将导致系统的效率急剧下降，如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制，通过创建执行池来缓冲写操作；只对本日的数据进行实时统计，而以前的数据以统计结果形式存储，进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢，这个时候应该是FB在分析整理前一天的数据，而接下来的访问由于只针对当日数据进行分析，数据量小很多，当然也会快很多。FB的Presentation是这样写，但我发现好像我的FB里并没有今天实时的统计，也许是我观察的不够仔细-_-! 现在第三个问题出现了，由于大多数的操作都集中在主数据库上，数据库服务器的读写出现了冲突，前面提到过Myiasm类型的数据库在写入的时候会锁表，这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显，但现在已经到了不能忽视的程度。解决方案是平衡读写的负载，以及扩展HibernateDaoSupport，区分只读与读写操作，以实现针对读写操作的不同处理。 现在是第四个问题：数据库全面负载过高。由于使用数据库做为缓存，同时数据库被所有的应用服务器共享，速度越来越慢，而这时数据库大小也到了Myisam的上限-4GB，FB的同学们自己都觉得自己有点懒。解决方案是使用内存做缓存，而非数据库，他们同样使用了我们前面推荐的memcached，同时他们还使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式缓存工具。 第五个问题：流行rss源带来大量重复请求，导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源，这同样需要服务器去处理，而目前所有的订阅数都在同一时间进行计算，导致对系统资源的大量占用。解决方案，把计算时间错开，同时在晚间处理堆积下来的请求，但这仍然不够。 问题六：状态统计写入数据库又一次出问题了。越来越多的辅助数据（包括广告统计，文章点击统计，订阅统计）需要写入数据库，导致太多的写操作。解决方案：每天晚上处理完堆积下来的请求后对子表进行截断操作： – FLUSH TABLES; TRUNCATE TABLE ad_stats0; 这样的操作对Master数据库是成功的，但对Slave会失败，正确的截断子表方法是： – ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2); – TRUNCATE TABLE ad_stats0; – ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2); 解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去，单独做集群，例如广告啊，订阅计算啊， 第七个问题，问题还真多，主数据库服务器的单点问题。虽然采用了Master-Slave模式，但主数据库Master和Slave都只有一台，当Master出问题的时候需要太长的时间进行Myisam的修复，而Slave又无法很快的切换成为Master。FB试了好多办法，最终的解决方案好像也不是非常完美。从他们的实验过程来看，并没有试验Master-Master的结构，我想Live Journal的Master-Master方案对他们来说应该有用，当然要实现Master-Master需要改应用，还有有些麻烦的。 第八个问题，停电!芝加哥地区的供电状况看来不是很好，不过不管好不好，做好备份是最重要的，大家各显神通吧。 这个Presentation好像比较偏重数据库，当然了，谁让这是在Mysql Con上的发言，不过总给人一种不过瘾的感觉。另外一个感觉，FB的NO们一直在救火，没有做系统的分析和设计。 最后FB的运维总监Joe Kottke给了四点建议： 1、 监控网站数据库负载。 2、 “explain”所有的SQL语句。 3、 缓存所有能缓存的东西。 4、 归档好代码。 最后，FB用到的软件都不是最新的，够用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。 文章参考了Joe Kottke在MySQL Users

最近视频的东西比较火，前些天我也稍微了解了一下使用开源软件建在线Flash流媒体播放平台的解决方案，还是有一些收获。 Red5是一款基于java的开源的Flash流媒体Server软件，可以作为取代Macromedia提供的商业版本FMS。Red5使用RSTP作为流媒体传输协议，内置了一些示例，这些示例实现了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本的功能。由于系统本身是开源的，在碰到问题的时候也比较容易解决，大不了直接改代码，在成本方面也可以省下一笔不小的开销，为未来的功能扩展也提供了充分的空间。 如果仅仅是实现在线录制，在线播放，那么Red5也就差不多够了，但可能我们有时候还需要用户上传自己拍摄的视频文件，而要把这些视频文件转成可播放的flv文件就需要视频编码软件了。FFMpeg提供了录制，播放，视频流处理的完整解决方案。它自身也带了一个基于HTTP的流媒体广播程序以及其它几个实用的程序，但我们的重点还是它的视频转换程序，似乎Google Video也是用的它的程序作为视频转换工具。 我用FFMpeg转了几个视频，效果还可以，在声音上碰到了一些问题，在不添加参数的情况下，有一部分视频的声音会有问题，有的视频无论怎么添加参数，都出不来声音，报错提示的是不支持所带的声音采样格式，只支持几种固定的格式，我看了一下代码，确实是这样子，但理论上应该是能够解决的。FFMpeg自带的libavcodec是一套很牛的编码库，为了保证质量和性能，里面的很多codec都是从头开发的。 这两个加起来，实现一些简单的在线视频功能就差不多了。 PS:今天刚看到古永锵也开始做小视频分享网站：优酷。

2006-6-17 于敦德 上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案，以解决在发展中由于负载增长而引起的性能问题，同时在设计网站架构的时候就从根本上避免或者解决这些问题。 今天我们来看一下在网站的设计上一些通常使用的解决大规模访问，高负载的方法。我们将主要涉及到以下几方面： 1、 前端负载 2、 业务逻辑层 3、 数据层 在LJ性能优化文章中我们提到对服务器分组是解决负载问题，实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决，这在邮件的服务器以及个人网站，博客的应用中都有使用，在Windows下面有类似的Active Directory解决方案。有的应用（例如博客或者个人网页）会要求在二级域名解析的时候就将用户定位到所属的服务器群组，这个时候请求还没到应用上面，我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind dlz，这是bind的一个插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在内的多种数据存储方式，可以比较好的解决这个问题。 另外一种涉及到DNS的问题就是目前普遍存在的南北互联互通的问题，通过bind9内置的视图功能可以根据不同的IP来源解析出不同的结果，从而将南方的用户解析到南方的服务器，北方的用户解析到北方的服务器。这个过程中会碰到两个问题，一是取得南北IP的分布列表，二是保证南北服务器之间的通讯顺畅。第一个问题有个笨办法解决，从日志里取出所有的访问者IP，写一个脚本，从南北的服务器分别ping回去，然后分析结果，可以得到一个大致准确的列表，当然最好的办法还是直到从运营商那里拿到这份列表(update:参见这篇文章)。后一个问题解决办法比较多，最好的办法就是租用双线机房，同一台机器，双IP，南北同时接入，差一些的办法就是南北各自找机房，通过大量的测试找出中间通讯顺畅的两个机房，后一种通常来说成本较低，但效果较差，维护不便。 另外DNS负载均衡也是广泛使用的一种负载均衡方法，通过并列的多条A记录将访问随即的分布到多台前端服务器上，这种通常使用在静态页面居多的应用上，几大门户内容部分的前端很多都是用的这种方法。 用户被定位到正确的服务器群组后，应用程序就接手用户的请求，并开始沿着定义好的业务逻辑进行处理。这些请求主要包括两类静态文件(图片，js脚本,css等)，动态请求。 静态请求一般使用squid进行缓存处理，可以根据应用的规模采用不同的缓存配置方案，可以是一级缓存，也可以是多级缓存，一般情况下cache的命中率可以达到70%左右，能够比较有效的提升服务器处理能力。Apache的deflate模块可以压缩传输数据，提高速度，2.0版本以后的cache模块也内置实现磁盘和内存的缓存，而不必要一定做反向代理。 动态请求目前一般有两种处理方式，一种是静态化，在页面发生变化时重新静态页面，现在大量的CMS，BBS都采用这种方案，加上cache，可以提供较快的访问速度。这种通常是写操作较少的应用比较适合的解决方案。 另一种解决办法是动态缓存，所有的访问都仍然通过应用处理，只是应用处理的时候会更多的使用内存，而不是数据库。通常访问数据库的操作是极慢的，而访问内存的操作很快，至少是一个数量级的差距，使用memcached可以实现这一解决方案，做的好的memcache甚至可以达到90%以上的缓存命中率。10年前我用的还是2M的内存，那时的一本杂事上曾经风趣的描述一对父子的对话： 儿子：爸爸，我想要1G的内存。 爸爸：儿子，不行，即使是你过生日也不行。 时至今日，大内存的成本已经完全可以承受。Google使用了大量的PC机建立集群用于数据处理，而我一直觉得，使用大内存PC可以很低成本的解决前端甚至中间的负载问题。由于PC硬盘寿命比较短，速度比较慢，CPU也稍慢，用于做web前端既便宜，又能充分发挥大内存的优势，而且坏了的话只需要替换即可，不存在数据的迁移问题。 下面就是应用的设计。应用在设计的时候应当尽量的设计成支持可扩展的数据库设计，数据库可以动态的添加，同时支持内存缓存，这样的成本是最低的。另外一种应用设计的方法是采用中间件，例如ICE。这种方案的优点是前端应用可以设计的相对简单，数据层对于前端应用透明，由ICE提供，数据库分布式的设计在后端实现，使用ICE封装后给前端应用使用，这路设计对每一部分设计的要求较低，将业务更好的分层，但由于引入了中间件，分了更多层，实现起来成本也相对较高。 在数据库的设计上一方面可以使用集群，一方面进行分组。同时在细节上将数据库优化的原则尽量应用，数据库结构和数据层应用在设计上尽量避免临时表的创建、死锁的产生。数据库优化的原则在网上比较常见，多google一下就能解决问题。在数据库的选择上可以根据自己的习惯选择，Oracle，MySQL等，并非Oracle就够解决所有的问题，也并非MySQL就代表小应用，合适的就是最好的。 前面讲的都是基于软件的性能设计方案，实际上硬件的良好搭配使用也可以有效的降低时间成本，以及开发维护成本，只是在这里我们不再展开。 网站架构的设计是一个整体的工程，在设计的时候需要考虑到性能，可括展性，硬件成本，时间成本等等，如何根据业务的定位，资金，时间，人员的条件设计合适的方案是件比较困难的事情，但多想多实践，终究会建立一套适合自己的网站设计理念，用于指导网站的设计工作，为网站的发展奠定良好的基础。

于敦德 2006-3-16 一、LiveJournal发展历程 LiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能： 博客，论坛 社会性网络，找到朋友 聚合，把朋友的文章聚合在一起 LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。 在上线后，LiveJournal实现了非常快速的增长： 2004年4月份：280万注册用户。 2005年4月份：680万注册用户。 2005年8月份：790万注册用户。 达到了每秒钟上千次的页面请求及处理。 使用了大量MySQL服务器。 使用了大量通用组件。 二、LiveJournal架构现状概况 三、从LiveJournal发展中学习 LiveJournal从1台服务器发展到100台服务器，这其中经历了无数的伤痛，但同时也摸索出了解决这些问题的方法，通过对LiveJournal的学习，可以让我们避免LJ曾经犯过的错误，并且从一开始就对系统进行良好的设计，以避免后期的痛苦。 下面我们一步一步看LJ发展的脚步。

ImageMagick是一套Linux下的开源图形处理工具，针对几乎所有的图片格式提供比较全面的图片处理功能。不像windows下的photoshop，先要双击运行，然后打开图片，然后才能对图片进行处理，ImageMagick可以直接在命令行下运行，加上几个参数，就可以得到想要的图片了，而大批量的处理图片也比photoshop简单的多，写个shell多循环几次就可以了。 假如我想给图片加个框，转一下，再加个阴影，输入以下的命令就可以了： convert -size 400x180 hatching.jpg -thumbnail '200x90>' -bordercolor white -border 6 -bordercolor grey60 -border 1 -background none -rotate 6 -background black ( +clone -shadow 60x4+4+4 ) +swap -background none -flatten -depth 8 -colors 256 -quality 95 poloroid.png 结果是这样： 除了提供命令行工作，ImageMagick同样为各种语言(包括Java，perl,php,c/c++,pascal,python,ruby,tcl/tk等)提供了丰富的开发接口。开发人员可以直接使用这些接口对图片进行高质量，效果丰富的处理。这些都是ImageMagick处理的效果： 更多的效果：Anthony Thyssen写的使用帮助，一些缩略图的效果，一些汽泡状缩略图效果。ImageMagick还有个比较酷的功能是可以做图片的比较： ImageMagick安装起来也相当方便，以php为例，需要下载两个包，一个是ImageMagick的包，一个是MagickWand的包，打包下载后运行： tar zxvf imagemagick.tar.gz cd ImageMagick-xx-xx ./configure

bind dlz全称是bind dynamic loadable zones，是基于bind的提供的一个组件，作用看名字就知道了，支持动态域加载支持。 bind已经有很久的历史，目前是搭建DNS服务器的首选。对于一般网站来说，一个标准的bind已经完全可以完成所有dns解决的工作，但在海量域名数量的情况下，bind也确实存在着一些问题： 1、域名解析信息全部存储在文本文件中，这非常容易导致由于编辑出错导致的域名解析出错。 2、bind运行时将全部的解析信息放在内存里，如果数量巨大将可能出现内存不足的情况，同时解析信息重新加载时所耗费的时间也非常值得考虑，由于加载时间较长，所以基本可以不考虑动态的进行域名的调整。 dlz就是为了解决这个问题而针对bind开发的组件，可以将域名解析信息放在数据库中，从而避免域名信息变动时重新加载的时间，在变动后马上生效。 dlz支持多种数据存储形式，包括文件系统，Berkeley-DB，Postgre-SQL，MySQL，ODBC，LDAP等等。性能的比较在这里。 bind dlz这种提供动态的域名调整，并且仍然可以提供高性能的dns解析服务的特点可以应用于提供二级或三级域名服务的分布式系统的前端，对不同的域名解析到所在服务器组上，从而实现可扩展的系统架构。

旧文重发 2005.8.9 通常的网页缓存方式有动态缓存和静态缓存等几种，在ASP.NET中已经可以实现对页面局部进行缓存，而使用memcached的缓存比ASP.NET的局部缓存更加灵活，可以缓存任意的对象，不管是否在页面上输出。而memcached最大的优点是可以分布式的部署，这对于大规模应用来说也是必不可少的要求。 LiveJournal.com使用了memcached在前端进行缓存，取得了良好的效果，而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。

CMS即Content Management System，一般用于网站的内容组织发布。不严格的意义上来看，博客系统也可以算是一个小型的CMS系统。最近做了一个小的CMS系统，感悟不少。 CMS最基本的功能当然是文章发布系统，后台提供一个文章管理的功能，前面将文章显示出来，按照栏目进行组织。当然，栏目，用户，权限管理等基本功能也是必不可少。 开始文章的显示是动态的，每次有人看都执行一下，然后把页面显示出来。后来发布动态的发布虽然实现简单，但即有着一些天然的缺陷。例如抵御大规模的访问，虽然可以通过缓存来进行解决，但毕竟无法从根本上解决这个问题。还有就是文章浏览与管理集中，依赖于同一数据源，一台数据源出现问题两个服务都无法正常提供。在这个条件下很多CMS就提供了静态化的发布方式，文章以静态文件发布出去后与CMS系统没有直接的关系，无论是访问速度，还是可靠性都得到大幅的提高。 Content的指的是内容，并不单纯是文章，而互联网的逐步发展使用户已经不满足于简单的文本阅读，于是CMS又添加了图文混排的功能，开始是单图，然后进一步是组图。 图片加上了以后，很多网站发布每天发布这么多文章实际上有很多文章是转载来的，如果能够自动的将别人网站的文章抓过来，编辑打勾就可以直接发布效率就高的多了，于是各种抓站系统又成了CMS的标准配置。这里面值得称道的是donews的CMS系统，看到一个喜欢的网页，直接右键保存，系统可以自动分析html页面，并将关键数据取出，点一下确定就可以发布，实在是非常方便。而且可以自动取出关键字，并在文章之间根据关键词形成关联。 在这个过程中模板系统也逐渐产生了。以前的模板多是由技术人员手工开发。例如做一个首页，页面上各个区块的逻辑确定后都手动写代码，写死后很难改变。这样子倒没有错误，只是模板制作效率非常低下，新做或修改模板非常麻烦。在这个条件下就促使开发人员将模板做进一步处理。模板一般会被切分成碎片，碎片有几种类型，文本，图片，广告，列表。前面三种都是简单的对html进行分块处理，列表是动态的功能，负责在发布的时候动态的组织内容。这样子就很方便了，可以很快的做出一个模板，加上模板复制的功能就更加如虎添翼。 目前新浪的CMS是C++做的，重点强调数据结构的丰富，功能非常强大，评论系统做的也不错。评论系统做的最好的是网易，它的延伸阅读做的也不错。Sohu的图库做的不错。 以后CMS发展的方向我认为很大的一方面是内容的相关组织。目前各大网站最常用的提高访问量的招数就是在文章页底添加相关链接，一般是比较火暴的文章和图片，提升访问量非常显著。但这种方式比较死板，每篇文章下面的内容都一样，用户点了一次就不会点第二次。理想的效果是在文章下面添加相关的文章，而且不仅仅局限于CMS内部，应该将站外的相关内容都添加进去，只要用户觉得方便，别怕他不回来。 另外一个方向就是内容来源多样化。例如新浪的CMS，目前似乎只能对手发文章进行比较好的管理，对于iask的内容，对于论坛的内容都是手动的编辑，目前似乎还能满足需要，但从长期来看，是肯定要变的。如果没有RSS的出现，内容来源的多样化还是一句空话，RSS出现后，站内的内容，站外的内容都可以通过RSS来传递。 互联网的入口开始是门户，后来成了搜索引擎，就是因为搜索引擎可以提供来源多样化的内容，一个网站再大也只是一个网站，做再多的频道也就是一个网站，无法满足用户对于多样化，个性化的需要。未来的入口是什么，现在还说不定，但肯定是要对用户的胃口，不能我给你什么，你就看什么，而是看谁能提供给我最想看的东西，让我最少的动脑动手。 我认为未来内容分化为两部分的趋势会逐渐显现出来。一部分提供底层的内容，博客服务提供商以及社区服务提供商会是主力，门户也是重要组成部分；另外一部分仅仅对内容进行组织，充当入口，只提供内容的链接，并不实质的存放内容。 Google的ig是一个例子，微软的Live站略中RSS Live也是重中之重，Yahoo最近也提供了个性化的门户，这些都是引子，慢慢的戏会越来越好看。 发文庆祝CMS完成，小小的展望一下未来，继续做事。

Skype的功能主要可以分为：初始化，登录，用户搜索，呼叫建立与终止，媒体传输和状态消息。 1、初始化 第一次安装后，Skype会发送一段HTTP 1.1的请求给中央服务器，包括关键字"installed"以及所装Skype的版本号。以后的每次登录Skype都会向中央服务器发送一小段包含关键字"getlatestversion"的HTTP 1.1请求，检查是否有新版本的Skype。

1、端口 在Skype的连接属性对话框中可以设置监听的端口号，在安装的时候Skype会随机的选择一个端口作为监听的端口，这一点与HTTP协议等不同，Skype没有默认的服务端口。同时，它还会打开对80和443端口的监听。80是常见的HTTP服务默认端口，而443则是HTTPS服务的默认端口。 2、主机列表(HC，Host Cache) 这里的主机指的是可以提供踏板及广播服务的Super Node(SN)。通常它被存储在注册表里的：HKEY_CURRENT_USER / SOFTWARE / SKYPE / PHONE / LIB / CONNECTION / HOSTCACHE 中.一般情况下，运行两天后，HC中会有约200个机器地址及对应的端口号。