[转] 谈谈MIXI的开源SNS架构

SNS总体策略:

页面大量的用户信息, 需要缓存(memcached); 图片分类根据图片使用频率来区分(常用图片如头像等做缓存; 个人上传的图片不做缓存)是否使用缓存.

 

转载自: http://awhite2008.blog.sohu.com/98385877.html

分布式的部署web应用的例子已经很多了，自己没有真正意义上实践过，特别期待与有这方面经验的大虾沟通，充实一下自己，前段时间有关于technorati的数据库架构的文章，其中提到了藏袍的文章，关于日本网站MIXI的 应用架构的，谈到的东西中规中矩，但是很实用，比如数据库的分表、分库，按照逻辑上、物理上对数据进行组织。技术架构上，mixi崇尚开源，Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等构成了应用的基础，数据库连接方式采用的是Connect when Query，而不是Permanent Connect，数据库以InnoDB模式运行。数据的扩展性，采用横向、纵向的数据库分割。

       首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常 的做法（国内很多大型门户的论坛就是采用此方法），也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在Data Layer，而尽量不影响Business Layer。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否Extensible，如果以前设计的不错，那创建连接的时候传个table name，UserID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就糟糕了。

      这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操 作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就 可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不 尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。

      图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们 被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划 算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不 然找不到放在哪台服务器上就郁闷了。

转载于:https://www.cnblogs.com/DavidYan/articles/2526482.html