原文转自:http://www.tech-q.cn/thread-1330-1-1.html 所有版权归原作者所有
第一章 相册瓶颈所在
1.用户上传海量数据是一个头疼的事情，每天上千万的数量，又因为互联网的特殊性，会出现高峰期和低潮期，以每天10，000，000张图片来计算，高的时候，每秒上传有可能会在上千张，而低的时候可忽略不计。
2.因为产品不同，往往上传一张原始的照片会需要压缩成四五张不同大小的图片。这个压缩过程相当消费cpu。
相信有同一问题的应该有：QQ空间，网易相册，新浪博客，flikr等等。
第二章 校内相册的发展和改革
第一阶段，原始社会。
在第一阶段，我们过着刀耕火种的生活，java代码上传+jmagick压缩，其结果就是，再多的服务器，也搞不定越来越多的访问量。
第二阶段，具有封建主义气息的资本主义社会。
这一阶段，我们痛定思痛啦，服务常常挂啊，怎么办？怎么办，当然是分布式处理，分析下原因，原来挂是因为cpu太高，用户上传一图压成四图，太费劲了。干脆传到其他cpu多的机器去。
说时迟那时快，我们挽起袖子，一个分布式的上传压缩过程就出来了。。。
所使用的方法：
结果发现。。。没啥改观。。。
第三阶段，完全没有社会主义气息的共产主义社会。
改革春风吹满地，齐心协力跨世纪。
精心研究下，使用了以下的方案，将性能提高了3.5倍，同样数目的照片以前上传如需要100秒的，现在35秒即可以搞定。
第三章 校内相册核心技术
先上无码图：
看明白没，没看明白？好 继续看内容吧：
1)nginx:最前端服务器,负责接受来自client的上传文件请求及其他的相前web页面请求,把文件上传请求转发给lighttpd,把web页面请求转发给resin
2)lighttpd:负责接受所有文件上传,并把请求交给fastcgi处理(此处的fastcgi可以是本机可以是网络,目前用的是本机)，其实lighttpd完全可以取代nginx,把文件上传请求交给fastcgi,把其他请求交给resin处理,不过为了平稳过渡和平常重启,仍然用了nginx,
3)fastcgi:接受来自webserver的文件上传请求,处理并返回结果给webserver,多进程,可以由lighttpd启动,也可以由spawn-fcgi来启动,不过后者在fastcgi进程死掉的情况下不能自动重启,所以目前采用前者。fastcgi的上传代码很常规，压缩的代码使用了interl的icc和ipp的操作，对性能提升非常明显。