Linux下LAMP（Apache+PHP+MySql）环境配置 LAMP是一个缩写Linux+Apache+MySql+PHP，它指一组通常一起使用来运行动态网站或者服务器的自由软件：* Linux，操作系统；* Apache，网页服务器；* MySQL，数据库管理系统（或者数据库服务器）；* PHP 和有時 Perl 或 Python，脚本语言。今天介绍一下Linux下LAMP（Apache+PHP+MySql）环境配置：1、下载软件MySql：wget http://down1.chinaunix.net/distfiles/mysql-5.0.56.tar.gzApache：wget http://apache.freelamp.com/httpd/httpd-2.2.13.tar.gzPHP：wget http://125.39.113.23:9203/CDE349DEF7D7A6AC19DE5771F752CA258C693F634815D4BE/cn.php.net/distributions/php-5.2.10.tar.bz22、安装MySql安装步骤：tar zxvf  mysql-5.0.56.tar.gzcd mysql-5.0.56./configure –prefix=/usr/local/mysql –sysconfdir=/etc –localstatedir=/var/lib/mysqlmakemake install#prefix=/usr/local/mysql mysql安装的目标目录#sysconfdir=/etc my.ini配置文件的路径#localstatedir=/var/lib/mysql 数据库存放的路径安装完以后要初始化数据库，当然你是升级的话不用做这步；/usr/local/mysql/bin/mysql_install_db如果系统没有mysql这个用户的话，最好做以下这步：useradd -M -o -r -d /var/lib/mysql -s /bin/bash -c “MySQL Server” -u 27 mysql然后我启动mysql/usr/local/mysql/bin/safe_mysqld &ok，先看看mysql能否正常工作mysql -uroot mysql一般情况下都是不能正常链接数据库，错误提示一般为：ERROR 2002: Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)其实网上大家问的最多的都是整个问题，说什么链接不到mysqld.sock，其实大家不妨看看mysql的错误日志就明白怎么回事，我这里的错误日志是在/var/lib/mysql/*.err 你会发现mysql只所以不能启动，是因为/var/lib/mysql的权限不允许mysql服务访问，英文mysql默认是调用mysql用户来启动服务的，好了，既然知道是什么原因找到不能启动，那就简单了。我们只要chown -R mysql:mysql /var/lib/mysql 就行，如果还是启动不了，再慢慢调试权限，反正一般启动不了都是权限的问题。如果大家还是不能启动不了的话，那就用我的比较繁琐的权限的设置，反正我每次都是这么做的，一般不会有问题，见下：chown -R root /usr/local/mysqlchgrp -R mysql /usr/local/mysqlchown -R root /usr/local/mysql/binchgrp -R mysql /usr/local/mysql/binchgrp -R mysql /var/lib/mysqlchmod 777 /var/lib/mysqlchown -R root /var/lib/mysql/mysqlchgrp -R mysql /var/lib/mysql/mysqlchmod 777 /var/lib/mysql/mysqlchown -R root /var/lib/mysql/mysql/*chgrp -R mysql /var/lib/mysql/mysql/*chmod 777 /var/lib/mysql/mysql/*chmod 777 /usr/local/mysql/lib/mysql/libmysqlclient.a做完上面的步骤，然后把你编译目录的一个脚本COPY过去cp support-files/mysql.server /etc/rc.d/init.d/mysqldchkconfig –add mysqld用ntsysv设置使mysql每次启动都能自动运行。好了，至此mysql安装完毕，你可以这样起动你的mysql服务/etc/rc.d/init.d/mysqld start下面这步比较关键，ln -s /usr/local/mysql/lib/mysql /usr/lib/mysqlln -s /usr/local/mysql/include/mysql /usr/include/mysql大家可以不做这步，大可以在编译其他软件的时候自定义myslq的库文件路径，但我还是喜欢把库文件链接到默认的位置，这样你在编译类似PHP，Vpopmail等软件时可以不用指定mysql的库文件地址。3、安装Apachetar zvxf httpd-2.2.13.tar.gzcd httpd-2.2.13修改src/include/httpd.h 增大最大线程数#define HARD_SERVER_LIMIT 256改成#define HARD_SERVER_LIMIT 2560保存退出编译apache./configure –prefix=/usr/local/apache –enable-module=so –enable-module=rewrite –enable-shared=max –htdocsdir=/var/www &&makemake install#这里我们通过enable-module参数告诉设置脚本，我们需要启动so和rewrite模块，so模块是用来提DSO支持的apache核心模块，而rewrite模块则是用意实现地址重写的模块，由于rewrite模块需要DBM支持，如果在初次安装时没有编译进apache，以后需要用到时需要重新编译整个apache才可以实现。为此除非你可以确定以后不会用到rewrite模块，否则还是建议你在第一次编译的时候把rewrite模块编译好。enable-shared=max 这个参数的作用时编译apache时，把除了so以外的所有apache的标准模块都编译成DSO模块。而不是编译进apache核心内。好了安装apache很简单的哦，启动apache看看/usr/local/apache/bin/apachectl start然后 通过浏览器查看http://youhost/，如果正常则说明安装成功。4、安装PHPtar zvxf php-5.2.10.tar.bz2cd php-5.2.10（1）./configure \–prefix=/usr/local/php \–with-mysql=/usr/local/mysql \–enable-force-cgi-redirect \–with-freetype-dir=/usr \–with-png-dir=/usr \–with-gd –enable-gd-native-ttf \–with-ttf \–with-gdbm \–with-gettext \–with-iconv \–with-jpeg-dir=/usr \–with-png \–with-zlib \–with-xml \–enable-calendar \–with-apxs=/usr/local/apache/bin/apxs（2）make（3）make install#我这里由于服务器需要用到GD库，所以加了一些支持GD的编译参数，GD直接用了redhat自带的GD库，大家没有安装的话可以从安装盘安装，注意除了安装GD以外，还要安装libjpeg，libpng等库文件。另外–with-mysql=/usr/local/mysql指向你安装mysql的路径。–with-apxs指向apache的apxs文件的路径。vi /usr/local/apache/conf/httpd.conf查找在此范围添加AddType application/x-httpd-php .phpAddType application/x-httpd-php-source .phps然CPOPY PHP的配置文件cp ../php-5.2.10/php.ini.dist /usr/local/php/lib/php.ini修改php.ini文件register_globals = Onok！重新启动一下apache服务器/usr/local/apache/bin/apachectl restart然后写个php测试页info.php:内容如下<?phpphpinfo();?>正常的话，应该能看到php的信息了，恭喜你的Apche+Mysql+PHP安装成功。

