大型web2.0互动网站设计方案
需积分: 9 194 浏览量
2011-09-22
11:31:07
上传
评论
收藏 14KB DOC 举报
大型 web2.0 互动网站设计方案
[项目架构&管理]
post by 天使羽翼 / 2011-3-9 17:15 Wednesday
总概关键点：
1，Mysql 切分，采用 Innodb 运行
2，动态 Cache 服务器 -- 美国 Facebok.com,中国 Yeejee.com,日本 mixi.jp 均采用开
源分布式缓存服务器 Memcache
3，图片缓存和加速
Mixi 目前是日本排名第三的网站，全球排名 42，主要提供 SNS 服务：日记，群组，站内
消息，评论，相册等等，是日本最大的 SNS 网站。Mixi 从 2003 年 12 月份开始开发，由
现在它的 CTO - Batara Kesuma 一个人焊，焊了四个月，在 2004 年 2 月份开始上线运
行。两个月后就注册了 1w 用户，日访问量 60wPV。在随后的一年里，用户增长到了
21w，第二年，增长到了 200w。到今年四月份已经增长到 370w 注册用户，并且还在以
每天 1.5w 人的注册量增长。这些用户中 70%是活跃用户（活跃用户：三天内至少登录一
次的用户），平均每个用户每周在线时间为将近 3 个半小时。
下面我们来看它的技术架构。Mixi 采用开源软件作为架构的基础：Linux 2.6，Apache
2.0，MySQL，Perl 5.8 ，memcached ，Squid 等等。到目前为止已经有 100 多台
MySQL 数据库服务器，并且在以每月 10 多台的速度增长。Mixi 的数据库连接方式采用的
是每次查询都进行连接，而不是持久连接。数据库大多数是以 InnoDB 方式运行。Mixi 解
决扩展问题主要依赖于对数据库的切分。
首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，
根据用户的 ID 将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管
用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务
层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设
计的不错，那创建连接的时候传个表名，用户 ID 进去差不多就解决问题了，而以前如果
sql 代码到处飞，或者数据层封装的不太好的话那就累了。
这样做了以后并不能从根本上解决问题，尤其是对于像 mixi 这种 SNS 网站，页面上往往
需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时
候就需要发挥 memcached 的作用了，用大内存把这些不变的数据全都缓存起来，而当
修改时就通知 cache 过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部
分请求穿透应用层，用到数据库。Mixi 的经验是平均每个页面的加载时间在 0.02 秒左右
（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi 一共在 32
台机器上有缓存服务器，每个 Cache Server 2G 内存，这些 Cache Server 与 App
Server 装在一起。因为 Cache Server 对 CPU 消耗不大，而有了 Cache Server 的支援，
App Server 对内存要求也不是太高，所以可以和平共处，更有效的利用资源。
资源评论
