大型网站架构之:MySpace的体系架构

MySpace.com有着6500万的订阅者，是因特网上增长最快的网站之一，每天还有260，000新用户注册。它经常因为性能问题而受指责，MySpace不得不处理其他网站很少碰到的或大或小的一些问题。它们是怎么做的呢？
Site: http://myspace.com
站点：http://myspace.com

平台
? ASP.NET 2.0
? Windows
? IIS
? SQL Server

内部运行情况？
? MySpace 每天处理15亿的页面页面查看，白天处理230万并发的用户

? 会员用户里程碑
- 500,000用户：简单的磕磕绊绊的体系结构
- 1百万用户：痛苦的垂直分割解决伸缩性
- 3百万用户：Scale-Out 胜过Scale-Up（按比例增加）
- 9百万用户：站点迁移到ASP.NET，增加虚拟存储
- 260万用户：MySpace拥有了64位技术
? 500,000 个帐号对于两个web服务器和一个数据库来说负担太大了
? 100-200万个帐号

   - 他们使用了一种数据库体系结构，围绕着垂直分割的概念，提供不同服务比如界面登录，用户资料和博客等的网站的各部分都有单独的数据库。
   - 垂直分割方案有助于分开数据库读和写的工作量，并且当用户需要一个新特征时，MySpace 将会加入一个新的在线数据库来支持它。
- MySpace 从直接使用附着于它的数据库的服务器的存储设备转换到一个存储区域网络（SAN），里面大量的磁盘存储设备由一个高速，专用网络联系到一块，同时数据库连接到SAN。到SAN的改变提高了性能，正常运行时间和可靠性。

? 300万个帐号
- 垂直分割解决方案并没有持续很长时间因为它们重复了一些水平的信息像跨过所有垂直片的用户帐号。有这么多的重复它会使系统变慢，肯定要失败。
- 个人应用比如Web站点子部分上的博客将会增长到对于单独一个数据库服务器来说太大的程度
- 在逻辑上重组所有核心数据到一个数据库里
- 把它的用户基本信息分成100万帐号一个的块，然后把所有有键的数据放到SQL Server不同实例的这些帐号中

? 900万-1700万帐号
   - 迁移到ASP.NET后，使用了比先前的体系结构更少的资源。150个服务器运行新的代码就能够做原来246个服务器做的同样的工作。
   - 再看看存储瓶颈。实施SAN解决了原来的一些性能问题，但是现在Web站点的需求开始间歇性地超过了SAN的I/O能力-它从磁盘存储读写的速度
   - 使用每个数据库100个帐号的分开方式达到了极限，因为这已经超过了极限；
   - 迁移到一个虚拟存储体系结构，那里整个SAN被当作一个大的存储池来对待，不需要特定的磁盘为特定的应用服务。现在
     MySpace在设备上从相对新的SAN厂商，3PARdata方面已经标准化了。增加了一个高速缓存层—服务器放在Web服务器和数据库服务器之间，它唯一的工作就是捕获内存中频繁访问的数据对象的副本，然后把它们用于Web应用，不需要数据库查询。

? 2600万帐号
   - 迁移到64位SQL server以解决它们的内存瓶颈问题。它们的标准数据库服务器配置使用64GB的RAM。

Myspace的经验能够说明什么？
? 你可以使用微软的技术构建大型网站。
? 从一开始就应该使用缓存。
? 高速缓存是一个更好的地方存储临时数据，比如Web站点上跟踪一个特定用户的会话产生的临时文件，就不再需要记录到数据库里，
? 嵌入OS特征来检测拒绝服务攻击会产生无法解释的错误
? 把数据分布到地理位置不同的数据中心，以免发生断电事故。
? 从开始就考虑使用虚拟存储/簇文件系统。它能让你大量并行IO访问，而且不需要任何重组就能够增加所需要的磁盘。