| 至于 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 | 
扫一扫
447
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
