国内外大型SNS网站后台架构对比

【51CTO观察】要问时下什么类型的站点人气最旺？答案当属SNS网站。短短几年的时间，SNS便迅速确立了Web 2.0核心的地位。用户的增长量之快更是让人咂舌，而Facebook访问量首次超越Google的消息也让人觉得SNS的前途不可限量。当然，面对庞大且繁琐的数据量、面对应用的高复杂度及用户体验，大型SNS站点的后台架构成为了51CTO开发频道近期关注的重点之一。

在连续报道了《世界最大的PHP站点 Facebook后台技术探秘》及《专访人人网黄晶：SNS网站后台架构探秘》之后，除了看到SNS网站后台的独特风景之外，我们也看到了作为国内外SNS站点的代表，Facebook和人人网在后台技术应用上还是有很多不同的地方，当然，造成这种不同的原因有很多。这里我们将对比Facebook和人人网的后台架构，在找出这些差异的同时，我们也能够看出，跟国外相比，国内SNS网站的后台技术差距还有多大？差距在哪里？

后台语言的选择

作为一个大型站点，后台语言的选择意味着不同的架构路线、以及不同的开发框架。考虑到SNS网站后台架构的复杂性，可选择的语言并不多，Facebook作为一个大型LAMP网站，选择了PHP；而人人网则使用Java。当然，PHP和Java各具优势，PHP+MySQL的黄金搭档被无数站点所使用；在评价Java的优势时，黄晶老师说道，“而当项目日渐复杂的时候，Java则能通过其良好的OO特性，保持非常好的模块性，也有益于网站重构。”

后台语言的选择有很多因素，选择哪种语言也并不重要，关键是要适合相应的生产环境，这里比较PHP与Java的优劣并没有太大的意义。但要说明的是，每种语言都有它的劣势，如何进行有效的优化才是开发者们需要思考的，就像Facebook为PHP量身打造了HipHop那样。

数据库

在后台架构中，数据库一直是我们关心的重点。曾经日壮山河的关系型数据库，在NoSQL运动下，仿佛显得日薄西山，这句话用在SNS站点中再合适不过了。没错，由于SNS站点的高复杂性，其对数据库的要求非常高，高性能、可扩展性以及可用性，缺一不可。

Facebook并不是一个传统意义上的LAMP站点，MySQL也主要作为一个Key-value的持久性存储使用，而它的存储系统则是NoSQL运动的一个重要组成部分——Cassandra，它的特点也正是SNS站点所需求的，尽管很多人认为NoSQL还不够成熟，缺乏可靠性，但Facebook的成功却是一个活生生的例子。

 
Facebook数据库架构图，请点击原图查看

通过黄晶老师的介绍我们了解到，其实人人网也不只是在使用MySQL。Nuclear是人人网团队自主研发的分布式KV存储系统，目前已经在逐步的试用。关于Nuclear的详细介绍，可以参考人人网UGC团队博客的介绍：http://ugc.renren.com/2010/01/21/ugc-nuclear-guide-use/。

从中我们不难看出，关系型数据库已经不能满足大型SNS站点的需求，在外国大胆使用NoSQL的同时（包括Facebook、Twitter等），国内对NoSQL的使用还是显得比较谨慎，技术水平的差距，在这点上确实有所体现。从长远角度讲，特别是在SNS领域，NoSQL必将会逐步代替传统的关系型数据库。

缓存

缓存技术在后台架构中扮演着重要的角色。对于SNS站点来说，仅仅依靠数据库、Web服务器等软件的自身缓存机制是绝对不能满足要求的。Memcached是人人网和Facebook都用到的一个分布式内存缓存系统，其已成为互联网最有名气的软件之一了。当然，缓存的手段是多种多样的，仅仅保证日常后台的稳定运行也是不够的。面对一些突发事件，缓存机制更是尤为重要，特别是在数据库服务器与Web服务器上。

图片存储架构

图片会给Web服务器带来不小的压力，特别是Facebook处理的图片量（每个月超过30亿张照片被上传），非常惊人！对此，Facebook专门开发了一套图片存储架构——Haystack。关于Haystack的详细介绍，请参考：Facebook图片存储架构技术全解析。

相比于Facebook，人人网并没有一套完整的图片存储架构体系。当然，作为人人网的用户，能够感觉到进行上传图片等一些操作，还是很流畅的。说明以目前的人人网图片处理技术，能够满足目前用户的需求，以及后台的流畅运行。但架构总要着眼于未来，开发一套完整的、高效的架构体系，才是最佳的解决方案。

SNS后台技术未来发展趋势