校内相册发展过程及核心技术分析爆料
前言
感谢人人网曾经的吕威大侠、现在的文斌大侠、谢龙大侠对人人网相册的不朽贡献,是吕威大侠精益求精的专研才有如此优秀的上传方案。
第一章 相册瓶颈所在
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的操作,对性能提升非常明显。
第四章 目前还没有第四章 等待开源吧
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:cc0cc 来源: 我是陈科学院
- 标签: 相册
- 发布时间:2009-11-16 23:14:34
- [68] Go Reflect 性能
- [68] 如何拿下简短的域名
- [67] Oracle MTS模式下 进程地址与会话信
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [48] 读书笔记-壹百度:百度十年千倍的29条法则