ASP.NET 缓存 方法和最佳实践 在 ASP.NET 提供的许多特性中，缓存支持无疑是我最欣赏的特性，我这样说当然是有充分理由的。相比 ASP.NET 的所有其他特性，缓存对应用程序的性能具有最大的潜在影响，利用缓存和其他机制，ASP.NET 开发人员可以接受使用开销很大的控件（例如，DataGrid）构建站点时的额外开销，而不必担心性能会受到太大的影响。为了在应用程序中最大程度地利用缓存，您应该考虑在所有程序级别上都实现缓存的方法。Steve 的缓存提示尽早缓存；经常缓存您应该在应用程序的每一层都实现缓存。向数据层、业务逻辑层、UI 或输出层添加缓存支持。内存现在非常便宜 — 因此，通过以智能的方式在整个应用程序中实现缓存，可以获得很大的性能提高。缓存可以掩盖许多过失缓存是一种无需大量时间和分析就可以获得“足够良好的”性能的方法。这里再次强调，内存现在非常便宜，因此，如果您能通过将输出缓存 30 秒，而不是花上一整天甚至一周的时间尝试优化代码或数据库就可以获得所需的性能，您肯定会选择缓存解决方案（假设可以接受 30 秒的旧数据）。缓存正是那些利用 20% 付出获得 80% 回报的特性之一，因此，要提高性能，应该首先想到缓存。不过，如果设计很糟糕，最终却有可能带来不良的后果，因此，您当然也应该尽量正确地设计应用程序。但如果您只是需要立即获得足够高的性能，缓存就是您的最佳选择，您可以在以后有时间的时候再尽快重新设计应用程序。页面级输出缓存作为最简单的缓存形式，输出缓存只是在内存中保留为响应请求而发送的 HTML 的副本。其后再有请求时将提供缓存的输出，直到缓存到期，这样，性能有可能得到很大的提高（取决于需要多少开销来创建原始页面输出 – 发送缓存的输出总是很快，并且比较稳定）。实现要实现页面输出缓存，只要将一条 OutputCache 指令添加到页面即可。<%@ OutputCache Duration="60" VaryByParam="*" %>如同其他页面指令一样，该指令应该出现在 ASPX 页面的顶部，即在任何输出之前。它支持五个属性（或参数），其中两个是必需的。 Duration 必需属性。页面应该被缓存的时间，以秒为单位。必须是正整数。 Location 指定应该对输出进行缓存的位置。如果要指定该参数，则必须是下列选项之一：Any、Client、Downstream、None、Server 或 ServerAndClient。 VaryByParam 必需属性。Request 中变量的名称，这些变量名应该产生单独的缓存条目。”none” 表示没有变动。”*” 可用于为每个不同的变量数组创建新的缓存条目。变量之间用 “;” 进行分隔。 VaryByHeader 基于指定的标头中的变动改变缓存条目。 VaryByCustom 允许在 global.asax 中指定自定义变动（例如，”Browser”）。 利用必需的 Duration 和 VaryByParam 选项的组合可以处理大多数情况。例如，如果您的产品目录允许用户基于 categoryID 和页变量查看目录页，您可以用参数值为 “categoryID;page” 的 VaryByParam 将产品目录缓存一段时间（如果产品不是随时都在改变，一小时还是可以接受的，因此，持续时间是 3600 秒）。这将为每个种类的每个目录页创建单独的缓存条目。每个条目从其第一个请求算起将维持一个小时。VaryByHeader 和 VaryByCustom 主要用于根据访问页面的客户端对页面的外观或内容进行自定义。同一个 URL 可能需要同时为浏览器和移动电话客户端呈现输出，因此，需要针对不同的客户端缓存不同的内容版本。或者，页面有可能已经针对 IE 进行了优化，但需要能针对 Netscape 或 Opera 完全降低优化（而不仅仅是破坏页面）。后一个例子非常普遍，我们将提供一个说明如何实现此目标的示例：示例： VaryByCustom用于支持浏览器自定义为了使每个浏览器都具有单独的缓存条目，VaryByCustom 的值可以设置为 “browser”。此功能已经内置在缓存模块中，并且将针对每个浏览器名称和主要版本插入单独的页面缓存版本。<%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser" %>片段缓存，用户控件输出缓存缓存整个页面通常并不可行，因为页面的某些部分是针对用户定制的。不过，页面的其他部分是整个应用程序共有的。这些部分最适合使用片段缓存和用户控件进行缓存。菜单和其他布局元素，尤其是那些从数据源动态生成的元素，也应该用这种方法进行缓存。如果需要，可以将缓存的控件配置为基于对其控件（或其他属性）的更改或由页面级输出缓存支持的任何其他变动进行改变。使用同一组控件的几百个页面还可以共享那些控件的缓存条目，而不是为每个页面保留单独的缓存版本。实现片段缓存使用的语法与页面级输出缓存一样，但其应用于用户控件（.ascx 文件）而不是 Web 窗体（.aspx 文件）。除了 Location 属性，对于 OutputCache 在 Web 窗体上支持的所有属性，用户控件也同样支持。用户控件还支持名为 VaryByControl 的 OutputCache 属性，该属性将根据用户控件（通常是页面上的控件，例如，DropDownList）的成员的值改变该控件的缓存。如果指定了 VaryByControl，可以省略 VaryByParam。最后，在默认情况下，对每个页面上的每个用户控件都单独进行缓存。不过，如果一个用户控件不随应用程序中的页面改变，并且在所有页面都使用相同的名称，则可以应用 Shared=”true” 参数，该参数将使用户控件的缓存版本供所有引用该控件的页面使用。示例<%@ OutputCache Duration="60" VaryByParam="*" %>该示例将缓存用户控件 60 秒，并且将针对查询字符串的每个变动、针对此控件所在的每个页面创建单独的缓存条目。<%@ OutputCache Duration="60" VaryByParam="none" VaryByControl="CategoryDropDownList" %>该示例将缓存用户控件 60 秒，并且将针对 CategoryDropDownList 控件的每个不同的值、针对此控件所在的每个页面创建单独的缓存条目。<%@ OutputCache Duration="60" VaryByParam="none" VaryByCustom="browser" Shared="true %>最后，该示例将缓存用户控件 60 秒，并且将针对每个浏览器名称和主要版本创建一个缓存条目。然后，每个浏览器的缓存条目将由引用此用户控件的所有页面共享（只要所有页面都用相同的 ID 引用该控件即可）。缓存 API，使用 Cache 对象页面级和用户控件级输出缓存的确是一种可以迅速而简便地提高站点性能的方法，但是在 ASP.NET 中，缓存的真正灵活性和强大功能是通过 Cache 对象提供的。使用 Cache 对象，您可以存储任何可序列化的数据对象，基于一个或多个依赖项的组合来控制缓存条目到期的方式。这些依赖项可以包括自从项被缓存后经过的时间、自从项上次被访问后经过的时间、对文件和/或文件夹的更改以及对其他缓存项的更改，在略作处理后还可以包括对数据库中特定表的更改。在 Cache中存储数据在 Cache 中存储数据的最简单的方法就是使用一个键为其赋值，就像 HashTable 或 Dictionary 对象一样：Cache["key"] = “value”;这种做法将在缓存中存储项，同时不带任何依赖项，因此它不会到期，除非缓存引擎为了给其他缓存数据提供空间而将其删除。要包括特定的缓存依赖项，可使用 Add() 或 Insert() 方法。其中每个方法都有几个重载。Add() 和 Insert() 之间的唯一区别是，Add() 返回对已缓存对象的引用，而 Insert() 没有返回值（在 C# 中为空，在 VB 中为 Sub）。示例Cache.Insert("key", myXMLFileData, new System.Web.Caching.CacheDependency(Server.MapPath("users.xml")));该示例可将文件中的 xml 数据插入缓存，无需在以后请求时从文件读取。 CacheDependency 的作用是确保缓存在文件更改后立即到期，以便可以从文件中提取最新数据，重新进行缓存。如果缓存的数据来自若干个文件，还可以指定一个文件名的数组。Cache.Insert("dependentkey", myDependentData, new System.Web.Caching.CacheDependency(new string[] {}, new string[] {"key"}));该示例可插入键值为 “key” 的第二个数据块（取决于是否存在第一个数据块）。如果缓存中不存在名为 “key” 的键，或者如果与该键相关联的项已到期或被更新，则 “dependentkey” 的缓存条目将到期。Cache.Insert("key", myTimeSensitiveData, null, DateTime.Now.AddMinutes(1), TimeSpan.Zero);绝对到期：此示例将对受时间影响的数据缓存一分钟，一分钟过后，缓存将到期。注意，绝对到期和滑动到期（见下文）不能一起使用。Cache.Insert("key", myFrequentlyAccessedData, null, System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(1));滑动到期：此示例将缓存一些频繁使用的数据。数据将在缓存中一直保留下去，除非数据未被引用的时间达到了一分钟。注意，滑动到期和绝对到期不能一起使用。更多选项除了上面提到的依赖项，我们还可以指定项的优先级（依次为 low、high、NotRemovable，它们是在 System.Web.Caching.CacheItemPriority 枚举中定义的）以及当缓存中的项到期时调用的 CacheItemRemovedCallback 函数。大多数时候，默认的优先级已经足够了 — 缓存引擎可以正常完成任务并处理缓存的内存管理。CacheItemRemovedCallback 选项考虑到一些很有趣的可能性，但实际上它很少使用。不过，为了说明该方法，我将提供它的一个使用示例：CacheItemRemovedCallback示例System.Web.Caching.CacheItemRemovedCallback callback = new System.Web.Caching.CacheItemRemovedCallback (OnRemove); Cache.Insert("key",myFile,null, System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.Zero, System.Web.Caching.CacheItemPriority.Default, callback); . . . public static void OnRemove(string key, object cacheItem, System.Web.Caching.CacheItemRemovedReason reason) { AppendLog("The cached value with key '" + key + "' was removed from the cache. Reason: " + reason.ToString()); }该示例将使用AppendLog()方法（这里不讨论该方法，请参阅 Writing Entries to Event Logs）中定义的任何逻辑来记录缓存中的数据到期的原因。通过在从缓存中删除项时记录这些项并记录删除的原因，您可以确定是否在有效地使用缓存或者您是否可能需要增加服务器上的内存。注意，callback 是一个静态（在 VB 中为 Shared）方法，建议使用该方法的原因是，如果不使用它，保存回调函数的类的实例将保留在内存中，以支持回调（对 static/Shared 方法则没有必要）。该特性有一个潜在的用处 — 在后台刷新缓存的数据，这样用户永远都不必等待数据被填充，但数据始终保持相对较新的状态。但实际上，此特性并不适用于当前版本的缓存 API，因为在从缓存中删除缓存的项之前，不触发或不完成回调。因此，用户将频繁地发出尝试访问缓存值的请求，然后发现缓存值为空，不得不等待缓存值的重新填充。我希望在未来的 ASP.NET 版本中看到一个附加的回调，可以称为 CachedItemExpiredButNotRemovedCallback，如果定义了该回调，则必须在删除缓存项之前完成执行。缓存数据引用模式每当我们尝试访问缓存中的数据时，都应该考虑到一种情况，那就是数据可能已经不在缓存中了。因此，下面的模式应该普遍适用于您对缓存的数据的访问。在这种情况下，我们假定已缓存的数据是一个数据表。public DataTable GetCustomers(bool BypassCache) { string cacheKey = "CustomersDataTable"; object cacheItem = Cache[cacheKey] as DataTable; if((BypassCache) || (cacheItem == null)) { cacheItem = GetCustomersFromDataSource(); Cache.Insert(cacheKey, cacheItem, null, DateTime.Now.AddSeconds(GetCacheSecondsFromConfig(cacheKey), TimeSpan.Zero); } return (DataTable)cacheItem; }关于此模式，有以下几点需要注意： 某些值（例如，cacheKey、cacheItem 和缓存持续时间）是一次定义的，并且只定义一次。 可以根据需要跳过缓存 — 例如，当注册一个新客户并重定向到客户列表后，最好的做法可能就是跳过缓存，用最新数据重新填充缓存，该数据包括新插入的客户。 缓存只能访问一次。这种做法可以提高性能，并确保不会发生 NullReferenceExceptions，因为该项在第一次被检查时是存在的，但第二次检查之前就已经到期了。 该模式使用强类型检查。C# 中的 “as” 运算符尝试将对象转换为类型，如果失败或该对象为空，则只返回 null（空）。 持续时间存储在配置文件中。在理想的情况下，所有的缓存依赖项（无论是基于文件的，或是基于时间的，还是其他类型的依赖项）都应该存储在配置文件中，这样就可以进行更改并轻松地测量性能。我还建议您指定默认缓存持续时间，而且，如果没有为所使用的 cacheKey 指定持续时间，就让 GetCacheSecondsFromConfig() 方法使用该默认持续时间。 相关的代码示例是一个 helper 类，它将处理上述所有情况，但允许通过一行或两行代码访问缓存的数据。请下载 CacheDemos.msi。小结缓存可以使应用程序的性能得到很大的提高，因此在设计应用程序以及对应用程序进行性能测试时应该予以考虑。应用程序总会或多或少地受益于缓存，当然有些应用程序比其他应用程序更适合使用缓存。对 ASP.NET 提供的缓存选项的深刻理解是任何 ASP.NET 开发人员应该掌握的重要技巧。Steven A. Smith 作为 Microsoft ASP.NET最有价值的专家，是 ASPAlliance.com 的总裁，也是该公司的所有者。他还是 ASPSmith Ltd（一家以 .NET 为中心的培训公司）的所有者和首席讲师。他撰写了两本书 — ASP.NET Developer’s Cookbook 和 ASP.NET By Example，并且在 MSDN? 杂志和 AspNetPRO 杂志上发表文章。Steve 每年都要在几个会议上进行演讲，是 INETA Speaker’s Bureau 的成员。Steve 拥有工商管理硕士学位和计算机科学工程的理学学士学位。如果希望与 Steve 联系，请将电子邮件发送至 ssmith@aspalliance.com。

