谈谈MIXI的开源SNS架构
来源:互联网 发布:新视野网络教学平台 编辑:程序博客网 时间:2024/06/18 09:32
首先进行垂直切分,按照表的内容将不同的表划分到不同的数据库中。然后是水平切分,根据用户的ID将不同用户的内容再划分的不同的数据库中,这是比较通常的做法(国内很多大型门户的论坛就是采用此方法),也很管用。划分的关键还是在于应用中的实现,需要将操作封装在在DataLayer,而尽量不影响BusinessLayer。当然完全不改变逻辑层也不可能,这时候最能检验以前的设计是否Extensible,如果以前设计的不错,那创建连接的时候传个tablename,UserID进去差不多就解决问题了,而以前如果sql代码到处飞,或者数据层封装的不太好的话那就糟糕了。
这样做了以后并不能从根本上解决问题,尤其是对于像mixi这种SNS网站,页面上往往需要引用大量的用户信息,好友信息,图片,文章信息,跨表,跨库操作相当多。这个时候就需要发挥memcached的作用了,用大内存把这些不变的数据全都缓存起来,而当修改时就通知cache过期,这样应用层基本上就可以解决大部分问题了,只会有很小一部分请求穿透应用层,用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右(当然根据页面大小情况不尽相似),可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器,每个Cache Server 2G内存,这些CacheServer与App Server装在一起。因为Cache Server对CPU消耗不大,而有了Cache Server的支援,AppServer对内存要求也不是太高,所以可以和平共处,更有效的利用资源。
图片的处理就显得相对简单的多了。对于mixi而言,图像主要有两部分:一部分是经常要使用到的,像用户头像,群组的头像等等,大概有100多GB,它们被Squid和CDN所缓存,命中率相对比较高;另一部分是用户上传的大量照片,它们的个体访问量相对而言比较小,命中率也比较低,使用Cache不划算,所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上,在用户访问的时候直接进行访问,当然图片的位置需要在数据库中进行记录,不然找不到放在哪台服务器上就郁闷了。
- 谈谈MIXI的开源SNS架构
- mixi.jp:使用开源软件搭建的可扩展SNS网站
- [转]mixi.jp:使用开源软件搭建的可扩展SNS网站
- mixi.jp:使用开源软件搭建的可扩展SNS网站
- [转]mixi.jp:使用开源软件搭建的可扩展SNS网站
- [转]mixi.jp:使用开源软件搭建的可扩展SNS网站
- [SNS]Mixi
- 谈谈SNS网站的黏度
- 分析mixi.jp and Yeejee.com:用开源搭建的可扩展大型SNS网站
- 分析mixi.jp and Yeejee.com:用开源搭建的可扩展大型SNS网站(一)
- 日本最大社交网络Mixi的服务器架构图解
- 大型web2.0互动网站设计方案:分析mixi.jp and Yeejee.com:用开源搭建的可扩展大型SNS网站
- 大型web2.0互动网站设计方案:分析mixi.jp and Yeejee.com:用开源搭建的可扩展大型SNS网站
- 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统
- 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统
- 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统
- 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统[原创]
- 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统
- popup弹窗(备忘)
- part7
- 在Linnux上安装rpm软件包
- pgstatpack,postgresql的性能分析利器
- 把一个字符串转化成浮点数
- 谈谈MIXI的开源SNS架构
- Ganglia简介
- C++ 字符串数组去重
- 123
- postgresql 的进程监控&管理
- hibernate 一对多单向关联配置完整示例
- ajax提交相同url,重复发送请求后台,页面无更新的问题解决
- VirtualAlloc VirtualFree
- Linux引导过程内幕