[转] 网站性能优化之-数据库及服务器架构...

　　转载自: http://blog.163.com/dangzhengtao@yeah/blog/static/ 7780087420098232213289/?fromdm&fromSearch&isFromSea rchEngine=yes 1、Web Server 与 DB Server 分离

　　小型网站或 B/S 项目，因同时在线人数不多，尚可让同一台物理主机，既做 Web Server，又做 DB Server。但此二者皆会占用大量的 CPU、内存、磁盘 I/O，最好让二者分别用不同的服务器主机来提供服务，以分散压力、提高负载承受能力。此外，二者若在同一网段，应尽量用内网 Private IP 进行访问，而不要用 Public IP 或主机名称。

　　基本上跑 Web 上的应用程序，不管用什么软、硬件，同时处理多个用户的 request，通常都比较消耗 CPU；但对数据库而言，CPU 就不见得会大量消耗，而是内存和磁盘 I/O 用得比 Web Server 多。因此一般建议 Web Server 用普通的 PC 即可，但要用好一点的 CPU；而 DB Server 就不能草率，应尽量买高级的服务器，并要有 RAID 5 或 6 的磁盘阵列 (硬件的 RAID，性能远比操作系统或软件做的 RAID 要好)，并有 4 GB 以上的内存。当然如果操作系统、数据库都用 64 位版本的最好，例如升级到 64 位的 SQL Server 和 64 位的 Windows Server，这样内存都可配置到 64 GB；不过要记得，太旧的 PC，一些周边硬件的 driver 可能不支持 64 位的操作系统和软件。

　　如果在线人数持续增加，则可增加多台 Web Server 和 DB Server，用「服务器集群 (cluster)」、「负载均衡 (Load balancing) 集群」、「高可用性集群 High-availability (HA)」、数据库集群，以实现更大规模的分布式布署。

　　Deployment Plan（部署规划）：

　　http://msdn.microsoft.com/zh-cn/library/ms978676.a spx

　　Three-Tiered Distribution（三级分布）(硬件、不同主机的物理级分层)：

　　http://msdn.microsoft.com/zh-cn/library/ms978694.a spx

　　Three-Layered Services Application（三层服务应用程序）(软件、代码上的分层)：

　　http://msdn.microsoft.com/zh-cn/library/ms978689.a spx

　　Tiered Distribution（分级分布）：

　　http://msdn.microsoft.com/en-gb/library/ms978701(z h-cn).aspx

　　Deployment Patterns：

　　http://msdn.microsoft.com/zh-cn/library/ms998478.a spx

　　http://msdn.microsoft.com/en-us/library/ms998478.a spx

　　-------------------------------------------------- ---

　　2、负载均衡 (Load Balance)

　　负载均衡技术发展了多年，有很多专业的服务提供商和产品可选择，基本上又可分为「软件」和「硬件」的解决方案：

　　(1) 硬件：

　　硬件的解决方案称作 Layer 4 Switch (第 4 层交换)，可将业务流分配到合适的 AP Server 进行处理，知名产品如 Alteon、F5 等。这些硬件产品虽比软件的解决方案要贵得多，但是物有所值，通常能提供远比软件优秀的性能，和方便、易于管理的 UI 界面，供管理人员快速配置。据说 Yahoo 中国当初接近 2000 台服务器时，只用三台 Alteon 就搞定了 [1]。

　　(2) 软件：

　　Apache 这一款众所皆知的 HTTP Server，其双向 Proxy / Reverse Proxy 功能，亦可达成 HTTP 负载均衡功能，但其效率算不上特别好。而另一款 HAProxy 就是纯粹用来处理负载均衡的，且具有简单的缓存功能。

　　以操作系统内置的负载均衡功能来讲，Unix 如 Sun 的 Solaris 有支持，Linux 上则有常用的 LVS (Linux Virtual Server)，而微软的 Windows Server 2003 / 2008 则有 NLB (Network LoadBalance)。