Database Optimize patterns Most of websites and enterprise application rely on the database backing them to store the application and customer data. So at some point the database could be the main performance and scalability bottleneck for your system performance, so I ‘m here today to cure this!Database supporters and resisters:Database supporters: MySQL, SQL Server, and PostgreSQL:MySQL, SQL Server, PostgreSQL, and others is hard competitors, everyone have different philosophy, and features.For example, SQL Server have rich features such as: support UTF16 in the data types, triggers, roles and policies, and integration with .NET, etc. MySQL: Free and open source, many database engines. PostgreSQL: Free and open source, support object-oriented data model.What about the performance?The Database performance is important. In the real and trusted performance benchmark: MySQL faster than SQL Server, and PostgreSQL have good performance better than SQL Server, and almost like MySQL. Also PostgreSQL, MySQL have small footprint, and consume small system resource.Database resisters: HBase, MongoDB, Redis, and others:Does all application really need databases backing them?I believe there is no option can fit in all situations, so not all applications need database. The golden wisdom (in my opinion) said: Every challenge has its own solution.There are many scenario will agreed with Database resisters, such as: Web search engine, Caching, File sharing, etc. In the other hand there are a lot of scenarios agreed with Database supporters, such as: ERP, CRM, E-Commerce, etc.Tiny URL services for example, shouldn’t use Database at all because it’s require very simple needs map a small/tiny URL to the real/big URL. But what we can use beside or instead of Databases?There are a lot of tools that fallowing CAP, BASE model, instead of ACID model. CAP model is about:* Consistency – your data is correct all the time. What you write is what you read.* Availability – you can read and write and write your data all the time.* Partition Tolerance – if one or more nodes fails the system still works and becomes consistent when the system comes on-line.For example in any in-memory or in-disk caching system you will never need all the Database features. You just need CAP like system. Today there are a lot of Documents, and key-value based store systems, such as:* MongoDB Document oriented* CouchDB Document oriented (JSON)* Redis Key-value oriented* Tokyo Cabinet Key-value oriented* Memcached in-memory, Key-value orientedThe above list can work in many scenarios, and they provide good performance more than the Databases, and most of them support distributed, partitions, and they also provide good fault tolerance algorithm.I know after all this there are still people say; Why CAP model or key-value store system, the database is good?The Database is often a performance- and scalability limiting factor in most types of applications, the reality is that relational databases have not changed much in the last 30 years, and for a lot of purposes using a database is akin to running an interstellar spaceship while having an old Volkswagen engine in the engine room!So the first lesson today is: Consider use Key-value store system depend on your needs.Database Optimizing pattern:What to store into the Database?lot of people in our industry think about the Database as fundamental, default, primitive disk based store system, but this is wrong there are too many ways to store the data; beside that you shouldn’t store anything into the Database. In other word, don’t store non-relational data in relational data model.For example if you design a photo sharing website, you shouldn’t store the thumbnails photos into the Database because simply when some user search the brewer will send a lot of requests to view this photos, and making a lot of DB connections is not good, beside this the DBMS will make this process heavy because the DBMS is complex system by nature.So you should think twice before use the Database to store BLOB data.Field data types:In any DBMS you can found many kind of data types, such as: Date, Time, DateTime, Text, BLOB, VarChar, NVarCar (in SQL Server), and so on. If you choice the right data type this will make the database use lower disks space, and the insert/retrieve will run faster. But why I choice think about it? The Database by nature resides in disks and such disks are slow, so if you minimize the size of the stored data this will improve the write and read time. For example don’t use NVarChar data type except if you really need 16 bits Unicode (UTF 16). Also be watchful when you choice Text, NText, BLOB data type because mostly it will store in another location and the row will just hold the a reference to data position, so when you retrieve the data the DBMS will do a lot of seeks.The primary key and the indexes:We usually use it to optimize the retrieve, insert, update, and delete operations in the tables. Create a primary key on each table you create and unless you are really knowledgeable enough to figure out a better plan, make it the clustered index.It’s important to minimize the primary field size and make the inserting always at the end of the table (i.e. make the value of the primary key field always increasing); I suggest use integer and auto increment in the primary key field if it’s possible.To start with create your indexes; you need to plan an indexing strategy at the same time as you plan and design the database. First, and most important, is the clustered index (Primary key). As a rule, every table in an online transactional processing (OLTP) system should get a clustered index. You can only put one clustered index on a given table, so the proper selection of exactly what column or columns to place it on is extremely important.It makes sense to leave the cluster on the primary key if that primary key provides the natural access path, the most common field used to either search the table or relate the table to another.Changing the parameters slightly, if the access path is mostly through another column, says Company Name, this may make a more appropriate clustered index. Another situation is when the table is no longer at the top of the chain, but somewhere in the middle and the most likely avenue of selection for the data is going to come through the foreign key to a parent table. Then the foreign key column becomes a good candidate for the clustered index. A further wrinkle could be added by needing to get the related data in this child table, but based on a date. This would result in a clustered index composed of two columns: the foreign key and the date. As you can see, in a few sentences a number of options were laid out. You need to think this through as you design the system.You may also identify, either during design, testing or monitoring the production system, that other indexes are needed. While multiple indexes on any given table may be needed, you need to keep in mind that each index adds overhead to the system because these values have to be maintained as the data gets modified, which includes inserts, updates and deletes. Further, since indexes are stored by pointing to the clustered index (one of the many reasons you need a clustered index on the table) changes to the clustered index can result in a cascade through all the other indexes on a table. Because of all this, while indexes are good and necessary, restraint must be exercised in their application & use.Data retrieve, SP’s, and Ad-hoc queries:When you submit Ad-hoc query to the DBMS, a number of processes on the server go to work on that query. The purpose of all these processes is to manage the system such that it will provide your data back to you, or store it, in as timely a manner as possible, whilst maintaining the integrity of the data. The processes actually take a time, some time it’s take long time depend on your query complexity.So I suggest using SP (stored procedure) because most of those steps happen statically at compile time (i.e. creation time). For example you can in .NET – LINQ to SQL to import SPs and call it, and using a few changes you can also enforce the LINQ to SQL to use SPs in any insert, update, and delete operation for better performance.Minimize the Ad-hoc queries will make you gain some performance but we can’t enforce the developers to forget this important feature. Beside create SP’s for the complex queries and the usually insert, update, delete operations; I suggest monitoring and tuning the Ad-hoc queries execute plans at stabilization and testing stage.In general try to do the following:- It’s important to return/select the columns and rows you need only.- Avid using Like operation because it’s mostly require full table scan.- Avoid NOT IN, instead use a left outer join – even though it’s often easier to visualize the NOT IN.- Consider use set nocount on at the top of each SP (and set nocount off) at the bottom.- Avid Long-Running, and the distributed transactions.Caching:Caching is fundamental thing in reading intensive application, also caching is important in writing intensive application. If your DBMS support caching system, such as Query Caching in MySQL I suggest to turn it on.Caching the not rapidly changing data such as: Logged-in user’s roles, top most posts, configuration, and Categories into the client/application server memory also is important to minimize the traveling to the server.

