随笔-8  评论-9  文章-416 

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

转载自: http://blog.163.com/dangzhengtao@yeah/blog/static/7780087420098232213289/?fromdm&fromSearch&isFromSearchEngine=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.aspx

Three-Tiered Distribution(三级分布)(硬件、不同主机的物理级分层):
http://msdn.microsoft.com/zh-cn/library/ms978694.aspx

Three-Layered Services Application(三层服务应用程序)(软件、代码上的分层):
http://msdn.microsoft.com/zh-cn/library/ms978689.aspx

Tiered Distribution(分级分布):
http://msdn.microsoft.com/en-gb/library/ms978701(zh-cn).aspx

Deployment Patterns:
http://msdn.microsoft.com/zh-cn/library/ms998478.aspx
http://msdn.microsoft.com/en-us/library/ms998478.aspx

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

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.aspx
http://msdn.microsoft.com/en-us/library/ms978730.aspx

Server Clustering(服务器群集):
http://msdn.microsoft.com/en-gb/library/ms998414(zh-cn).aspx

Installing Network Load Balancing (NLB) on Windows Server 2008:
http://blogs.msdn.com/clustering/archive/2008/01/08/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.aspx
http://msdn.microsoft.com/en-us/library/ms730128.aspx

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

 

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/2005/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/1524387.html
http://www.javaeye.com/topic/152766
http://smb.pconline.com.cn/database/0808/1403100.html
http://idai.blogbus.com/logs/14736411.html

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


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

posted on 2011-10-27 01:46 DavidYanXW 阅读(...) 评论(...)  编辑 收藏