　　LVS 是利用 ipvsadm 这一个以 IP 为主的负载均衡程序，来达到让所有 TCP/IP 的通讯协议都可以进行负载均衡。由于它是 Linux Kernel 所支持，因此效率相当好，占用的 CPU 资源相当低，但缺点是 ipvsadm 无法针对 Layer 4 以上的网络 packet 数据进行分析。

　　至于 Windows Server 的 NLB，其原理是不论有多少台服务器，都全部共用一个「集群的 IP」，如下图 1 的 Active Load balancer，和下图 2 的 Virtual Server 1 (Web Server)，以及 Virtual DB Server，依照负载均衡的类型来做分配 (Active/Active、Active/Standby、...)，而用户在外面只会看到单一个 IP，至于背后有多少台服务器，用户并不需要知道 (如同 Cluster 集群和云计算的概念)。

　　

　　图 1 分布式用户 vs 服务器农场 (Web Server farm)

　　

　　图 2 红色箭头为 Failover 架构 (HA)，其功能与 Load Balance 不同

　　上图 2 中，有四台 Real Server (Web Server)，以及三台 Real DB Server，形成 Web 及 DB 的服务器集群 (Cluster)。我们看到最上方的 Virtual Server 1 本身不具备任何的数据服务 (如：.NET 代码、图片...等)，只有一个功能，就是将用户的连线 request 请求，重新导向下方的四台 Real Server。这种利用重新导向 (director) 的方式，将服务负载分布给 Real Server 的方式，就称作 Load Balance。

　　现在似乎还没有一种做法，能自动计算主机的「负载」情形，例如计算 CPU 已使用多少百分比，以决定要把 request 丢向哪一台 Real Server；现在一般都还是按照轮替 (Round-robin) 的方式，或加上一些权重的设置而已。

　　若我们在 Server 上设置 Load Balance，且要执行 ASP.NET 程序，就要注意一个问题，就是 Session 的存储位置是在哪一台 Web Server 的内存上，以避免发生有用户表单填写得比较久，等到他提交时，已经被 Windows Server 的 NLB 将工作阶段切换到另一台 Web Server 主机上了。此时就可考虑将 Session State，改存储在 SQL Server 里。

　　至于用软件做的 Load Balance 其性能如何呢？基本上用软件做的，性能一定不会是 1 + 1 = 2，但通常能提高 Availability，亦即常听到的 HA (高可用性集群 High-availability)，即 Failover 方式，如上图 2 的最上方，红色箭头左侧的 Virtual Server 2，是能够侦测 Virtual Server 1 宕机或无法提供服务时，自动将自己的 IP address 取代 Virtual Server1。因此 HA 是指提供「不会中断的服务」，而本帖讨论的 Load Balance 是指提供「能承受高度负载的服务」，两者指的不是同一件事。MIS 人员应视公司的硬件资源、成本和预算，考量是否两者都要做。

　　Load-Balanced Cluster（负载平衡群集）：

　　http://msdn.microsoft.com/zh-cn/library/ms978730.a spx

　　http://msdn.microsoft.com/en-us/library/ms978730.a spx

　　Server Clustering（服务器群集）：

　　http://msdn.microsoft.com/en-gb/library/ms998414(z h-cn).aspx

　　Installing Network Load Balancing (NLB) on Windows Server 2008：

　　http://blogs.msdn.com/clustering/archive/2008/01/0 8/7024154.aspx

　　Linux load balancing support & consulting：

　　http://www.netdigix.com/linux-loadbalancing.php

　　Load Balancing (WCF, 与本文无直接关系)：

　　http://msdn.microsoft.com/zh-cn/library/ms730128.a spx

　　http://msdn.microsoft.com/en-us/library/ms730128.a spx

　　-------------------------------------------------- ---

　　3、展示和功能的分层