网站架构方案应包括哪些方面 网站架构方案应包括如下几个方面：网络管理系统：包括网络结构、服务器架构与有关硬件设备部署的整合设计。应用管理系统：包括web服务、数据库服务、应用服务、邮件服务的整合设计；业务管理系统：包括网站内容管理、社区论坛、资源管理、视频点播、短信娱乐、广告管理等业务内容的整合设计；网络安全系统：包括数据存储备份恢复、系统监控、流量分析、应用审计等网络安全的整合设计；文档目录可以划分为：一、概　　述 5二、需求分析 52.1 异构系统 62.2 异构应用 82.3 异构数据 82.4 网站结构 92.5 内容海量 102.6 内容深度 102.7 服务深度 102.8 发布系统 112.9 网络安全 112.10 信息安全 11三、方案整体规划 113．1设计目标 113．2实施规划 12四、网络解决方案 134.1 拓扑结构图 144.2 硬件选型、分布与规划 144.2.1 数据库服务器 144.2.2 web发布服务器 154.2.3 cgi服务器 154.2.4 内容管理发布服务器 154.2.5 内容管理生成服务器 154.2.6 数据存储设备 154.2.7 安全设备 164.2.8 防病毒 164.2.9 原有服务器与置换服务器比较 164.3 新增硬件配置清单 18五、软件解决方案 185.1系统架构 185.2系统软件整合 195.3 网站内容管理系统 205.3.1网站内容管理系统介绍 205.3.2网站后台管理系统 215.3.3网站采编应用系统 225.3.4网站调查投票子系统 255.3.5站点内容全文检索子系统 265.3.6文章评论系统 265.3.7网站论坛、聊天室子系统 265.3.8网站会员认证管理子系统 315.3.9网站广告发布子系统 32六、网站音视频管理系统 326.1用户需求分析 326.2 产品概述 336.3技术特点 336.4基础构架和运行环境 346.5 功能描述 344.3.6 拓扑结构图 394.3.7音视频系统组成 39七、项目实施进度安排 427.1项目领导小组 427.2 项目实施小组 427.3质量监督小组 437.4系统集成实施进度计划及工作日程表 43八、培训、支持和服务 448.1 培训服务 448.1.1 基本操作培训 448.1.2 系统管理培训 448.1.3 培训安排 458.1.4 培训内容 458.2 技术支持服务 458.2.1 硬件平台技术支持 458.2.2 应用软件平台技术支持 458.3 售后服务 46九、小结 46附录 47硬件产品说明 47hp dl 580 47hp dl 380 49

