<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>目之所及 - hpan.net &#187; temp technology</title>
	<atom:link href="http://hpan.net/category/tech/feed/" rel="self" type="application/rss+xml" />
	<link>http://hpan.net</link>
	<description>-- 平衡才可长久</description>
	<lastBuildDate>Tue, 03 May 2011 05:02:52 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>通过了解MySpace的六次重构经历,来认识分布式系统到底该如何创建</title>
		<link>http://hpan.net/2007/11/%e9%80%9a%e8%bf%87%e4%ba%86%e8%a7%a3myspace%e7%9a%84%e5%85%ad%e6%ac%a1%e9%87%8d%e6%9e%84%e7%bb%8f%e5%8e%86%e6%9d%a5%e8%ae%a4%e8%af%86%e5%88%86%e5%b8%83%e5%bc%8f%e7%b3%bb%e7%bb%9f%e5%88%b0%e5%ba%95/</link>
		<comments>http://hpan.net/2007/11/%e9%80%9a%e8%bf%87%e4%ba%86%e8%a7%a3myspace%e7%9a%84%e5%85%ad%e6%ac%a1%e9%87%8d%e6%9e%84%e7%bb%8f%e5%8e%86%e6%9d%a5%e8%ae%a4%e8%af%86%e5%88%86%e5%b8%83%e5%bc%8f%e7%b3%bb%e7%bb%9f%e5%88%b0%e5%ba%95/#comments</comments>
		<pubDate>Wed, 14 Nov 2007 13:47:32 +0000</pubDate>
		<dc:creator>Horn.pan</dc:creator>
				<category><![CDATA[temp technology]]></category>
		<category><![CDATA[myspace]]></category>
		<category><![CDATA[分布式]]></category>
		<category><![CDATA[技术]]></category>

		<guid isPermaLink="false">http://hpan.net/?p=62</guid>
		<description><![CDATA[在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。 虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，&#8221;我们已经尽可能把事情做到最好&#8221;。 里程碑一：50万账户 按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。 单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。 但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。 但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。 在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。 里程碑二：1-2百万账户 MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇&#8221;主要矛盾&#8221;，Benedetto说，这意味着MySpace永远都会轻度落后于用户需求。 &#8220;有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。&#8221;他补充道。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。 垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。 里程碑三：3百万账户 当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。 另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。 2004年中，MySpace面临Web开发者称之为&#8221;向上扩展&#8221;对&#8221;向外扩展&#8221;（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。 但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。 另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。&#8221;搞不好，开发人员的所有工作都将白费&#8221;，Benedetto说。 因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，&#8221;那时候，这个方案看似可能解决一切问题。&#8221;如稳定性，更棒的是对现有软件几乎没有改动要求。 糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，&#8221;换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。&#8221; 因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。 当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。 里程碑四：9百万到1千7百万账户 2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是Microsoft目前主推的Web站点编程环境。 可以说是立竿见影， MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。 最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。 账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。 原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。 某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。&#8221;SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。&#8221;Benedetto说。 最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，&#8221;大概需要两个人全职工作。&#8221;Benedetto说。 长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。 在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。 当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。 缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，&#8221;我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。&#8221;但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。 增加缓存服务器是&#8221;一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。&#8221;Benedetto补充道。 里程碑五：2千6百万账户 2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，&#8221;这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。&#8221;支持64位的数据库可以管理更多内存。 更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL [...]]]></description>
			<content:encoded><![CDATA[<p><span style="color: #800000">在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。</span></p>
<p style="color: #800000">虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，&#8221;我们已经尽可能把事情做到最好&#8221;。</p>
<p style="color: #800000">里程碑一：50万账户</p>
<p style="color: #800000">按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。<span id="more-62"></span></p>
<p style="color: #800000">单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。</p>
<p style="color: #800000">但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。</p>
<p style="color: #800000">但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。</p>
<p style="color: #800000">在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。</p>
<p style="color: #800000">里程碑二：1-2百万账户</p>
<p style="color: #800000">MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇&#8221;主要矛盾&#8221;，Benedetto说，这意味着MySpace永远都会轻度落后于用户需求。</p>
<p style="color: #800000">&#8220;有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。&#8221;他补充道。</p>
<p style="color: #800000">这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。</p>
<p style="color: #800000">垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。</p>
<p style="color: #800000">里程碑三：3百万账户</p>
<p style="color: #800000">当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。</p>
<p style="color: #800000">另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。</p>
<p style="color: #800000">2004年中，MySpace面临Web开发者称之为&#8221;向上扩展&#8221;对&#8221;向外扩展&#8221;（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。</p>
<p style="color: #800000">但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。</p>
<p style="color: #800000">另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。&#8221;搞不好，开发人员的所有工作都将白费&#8221;，Benedetto说。</p>
<p style="color: #800000">因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，&#8221;那时候，这个方案看似可能解决一切问题。&#8221;如稳定性，更棒的是对现有软件几乎没有改动要求。</p>
<p style="color: #800000">糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，&#8221;换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。&#8221;</p>
<p style="color: #800000">因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。</p>
<p style="color: #800000">既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。</p>
<p style="color: #800000">当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。</p>
<p style="color: #800000">里程碑四：9百万到1千7百万账户</p>
<p style="color: #800000">2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是Microsoft目前主推的Web站点编程环境。</p>
<p style="color: #800000">可以说是立竿见影， MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。</p>
<p style="color: #800000">最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。</p>
<p style="color: #800000">账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。</p>
<p style="color: #800000">原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。</p>
<p style="color: #800000">某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。&#8221;SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。&#8221;Benedetto说。</p>
<p style="color: #800000">最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，&#8221;大概需要两个人全职工作。&#8221;Benedetto说。</p>
<p style="color: #800000">长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。</p>
<p style="color: #800000">在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。</p>
<p style="color: #800000">当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。</p>
<p style="color: #800000">缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，&#8221;我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。&#8221;但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。</p>
<p style="color: #800000">增加缓存服务器是&#8221;一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。&#8221;Benedetto补充道。</p>
<p style="color: #800000">里程碑五：2千6百万账户</p>
<p style="color: #800000">2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，&#8221;这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。&#8221;支持64位的数据库可以管理更多内存。</p>
<p style="color: #800000">更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。</p>
<p style="color: #800000">意外错误</p>
<p style="color: #800000">如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的&#8221;意外错误&#8221;是怎么引起的呢？</p>
<p style="color: #800000">原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工，&#8221;无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个&#8217;意外错误&#8217;提示。&#8221;他解释说。</p>
<p style="color: #800000">去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量MySpace合法用户连接时也会引起服务器反击。</p>
<p style="color: #800000">&#8220;我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。&#8221;Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：&#8221;别开枪，是友军。&#8221;</p>
<p style="color: #800000">紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等待，不能提供任何服务。</p>
<p style="color: #800000">Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。</p>
<p style="color: #800000">2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。</p>
<p style="color: #800000">MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。</p>
<p style="color: #800000">&#8220;作为开发人员，我憎恶Bug，它太气人了。&#8221;Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。&#8221;不过，MySpace对我们的用处很大，因此我们可以原谅偶发的故障和错误。&#8221; Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。</p>
<p style="color: #800000">这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，&#8221;我已经两次给MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。&#8221;另一个用户回复说，&#8221;毕竟它是免费的。&#8221;Benedetto坦承100%的可靠性不是他的目标。&#8221;它不是银行，而是一个免费的服务。&#8221;他说。</p>
<p style="color: #800000">换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。&#8221;关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。&#8221;Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了&#8221;checkpoint&#8221;操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。</p>
<p style="color: #800000">Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站点。</p>
<p style="color: #800000">&#8220;我们犯过大量错误，&#8221;Benedetto说，&#8221;但到头来，我认为我们做对的还是比做错的多。&#8221;</p>
<p style="color: #800000">MySpace Tech Roster</p>
<p style="color: #800000">January 16, 2007</p>
<p style="color: #800000">By David F. Carr</p>
]]></content:encoded>
			<wfw:commentRss>http://hpan.net/2007/11/%e9%80%9a%e8%bf%87%e4%ba%86%e8%a7%a3myspace%e7%9a%84%e5%85%ad%e6%ac%a1%e9%87%8d%e6%9e%84%e7%bb%8f%e5%8e%86%e6%9d%a5%e8%ae%a4%e8%af%86%e5%88%86%e5%b8%83%e5%bc%8f%e7%b3%bb%e7%bb%9f%e5%88%b0%e5%ba%95/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