　　大型网站中，常会为了将来的可扩展性、源代码维护方便，而将前台的展示 (HTML、Script)，和后台的商业逻辑、数据库访问 (.NET/C#、SQL)，切成多层。

　　根据 Martin Fowler 在 P of EAA 里的说法：Layer 是指「逻辑」上的分层 (logical separation)，Tier 是指「物理」上的分层 (physical separation)。若我们的 ASP.NET 站台，是用「虚拟」的分层 (N-Layer)，来切开 UI - BLL - DAL，通常不会有性能上的问题；但若是用「物理」的分层 (N-Tier)，亦即如上图 2 和下图 3，可能每一台 AP Server 都负责不同的商业逻辑 (销售、库存、物流、制造、会计、...)，各自的源代码都存放在不同的物理主机上，且可各自独立运作，此时就要考虑到每一台 AP Server 在彼此协调合作，以及调用 Web Service (XML 的性能不佳)、执行分布式事务上的性能问题。

　　

　　图 3 「物理」上的分层，各种商业逻辑可能存在多台物理主机上

　　谈到「物理」分层上的分布式事务 (Distributed Transaction)，微软的 Enterprise Services、COM+、WCF、WF 用到操作系统上的 MS DTC 来协调事务，由于 MS DTC 和这些应用程序各自处于不同的 Process，在沟通上会遇到序列化、反序列化的动作，还要整合事务中所有的 AppDomain 和不同主机上的资源，无可避免地一定会拖累性能。

　　Web Applications: N-Tier vs. N-Layer ：

　　http://codebetter.com/blogs/david.hayden/archive/2 005/07/23/129745.aspx

　　-------------------------------------------------- ---

　　4、数据大表拆分

　　对比较大的数据表，或历史数据比较多的数据表，可根据一定的逻辑进行拆分。若每天的数据量非常大，则可采用按日存放，再用一个「汇总表」来记录当天的一个汇总值；也可先将比较大的表拆分成多个表，再通过「索引表」进行关联处理，以避免查询大表造成的性能问题 [1]。

　　另也可用「表分区」的方式，将数据存储在不同的文件上，然后再部署到独立的物理服务器，以增加 I/O 吞吐，改善读写的性能。

　　此外，在本文的系列作「30 分钟快快乐乐学 SQL Performance Tuning」曾提过，若一个数据表的字段过多 (与刚才提的记录量过多不同)，应垂直切割成两个以上的数据表，并可用同名的 Primary Key 一对多连结起来，如：Northwind 的 Orders、Order Details 数据表。以避免在访问数据时，以「集簇引 (clustered index)」扫描时会加载过多的数据，或修改数据时造成互相锁定或锁定过久。

　　-------------------------------------------------- ---

　　5、图片服务器分离

　　对于 Web Server 来说，用户对图片的请求是最消耗系统资源的，因此可视网站的规模和项目的特性，部署独立的图片服务器，甚至多台图片服务器。

　　-------------------------------------------------- ---

　　6、读写分离

　　同时对数据库进行「读」和「写」的操作，是非常没效率的一种访问方式。比较好的做法，是根据读、写的压力和需求，分别建立两台结构完全相同的数据库服务器，将负责「写」的那台服务器的数据，定时复制给负责「读」的服务器。

　　-------------------------------------------------- ---

　　7、扩容性应对突增流量

　　大型网站在设计架构的时候，必须考虑到以后的容量扩充 [1]。对于活动类的网站来说，不定时的突增流量是巨大的。在网站主存储服务器上，采用配置文件形式，指定每一个存储盘柜上存储的数据文件的 ID 范围。当前台服务器需要读取一个数据的时候，首先通过询问主存储服务器上的接口，获得该数据所在的盘柜及目录地址，然后再去该盘柜读取实际的数据文件。如果需要增加盘柜，则只要修改配置文件即可，前台程序完全不受影响。

　　-------------------------------------------------- ---

　　8、缓存

　　缓存 (Cache) 是数据库或对象在内存中的临时容器，使用缓存可大幅减少数据库的读取，改由内存来提供数据。例如我们可以在 Web Server、DB Server 之间增加一层「数据缓存层」，在内存中建立被频繁请求对象的副本，如此一来，不访问数据库也可供给数据。例如，有 100 个用户请求同一份资料，以前需要查询数据库 100 次，现在则只需要 1 次，其余都可从缓存数据中获得，而且读取速度、网页反应速度会大幅提升。

　　提供缓存的产品有很多种，还可分为用硬件或软件所做的缓存，如：ASP.NET 内置的缓存功能、第三方厂商的缓存套件、Hibernate 和 NHibernate 里也有 Session 和 SessionFactory 的缓存机制、Oracle 的 cache group 技术，还有我先前在「用 IIS 7、ARR 与 Velocity 建设高性能的大型网站」这篇文章介绍的，微软官方新一代的分布式缓存技术 Velocity，另外像 Proxy Server (代理服务器) 也可以作为网页的缓存：

　　客户端 <----> 代理服务器 <----> 目的服务器

　　在 .NET 的类库中，有提供 CacheDependency 和 AggregateCacheDependency 这两个类，可用来将 ASP.NET 中缓存的对象 (如：DataSet)，和一或多个物理文件 (如：XML 文件) 或数据库中的表，去建立一种关联。当其中任一个 XML 文件被修改或移除时，与其关联的 DataSet 也会一并从内存里移除；当然，也可透过您程序中设定的时间自动移除。 ASP.NET 2.0 以后的缓存，最大的改变在于 CacheDependency 类已经被微软重新改写过，我们也可透过自定义类去继承它后再改写，以达成以下功能：

　　? 从 Active Directory 中的请求，让缓存失效 (缓存被自动移除)

　　? 从 MSMQ 或 MQSeries 中的请求，让缓存失效

　　? 从 Web Service 中的请求，让缓存失效

　　? 创建用于 Oracle 的 CacheDependency

　　? 其他

　　此外，SQL Server 中还有一种 SqlCacheDependency (缓存相依性)，可监听数据表中的数据是否曾经改变，亦即避免用户在缓存期间查到的数据是旧的，达到如果数据不变化，用户就一直从缓存中取得数据；一旦数据有变化，就自动更新缓存中的数据。启用 SqlCacheDependency 的方式，只要透过 aspnet_regsql.exe 这个工具，搭配参数输入命令，就会在 SQL Server 中产生一个新的 AspNet_SqlCacheTablesForChangeNotification 表，如下图 4 所示，这张表的的每一条记录，都代表您要监听的其中一个表；最右侧的 changeId 字段，其值为供系统判断，用户对 ASP.NET 中的请求，应由内存中的缓存来提供，抑或要至数据库重新做查询。

　　

　　图 4 启用 SqlCacheDependency 后，自动添加用来监听的表

　　另外再谈到，我在「网站性能越来越差怎么办？」这篇文章，也有提过下面的内容：

　　(4) 用程序或软件做缓存

　　用程序做缓存，如 ASP.NET 从 1.x 时代，就已内建的 Cache (缓存) 机制；或用一些第三方的辅助软件、Framework。

　　(5) 用硬件做快取或缓冲、砸钱加装 AP Server

　　他还在原本的网页服务器，与数据库服务器的架构中，加入一组应用程序服务器，作为网页服务器 cache 数据的来源。

　　改版之后的新网站，搜寻速度提升许多，先前每日的统计数据中，处理速度超过 3 秒的数据超过 50 万笔；而改版后，每星期超过 3 秒的查询不到 10 笔。

　　(6) 用硬件做缓存 (cache)

　　全盛时期，来自美国 blog 的流量每天达 80 万次。这个数字其实不高，对程序高手来说是小菜一碟，但笔者是半吊子工程师，知识有限也因此可能程序写得不好，频频被主机供货商发信警告，要求改善网站系统性能。最后，我决定开发 cache system。cache system 缓存系统上线后，将数据库读写，从每天 80 万次降低到每天 16 万次。

　　回复：

　　Peter.z.lu

　　中间件可以有很多选择：

　　Ncache, Coherence, Velocity, MemCache...

　　另外，还有像是 Memcached、Cacheman 这种分布式缓存的系统。前者可基于 Linux 和 Win32 平台使用，通过在内存里维护一个巨大的 hash 表，可存储图像、视频、文件及数据库检索的结果，并且支持多服务器，可解决 ASP.NET 内置的缓存机制仅适用于单独的服务器；后者据说是微软旗下 Popfly 项目组成员 Sriram Krishnan 的作品，将来也有可能成为微软的正式产品。

　　-------------------------------------------------- ---

　　9、分布式系统数据结构 - 以 MySpace 为例

　　在网络上流传一篇很火红的文章「从 MySpace 数据库看分布式系统数据结构变迁」，内容提到 MySpace 这个大型的社区网站，使用微软平台的 Windows Server、SQL Server、ASP.NET 技术，如今每个月的用户访问量高达 500 亿，且已有 2 亿个以上的用户注册。以下仅节录该文的重点： 第一代架构 - 添置更多的 Web 服务器

　　在 MySpace 有 50 万个注册用户的时候，网站只用了两台 Dell 双 CPU、4 GB 内存的 Web Server (分散用户的请求)、一台 DB Server (所有数据都存储在这)。

　　第二代架构 - 增加数据库服务器

　　运行在三台数据库服务器上，一台用于更新数据 (由它复制到其他两个)、另两台用于读取数据，因为看网页的人多，而需要写入的人少。等到用户数和访问量增加了，就再加装硬盘。

　　后来数据库服务器的 I/O 成了瓶颈，就按照垂直分割模式设计，把网站里的不同功能，如：登录、用户资料和博客，搬移到不同的数据库服务器中，以分担访问压力；若要增加新功能，就再投入新的数据库服务器。

　　当注册用户达到 200 万后，还从存储设备与数据库服务器直接交互的方式，切换到 SAN (存储区域网络)，一种高带宽、专门设计的网络系统，可将大量磁盘存储设备连接在一起。MySpace 让数据库连接到 SAN。但是当用户增加到 300 万人后，垂直分割策略也变得难以维持下去，后来架构师后来将主机升级成 34 个 CPU 的昂贵服务器，却也无法负荷。

　　第三代架构 - 转到分布式计算架构

　　架构师将 MySpace 移到分布式计算架构，它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。这次，不再按站点功能和应用分割数据库，MySpace 开始将它的用户按每 100 万一组分割，然后将各组的全部数据分别存入独立的 SQL Server 实例。后来 MySpace 的每台数据库服务器实际运行两个 SQL Server 实例，也就是说每台服务器会服务大约 200 万用户。

　　第四代架构 - 增加数据缓存层

　　当用户达到 900-1000 万时，MySpace再次遭遇存储瓶颈问题，后来引用了新的 SAN 产品，但站点目前的要求，已经超越 SAN 的 I/O 磁盘存储系统、及其读写数据的极限速度。

　　当用户达到 1700 万时，增加了一个数据缓存层，其位于 Web 服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本。以前每一位用户查询一个信息，就请求一次数据库；现在当任一个用户请求数据库后，缓存层就会保留一个副本，当其他用户再访问时就不需要再请求数据库了，如此一来，不访问数据库也可以供给数据。

　　第五代架构 - 转到支持 64 位处理器的操作系统和数据库软件

　　当用户数达到 2600 万时，转到了还处于 Beta 版、但支持 64 位处理器的 SQL Server 2005。在升级到 64 位的 SQL Server 2005 和 Windows Server 2003 后，MySpace 每台服务器配备了 32 GB 内存，后来又提升到了 64 GB。

　　从 MySpace 数据库看分布式系统数据结构变迁：

　　http://www.cnblogs.com/cxccbv/archive/2009/07/15/1 524387.html

　　http://www.javaeye.com/topic/152766

　　http://smb.pconline.com.cn/database/0808/1403100.h tml

　　http://idai.blogbus.com/logs/14736411.html

　　-------------------------------------------------- ---

　　转载于博客园：http://kb.cnblogs.com/page/49218/


-----------------------------------------------------------------
以上正文预览由 SOSO博客 提供，原文地址： http://www.cnblogs.com/DavidYan/articles/2225946.html