网站架构设计原则-小规模低性能低流量 到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。拥抱熟知的技术动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。架构层次清晰化起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。Web Server <–> (AppServer)<–>Cache(eg. Memcached)<–>DB层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。数据冗余? 有必要很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。前端优化很重要因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。功能增加要谨慎不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。从开始考虑性能这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。好架构不是设计出来的这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。作者: Fenng 网址: http://www.dbanotes.net/arch/small_site_arch.html

Apache的HTTP压缩GZIP优化配置 HTTP压缩对于纯文本内容可压缩至原大小的40％一下，从而提供60％以上的数据传输节约，虽然WEB服务器会因为压缩导致CPU占用的略微上升，但是 可以节约大量用于传输的网络IO。对于数据压缩带来的用户浏览速度提升（让页面符合8秒定律），这点总体负载5%-10%上升是非常值得的。毕竟通过数据 压缩会比通过不规范的HTML代码优化要方便得多。mod_gzip的安装：修改Makefile中的 apxs路径：然后make make install配置：mod_gzip+mod_phpLoadModule gzip_module modules/mod_gzip.so…AddModule mod_gzip.c…<IfModule mod_gzip.c>mod_gzip_on Yesmod_gzip_minimum_file_size 1000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.htm$mod_gzip_item_include file \.html$mod_gzip_item_include file \.php$mod_gzip_item_include file \.php3$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directory# mod_gzip的临时工作目录: mkdir /tmp/mod_gzip; chmod -R 777 mod_gzipmod_gzip_temp_dir /tmp/mod_gzipmod_gzip_dechunk Yesmod_gzip_keep_workfiles No</IfModule> mod_gzip和mod_php的配合：不要让mod_gzip和mod_php使用同一个临时目录，php_session存放目录可以通过 php.ini设置到session.save_path = /tmp/php_sessmod_gzip和Resin配合：从resin的邮件列表上查到的：要让mod_gzip在mod_caucho后加载，否则mod_gzip不起作用…othr modulesAddModule mod_so.cAddModule mod_caucho.c#notice: mod_gzip must load after mod_cauchoAddModule mod_gzip.cAddModule mod_expires.c…配置：mod_gzip + resin<IFModule mod_gzip.c>mod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler caucho-request</IFModule>配置：mod_gzip + mod_proxy 反相代理加速并压缩 IIS注意要增加缺省的文件编码属性映射。AddType text/html .aspAddType text/html .aspx<IFModule mod_gzip.c>AddType text/html .aspAddType text/html .aspxmod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include file \.asp$mod_gzip_item_include file \.aspx$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler proxy-server</IFModule>参考资料：mod_gzip的下载http://sourceforge.net/projects/mod-gzip/mod_gzip项目首页http://www.schroepl.net/projekte/mod_gzip/Apache2 中的mod_deflate：压缩率比mod_gzip略低http://httpd.apache.org/docs-2.0/mod/mod_deflate.html模块化安装Apachehttp://www.chedong.com/tech/apache_install.html作者：车东 发表于：http://www.chedong.com/tech/compress.html

