坚信科学,分享技术

2018全新版本,未来在blog.54chen.com更新博客!

>>>尝试更加利于阅读的2014版科学院,以后都在新版上写。

[五四陈科学院]校内相册发展过程及核心技术分析爆料

信春哥,转载的都给我注明出处:http://www.54chen.com/801-54-chen-academy-schools-the-development-process-and-the-album-broke-the-heart-of-technical-analysis/

前言

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

第一章 相册瓶颈所在

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的上传代码很常规,压缩的代码使用了interliccipp的操作,对性能提升非常明显。

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


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]
本文链接: http://www.54chen.com/architecture/54-chen-academy-schools-the-development-process-and-the-album-broke-the-heart-of-technical-analysis.html

This entry was posted in 架构研究 and tagged , , . Bookmark the permalink.

27 Responses to “[五四陈科学院]校内相册发展过程及核心技术分析爆料”

  1. unixhater 说:

    最关键的海量存储系统没说

  2. bera 说:

    简单的说就是把所有请求都给resin变成了上传图片的给fastcgi 其他的给resin 然后采用了比较好的压缩算法?

  3. blankyao 说:

    为啥第二阶段会没有改观呢?

  4. cc0cc 说:

    海量存储系统不是这里说的瓶颈哦,人人网用的是国内一个商业分布式文件系统。

  5. cc0cc 说:

    这个理解是正确的

  6. cc0cc 说:

    第二阶段的网络开销太大了,文件上传这种事情,尽管在内网千兆环境,分布式搞起来也不能满足立刻出图的要求

  7. yuehei 说:

    感觉很普通,没有什么特别的地方

  8. yuehei 说:

    主要是海量存储,校内应该实力开发自己的海量存储系统

  9. cc0cc 说:

    呵呵 兄弟你遇到过同样的问题吗 能很普通地分享出来不

  10. cc0cc 说:

    商用有商用的好处,同时也有项目在用hadoop什么的处理一些事情,这里讨论的重点不是存储,而是压缩

  11. haitian 说:

    校内的图片上传还可以,但图片服务器的处理感觉在各大网站中最垃圾的。
    经常遇到图片无法显示的情况,碰到多的时候直接无法正常浏览。我即使把图片地址直接放到我在IDC机房的服务器上访问,也一样。十分闹心。在其他网站上几乎遇不到这种情况。

  12. cc0cc 说:

    兄弟所言甚是,可惜这一块不在我们团队的可控范围内,只能等待未来领导们怎么处理了。

  13. isll 说:

    虽然重点不是存储,但能否说一下图片存储,
    是基于你前面博客所写的dynamo类似的那个东东?

  14. cc0cc 说:

    dynamo类似的那个东西是分布式的数据存储,我们正在实现中
    这里是分布式的文件存储,有不少的商业公司专门做这个,用hadoop要实现也不难。

  15. ideawu 说:

    不明白第三种使用的技术为什么会缩短图片上传时间? 原来的100秒, 时间都花在哪了? 如果100秒和35秒都是在同一台服务器上获取的, 我看唯一的区别可能是进程增多了, 和请求被拆分了以应用流水线技术.

  16. cc0cc 说:

    兄弟看问题很透彻,原来的100s,在jmagick的消费上太在大,没有完全发挥intel的cpu优势,35s的时候,是因为:1.使用了一个简单的方案,将图片利用size来等比缩小后再进行缩图;2.使用了ipp和icc

  17. ideawu 说:

    这样看来, 似乎性能的提升和架构的变更没有太大关系, 但开始我以为文章的重点在于架构的变更. 还是我的理解有误, 其实第一种和第三种的架构就是同一种?

    能不能把100秒时的架构图也传上来看看? 另外, 使用第一种架构, 然后改用第三种架构的图像处理算法和技术, 测试的结果会是多少呢? 我对这个很感兴趣.

    如果设计合理, 使用多台服务器进行处理, 性能应该会比单台更好的. 但文中提到前两种都没有改进, 所以, 看完本文, 疑惑很多.

  18. cc0cc 说:

    因为有些东西不好太露骨,望体谅,不过讨论出来的话你应该能理解,也不会有人来盯着我在讨论什么
    第一种是传统的jmagick 其实也就是java-jni-c这样的过程,第三种是c++,没有语言的转换。
    第二种中提到用多台处理,消费转到了网络上,还有机器的协调上,所以其实也很难找到一个很好的算法。

  19. ideawu 说:

    毕竟是工作内容, 能理解. 能尝试各种技术, 看对性能的影响, 应该是一件很有趣的事情. 谢谢分享!

  20. isll 说:

    突然想起个问题,冒昧的问一句,不知道人人有没有考虑或者参考过facebook的cassanra等类似的小对象存储方案来满足自己的存储要求?

  21. cc0cc 说:

    cassanra里的一个兄弟是来自亚马逊dynamo研发成员,我们正在实现类似的分布式key-value系统,我正好有幸参与研发这个项目。相信近期会推出一个全新的存储系统。

  22. isll 说:

    呵呵,希望推出来的时候能做个简要的介绍啊

  23. isll 说:

    呵呵,希望推出来的时候,能做个简单的介绍啊

  24. cc0cc 说:

    介绍那是必须的,没事常过来,:)

  25. 新之助 说:

    好想加入人人 工作团队呀

  26. cc0cc 说:

    呵呵 欢迎加入哦,见右上脚的广告

Leave a Reply