MySpace架构

说起MySpace，可能很多人对他印象很深，MySpace.com成立于2003年9月，是目前全球最大的社交网站。它为全球用户提供了一个集交友、个人信息分享、即时通讯等多种功能于一体的互动平台，同时他也是.NET应用最出色的网站之一。下面我们一起来回顾一下MySpace架构的改革之路，或许我们能从中得到一点点架构方面的经验和教训。

1、50万用户

最早myspace网站由一台数据库服务器和两台Web服务器构成，此后一段时间又加了几台web服务器。但在2004年早期，用户增加到50万时一台数据库服务器就显得力不从心了。

他们设计了第一代架构，在此架构中他们运行3个SQL Server2000服务器，一个为主，所有的新数据都提交给他，然后再复制给其他两个数据库服务器。另外两台服务器用来给用户提供信息浏览，也就是只做数据读取。在一段时间内效果不错，只需要增加数据库服务器，扩大硬盘，就可以应对用户数和访问量的增加了。

2、100万-200万用户

当达到这个数字时，myspace数据库服务器遇到了I/O瓶颈，即他们存取数据的速度跟不上了。而这时据他们第一个架构只要5个月。有人花5分钟都无法完成留言，很多用户认为myspace完蛋了。

这个时候新的架构被快速提出来了，这一次他们把数据库架构按照分割模式设计，以网站功能分出多种，如登陆、现实用户资料、博客信息、等分门别类存储在不同的数据库 服务器里。这种垂直分割策略利于多个数据库分担访问压力(天涯曾经就这么做过)。后来myspace从存储设备与数据库服务器直接交互的方式SAN（用高 带宽和专门设计的网络将大量磁盘存储设备链接在一起，而数据库链接到SAN）。

3、300万用户

到300万用户时，这种架构开始也不行了，因为每个数据库都必须有每个用户表副本，意识是一个用户注册后，他的信息会分别存在每个数据库中，但这种做法有 可能某台数据库服务器挂掉了，用户使用一些服务可能会有问题。另一个问题是比如博客信息增长太快，专门为他服务的数据库的压力过大，而其他一些功能很少被 使用又在闲置。这就好像有人忙的要死，有人闲的要死。

于是他们购买了更好更贵的服务器来解决管理更大数据库的问题。但专家预测他们即使昂贵专业的服务器到最后也会不堪重负，他们必须调整架构而不是掏钱买更 好的服务器。于是他们的第三代架构出现了。分布式计算架构，他们分布众多服务器，但从逻辑上看成是一台服务器。拿数据库来说，不能再按功能拆分了，看成只 有一个数据库服务器。数据库模型中维护一个用户表、博客信息表、等等同看作在一个数据库服务器中。

然后他们开始把用户按每百万一组分割，每一组的用户访问指定的数据库服务器。另外一个特殊服务器保存所有用户的帐号和密码。他们的设计师说如果按照这种模式以更小粒度划分架构是可以进一步优化负荷负担的(50万用户为一组 或者更少)。

4、900万-1700万用户

myspace在这个时候把网站代码全部改为.net语言，事实证明网站跑的比以前快了很多、执行用户的请求消耗非常少的资源，后来他们把所有的程序都改成.net了。但问题到1000万时还是出来了。

用户注册量太快，按每100万分割数据库的策略不是那么完美，比如他们的第7台数据库服务器上线仅仅7天就被塞满了。主要原因是佛罗里达一个乐队的 歌迷疯狂注册。而且某台数据库服务器可以在任何原因 任何时候遭遇特别大的负荷。他们的解决办法是人工把崩溃的数据库里的用户迁移走。但这不是一个好办法。

这个时候myspace购买了3PAdata设备，他的牛逼之处是真正把所有的数据库看成一个整体。他会根据情况把负荷平均分配出去，比如当用户提交一个信 息，他会看哪个数据区域空闲然后分配给他，然后会在其他多处地方留有副本，不会出现一台数据库服务器崩溃，而这台数据库里的信息没有办法读取的情况，这样 做看起来好极了。

另外他们增加了缓存层，以前用户查询一个信息，就请求一次数据库，现在当一个用户请求数据库后，缓存层就会保留下来一个副本，当其他用户再访问时就不需要再请求数据库了，直接请求缓存就够了。

5、2600万用户

他们把服务器更换到运行64位的服务器，这样服务器上可最多挂上32G内存，这无疑有提升了网站性能，用户感觉这个网站开始稳定快起来了。但一个新问题意外出现了。他们放数据库服务中心的洛杉矶全市停电了。这导致整个系统停止运行长达12个小时。

这时他们实现了在地理上分布多个数据中心以防止洛杉矶事件再次出现，在几个重要城市的数据中心的部署可以防止某一处出现故障，整个系统照样提供服务，如果几个地方都出现故障，那么这就意味着国家出现了重大灾难，这种几率是非常低的。

6、总结

这个架构变化升级相当有意思，架构随着用户量的提升作仓促的变化，但又恰到好处，看来MySpace又验证了一句古话“有压力才会有动力”。同时他给我们后人的启示是要尽早发现系统的瓶颈，设计师在设计时要有前瞻思想，否则今后有可能也要这样仓促的升级你的产品。