.Net架构网站遇到大表的处理办法 最近做的web2.0网站本身遇到一个大表(2000万rows左右)，因为对于performance，web本身可用性的考虑，必须想办法boost perf.这种情况应该都用partition来搞定了，这也符合分治等算法的思想，想办法降低问题本身的复杂度，然后在一个一个解决。mysql中一般到100万操作就有点麻烦了，index要好好的做。这里还遇到了一个文本检索问题，MyIASM storage engine里面有个full-text index，但是不知道它对于中文支持如何，而且不清楚它是怎么分词的，不大清楚后台逻辑，Mysql这种index limitation很多，很难scalable，所以基本上直接考虑用search engine那一套。直接上了lucene+solr+solrsharp.小表like还可以忽悠忽悠，大点就慢的如老牛……Partition通过了解发现解决方案倒是不少，以前做过了解过这方面知识储备。对hivedb，hscale等都没想过要尝试，发现。net在使用open source很多都不是很舒服。最开始尝试了mysql partition，一开始听起来方法这种方案很Perfect!是mysql解决horizontal partioning的很好方案，等document看完了，发现5.1版本的partion limitation太多了，只能适合某些特性的场景，例如按照用户id做split;普通那种非unique key，primary key是很难搞定的，简单方法是给表本身不添加任何主键，自己来实现主键生成机制。这样仿佛可以了，但是通过explain partitions来做下analysis，发现结果定位具体parition不好，这就很难降低IO本身的高成本了。没有通过具体测试不知道可能是 explain partition本身不准确原因还是……mysql partition还有一个很大的弊病，就是很难跨机器，当然如何能够把Mysql存储做成分布式，也还好，但是这个技术代价都上了不少档次，risk过高了，只能算是下下策了，备用好了。这些不爽的地方导致偶们直接抛弃了这种方案，直接用手工切分来搞定这种问题，我想这也是大部分这种需求的常见 solution把。手工切分本身技术还比较简单，就是要考虑表的编码，管理等多个方面，以及如何快速定位到可能的partition，这些在设计方面都应该注意了。而且对于多partitions的结果，应该使用多线程等并发，同步技术来提高perf.这里的partition还做到支持对某一个partition做进一步切分，这样切分到每一个partition块尽量表中数据在50万以下，这样加上db index，速度应该能够满足一定的需求的，手工切分本身很容易scale out，可以把表放在不同的机器上等等load balance方法来scale.回想感觉最有意思还是表编码自身的考虑有点意思，我很大程度的灵感来源于IP地址的划分，因为这个表自身增长速度会很慢，所以采用unsigned int来搞定，43亿来表示2000万还是小意思嘛。我主要是通过前缀+长度来定义表的标识。1，2，3前缀可以让给数据比较密集的表，因为它们可以支持10位，其它就用9位来表示，可能有些不再切分范围内的就让他们从0开始增长把。这里partition list本身维护可以序列化到filesystem中，每次Load class时候deserialize一下，然后就是本身partition如何快速定位就需要用点复杂点的data stuctures了。出处:IT专家网论坛

YouTube架构分析 YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？转载一些相关的文章，参考学习一下原文: YouTube ArchitectureYouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。平台ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBA处理飞速增长的流量Java代码  while (true)   {     identify_and_fix_bottlenecks();     drink();     sleep();     notice_new_bottleneck();   }   while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }每天运行该循环多次Web服务器1，NetScaler用于负载均衡和静态内容缓存2，使用mod_fast_cgi运行Apache3，使用一个Python应用服务器来处理请求的路由4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面5，一般可以通过添加更多的机器来在Web层提高伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速而灵活的开发和部署8，通常每个页面服务少于100毫秒的时间9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环10，对于像加密等密集型CPU活动，使用C扩展11，对于一些开销昂贵的块使用预先生成并缓存的html12，数据库里使用行级缓存13，缓存完整的Python对象14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1，花费包括带宽，硬件和能源消耗2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有3，使用一个集群意味着：-更多的硬盘来持有内容意味着更快的速度-failover。如果一台机器出故障了，另外的机器可以继续服务-在线备份4，使用lighttpd作为Web服务器来提供视频服务：-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接5，大部分流行的内容移到CDN：-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。-调节RAID控制并注意其他低级问题-调节每台机器上的内存，不要太多也不要太少视频服务关键点1，保持简单和廉价2，保持简单网络路径，在内容和用户间不要有太多设备3，使用常用硬件，昂贵的硬件很难找到帮助文档4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具5，很好的处理随机查找(SATA，tweaks)缩略图服务1，做到高效令人惊奇的难2，每个视频大概4张缩略图，所以缩略图比视频多很多3，缩略图仅仅host在几个机器上4，持有一些小东西所遇到的问题：-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存-如此多的图片以致一台新机器只能接管24小时-重启机器需要6-10小时来缓存5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：-避免小文件问题，因为它将文件收集到一起-快，错误容忍-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable还有从DBA Notes看到过的一些：一、系统主要用Python开发，用psyco提高性能看到这个我总算知道Google为什么要收购YouTube了，都喜欢用Python嘛，本 来就有缘。用Python开发的速度显然比用C/C++、 Java等高不少，这一点eBay就比较传统，用C++/Java来写，结果落得需要几百个工程师，编译一次很久。最感兴趣的是用了psyco这个东西，所说这玩意相当于Java中的JIT编译器，通常能将Python代码的执行速度提高4倍，对于算法集中的代码甚至能提高10到100倍。二、使用lighttpd给视频内容本身提供服务时用了lighttpd，不能Apache，据说性能提高不少，但有了说这个还不好，应该用nginx，俄罗斯人写的一玩意。三、最流行的内容自己不管，放在CDN上YouTube很会享受，最常访问的内容自己的系统不管，放在运营商和Google（估计是被Google收购之后吧？）的内容分发网络上。他们自己的服务器只要处理一些不常访问的漏网之鱼就可以了，负载大大减轻。四、缩略图是最大的问题，自己搞不定，最后用Google的BigTable搞定俗话说人小鬼大绝对是有道理的，那么大的视频没什么问题，小小的缩略图却是个大问题。原来YouTube的开发人员用lighttpd，发现效果不太好，就改了代码，但效果还是不行。最后被Google收购后用了BigTable才算搞定这个问题。五、MySQL swap问题，把swap关掉就行了YouTube用MySQL存元数据，结果在Linux上swap颠簸很厉害，解决的方法也简单，把swap关掉就好了。而且人家胆子大，服务还在那里跑，这边就把它关了。六、MySQLYouTube 用MySQL也是摸着石头过河，一开始只用一个主服务器和replication，显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处 理，但这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁盘系统的选择也很有意思，最早是用10块盘做RAID 1+0，但发现盘太多了也使不上劲，所以后来改后一堆RAID 1。

