IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

校内相册发展过程及核心技术分析爆料

我是陈科学院 2009-11-16 23:14:34 累计浏览 2,641 次
本机暂存

    前言

    感谢人人网曾经的吕威大侠、现在的文斌大侠、谢龙大侠对人人网相册的不朽贡献,是吕威大侠精益求精的专研才有如此优秀的上传方案。

    第一章 相册瓶颈所在

    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的操作,对性能提升非常明显。

    第四章 目前还没有第四章 等待开源吧

同分类推荐文章

  1. 等了十年的 Go 链式管道,终于来了:seq 让你像写 Scala 一样写 Go (2026-06-25 18:38:18)
  2. Go 实验特性详解 (2026-06-21 10:05:27)
  3. amd64 微架构级别对 Go 程序性能提升多少? (2026-06-21 09:38:49)

查看更多 后端 文章 →

建议继续学习

  1. 大型高并发高负载网站的系统架构分析 (累计阅读 9,006)
  2. Craigslist 的数据库架构 (累计阅读 6,703)
  3. 可扩展的分布式数据库架构 (累计阅读 6,396)
  4. 各消息队列软件产品大比拼 (累计阅读 6,207)
  5. 如果用户在5分钟内重复上线,就给他发警告,问如何设计? (累计阅读 6,029)
  6. 统计指标和术语汇总 (累计阅读 4,052)
  7. 构建C1000K的服务器(2) – 实现百万连接的comet服务器 (累计阅读 3,569)
  8. 图片服务架构学习之ZIMG (累计阅读 3,427)
  9. Infobright 数据仓库 (累计阅读 3,344)
  10. 核心业务系统数据库平台迁移: Oracle -> MySQL (累计阅读 3,120)