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