Google网站架构分析 Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢？参考资料以及信息来源视频：在Google上构建大型系统 (Video: Building Large Systems at Google)Google实验室：Google文件系统 (Google Lab: The Google File System)Google实验室：MapReduce：在大规模集群上简化数据处理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters)Google实验室：BigTable: (Google Lab: BigTable.)视频：BigTable: 一个分布式的结构化存储系统 (Video: BigTable: A Distributed Structured Storage System.)Google实验室：松散耦合的分布式系统的 Chubby Lock服务 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.)Google是如何工作的 作者 David Carr发表于Baseline杂志 (How Google Works by David Carr in Baseline Magazine.)Google实验室：翻译数据：使用Sawzall并行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.)可伸缩性大会上Dare Obasonjo的笔记 (Dare Obasonjo’s Notes on the scalability conference.)平台• Linux• 多种不同的语言： Python, Java, C++数据揭秘目前的情形：• 2006年估计有450,000个价格便宜的商用服务器• 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。• 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。• 目前在Google有6000个 MapReduce应用，并且每个月有几百个新的应用正在出现。架构的层次Google把他们的基础设施架构描述为三个层次栈：• 产品：检索，广告，电子邮件，地图，视频，聊天，博客• 分布式系统基础设施：GFS, MapReduce, 以及BigTable。• 计算平台：很多不同数据中心的很多机器• 确保公司员工容易低成本配置。• 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。使用GFS（Google文件系统）的可靠存储机制• 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。• Google文件系统- 大的分布式日志结构化文件系统，里面有大量数据• 为什么不用其他的而非要构建一个文件系统呢？因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要：- 通过数据中心的高可靠性- 对于几千个网络节点的可伸缩性- 大的读写带宽需求- 支持十亿字节大的数据块- 高效的通过节点减少瓶颈的分布式操作• 系统有主服务器和分块服务器（chunk servers）- 主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。• 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。• 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。使用MapReduce对数据做一些事情• 既然你有了一个好的存储系统，你怎样使用如此多的数据呢？假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。• MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。• 为什么使用MapReduce呢？- 在大量机器上分割任务的极佳方式- 处理机器故障- 在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。- 计算可以自动地更加靠近IO源。• MapReduce 系统有三个不同类型的服务器。- 主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。- 映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。- 化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。• 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。- 步骤如下：GFS -> Map -> Shuffle -> Reduction -> 把结果存回GFS- 在MapReduce 里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。- Shuffling 聚合键的类型- 化简把所有的键值对加起来产生最后的结果。• Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。等等。• 程序可以很小。可以小到20到50行的代码。• 一个问题是stragglers。Stragglers是一种比其他都要慢的计算。Stragglers会发生是因为慢的IO（比如一个糟糕的控制器）或者从一个临时的CPU尖峰信号。解决办法是运行多个同样的计算，当一个完成时就销毁所有其他的计算。• 在映射和化简之间转换的数据被压缩。这样做是因为服务器不受CPU约束，花时间在数据的压缩和解压缩上还是有意义的，可以节省花在带宽和I/O上的时间。在BigTable中存储结构化数据• BigTable 是一个大型的容错和自我管理系统，包括太（万亿）字节的内存和皮字节的内存。它每秒能够处理几百万的读写。• BigTable是一个构建在GFS之上的分布式散列机制。它不是一个关系数据库。它不支持联结或者SQL类型查询。• 它提供查找机制，可以通过键来访问结构化的数据。GFS存储不透明数据和许多应用所需的结构化数据。• 商业化数据不能伸缩到这个层次，它们不在1000个机器上工作。• 通过控制它们自己的低层次存储系统，Google得到更多的控制和有力的工具来改进它们的系统。例如，如果它们想要使得分布数据操作更简单的特征，它们可以在里面构建。• 当系统运行的时候，机器可以增加和减少，而整个系统还会正常工作。• 每个数据条存储在一个可以使用行键，列键或者时间邮票访问的单元中。• 每行存储在一个或者更多个tablet中。一个tablet是数据形式的64KB块的序列叫做SSTable。• BigTable 有三个不同类型的服务器：- 主服务器分配tablet到tablet服务器中。它们跟踪的位置，当需要时还会重新分配任务。- Tablet 服务器处理tablet的读写请求。当tablet超过规模限制（通常是100MB – 200MB）时，它们将它分开。当一个tablet服务器出故障时，会有100个tablet服务器每个捡起一个新的tablet，所以系统就恢复了。• 一个位置组可以被用作与几比特的数据相关的物理存储，为了有一个更好的参考位置。• Tablets尽可能在RAM里被缓存。硬件• 当你有很多个机器时，你如何构建它们以使花费代价最小电能消耗最少呢？• 使用超便宜的商业硬件，拼命利用它们在上面构建软件。• 增加 1,000-fold 计算机电力，如果你使用容易出事故的基础设施而不是构建在高度可靠的部件之上的基础设施时，可以有33倍更低的花费。你必须使用这一策略在不可靠之上构建可靠。• Linux，内部的架构设计，PC类主机板，低端存储。• 性能基线中每瓦的价格没有越来越好。存在着很多的电力和其他问题。• 使用混合收集和它们自己的数据中心。杂类• 很快找出改变而不是等着提问和回答。• 库是构建程序的主要方式。• 一些是以服务的形式提供的应用，比如crawling。• 基础设施处理应用程序的版本，所以它们就能够发布，不用担心破坏事情。Google未来的方向• 支持地理位置分布的集群• 为所有的数据创建单一的全局名字空间。当前数据由集群分离开的。• 更多更好的数据和计算的自动化迁移。• 解决当你用网络分割耦合大范围的复制时产生的一致性问题（例如，即使一个集群已经因为维修或是其他一些临时停电等原因而下线时，还能继续提供服务）Goolge告诉我们的经验• 基础设施是一个很有竞争性的优势。它当然是属于Google的。它们能更快更便宜地提供和生产新的网络服务，这在一定程度上是无人能比的。许多公司采取了完全不同的方式。许多公司把基础设施看做一种花销。每个组将使用完全不同的技术，而且他们很少有计划如何更经济地构建系统。Google把他们自己看做一个系统工程公司，以一个非常新的方式来看待构建软件。• 跨越多个数据中心仍是一个未解决的问题。大多数网站是一个至多是两个数据中心。如何在大量数据中心上充分分配网站，我们说，非常复杂。• 看一看Hadoop (产品)如果你没有时间来从头开始构建所有这个基础设施的话。Hadoop 是一个这里讲的一些主意的开源实现。• 一个平台方式被忽略的优点是初级开发人员可以在平台上很快自信地构建健壮的应用。如果每个项目需要创建同样的分布式基础设施轮，你将会陷入困境，因为知道如何这样做的人员相对稀少。• 协同工作并不总是废话。通过使系统中所有部件一起工作，一个改进会有助于所有的改进。改善文件系统，每个人都会立刻明显受益。如果每个项目使用一个不同的文件系统，那么就没有整个展的持续的改进。• 构建不需要降低系统性能的自我管理系统。这可以让你更容易地平衡各服务器的资源，动态增加更多空间，允许机器下线，以及更从容地处理升级。• 创建一个进化式基础设施。花时间在并行处理上会有回报的。• 不要忽视了学院。学术界有很多好的创意并没有转入生产环境里。Google所做的大部分先于艺术，不只是先于大规模配置。• 考虑压缩。当你有大量CPU可以挥霍和IO限制时，压缩是一个很好的选择。

亿万用户网站MySpace网站架构及成功秘密 《亿万用户网站MySpace的成功秘密》　◎ 文 / David F. Carr   译 / 罗小平     增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从MySpace的成长过程学到知识。用户的烦恼     Drew，是个来自达拉斯的17岁小伙子，在他的MySpace个人资料页上，可以看到他的袒胸照，看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接，另外还说自己参加了学校田径队，爱好吉他，开一辆蓝色福特野马。     不过在用户反映问题的论坛里，似乎他的火气很大。“赶紧弄好这该死的收件箱！”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息，但当他要查看一条消息时，页面却出现提示：“非常抱歉……消息错误”。     Drew的抱怨说明1.4亿用户非常重视在线交流系统，这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。     11月，MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示，MySpace当月访问量为387亿，而Yahoo是380.5亿。     显然，MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。事实上，MySpace的Web服务器和数据库经常性超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的 MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务，他们不得不在论坛抱怨不停。     尤其是最近，MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说，“难以想象，在有些时候，我们发现20%的错误日志都来自MySpace，有时候甚至达到30%以至40%……而Yahoo、 Salesforce.com和其他提供商用服务的站点，从来不会出现这样的数字。”他告诉我们，其他大型站点的日错误率一般就1%多点。    顺便提及，MySpace在2006年7月24号晚上开始了长达12小时的瘫痪，期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复，该页面提供了用Flash开发的派克人（Pac-Man）游戏。Web站点跟踪服务研究公司总经理Bill Tancer说，尤其有趣的是，MySpace瘫痪期间，访问量不降反升，“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。现 Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师，因在Web站点方面的评论而闻名的Jakob Nielsen说，MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样，他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新，但他们面对的的确是一个巨大的科学难题。”他说。     MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。     Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。背景知识MySpace logo    MySpace目前的努力方向是解决扩展性问题，但其领导人最初关注的是系统性能。3年多前，一家叫做Intermix Media（早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务）的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson，他们原来也有一家叫做ResponseBase的电子邮件营销公司，后于2002年出售给Intermix。据Brad Greenspan（Intermix前CEO）运作的一个网站披露，ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年，纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务，Intermix最后以790万美元的代价达成和解。     2003年，美国国会通过《反垃圾邮件法》（CAN-SPAM Act），意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务，“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。     当时有个叫Friendster的交友网站，Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了 Friendster在用户自我表述方面的诸多限制，并重点突出音乐（尤其是重金属乐），希望以此吸引用户。Chau使用Perl开发了最初的 MySpace版本，运行于Apache Web服务器，后台使用MySQL数据库。但它没有通过终审，因为Intermix的多数开发人员对ColdFusion（一个Web应用程序环境，最初由Allaire开发，现为Adobe所有）更为熟悉。因此，最后发布的产品采用ColdFusion开发，运行在Windows上，并使用MS SQL Server作为数据库服务器。     Chau就在那时离开了公司，将开发工作交给其他人，包括Aber Whitcomb（Intermix的技术专家，现在是MySpace技术总监）和Benedetto（MySpace现技术副总裁，大概于MySpace上线一个月后加入）。     MySpace上线的2003年，恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。财富杂志最近的一次采访中，Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时，Friendster传输一个页面需要20到30秒，而MySpace只需2到3秒。结果，Friendster用户开始转投MySpace，他们认为后者更为可靠。     今天，MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn，当然还少不了Friendster。MySpace宣称自己是“下一代门户”，强调内容的丰富多彩（如音乐、趣事和视频等）。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧，而显著位置则是以性为目的的约会，和寻找刺激派对气氛的年轻人的搜索服务。     用户注册时，需要提供个人基本信息，主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评，指其为网上性犯罪提供了温床，但对于未成年人，有些功能还是不予提供的。　　MySpace的个人资料页上表述自己的方式很多，如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲，以及视频、交友要求等。它还允许用户使用CSS（一种Web标准格式语言，用户以此可设置页面元素的字体、颜色和页面背景图像）自由设计个人页面，这也提升了人气。不过结果是五花八门 ——很多用户的页面布局粗野、颜色迷乱，进去后找不到东南西北，不忍卒读；而有些人则使用了专业设计的模版（可阅读《Too Much of a Good Thing?》第49页），页面效果很好。     在网站上线8个月后，开始有大量用户邀请朋友注册MySpace，因此用户量大增。“这就是网络的力量，这种趋势一直没有停止。”Chau说。     拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团，看到了他们在互联网用户中的机会，于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席 Rupert Murdoch最近向一个投资团透露，他认为MySpace目前是世界主要Web门户之一，如果现在出售MySpace，那么可获60亿美元——这比 2005年收购价格的10倍还多！新闻集团还惊人地宣称，MySpace在2006年7月结束的财政年度里总收入约2亿美元，而且预期在2007年度，Fox Interactive公司总收入将达到5亿美元，其中4亿来自MySpace。　　然而MySpace还在继续成长。12月份，它的注册账户达到1.4亿，而2005年11月时不过4千万。当然，这个数字并不等于真实的用户个体数，因为有些人可能有多个帐号，而且个人资料也表明有些是乐队，或者是虚构的名字，如波拉特（译者注：喜剧电影《Borat》主角），还有像Burger King（译者注：美国最大的汉堡连锁集团）这样的品牌名。     当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。　　浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。     MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。　　尽管MySpace拒绝了正式采访，但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。　　据他们讲，MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。     在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。　　虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。 里程碑一：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年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着 MySpace永远都会轻度落后于用户需求。“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。　　这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。　　垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。里程碑三：3百万账户     当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。　　另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。　　2004年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。　　但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。     另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”     因此，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中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。     最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。　　长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。     在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。　　当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。     缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。　　增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。里程碑五：2千6百万账户     2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。     更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。意外错误     如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？　　原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。　　去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量 MySpace合法用户连接时也会引起服务器反击。    “我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”　　紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等待，不能提供任何服务。     Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。     2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。       MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。“作为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。     这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给 MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承 100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。”他说。     换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。     Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站点。   “我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”