大数据量、大并发请求的处理方法

大并发大数据量请求通常会分为几种状况：

1. 大量的用户对系统的不一样功能页面进行查找、更新操做

2. 大量的用户同事对系统的同一页面，同一表的大数据量进行查询操做

3. 大量的用户同事对系统的同一页面，同一表进行更新操做

 

对于第一种状况通常处理方法以下：

一。对服务器层面的处理

1. 调整IIS 7应用程序池队列长度

由原来的默认1000改成65535。

IIS Manager > ApplicationPools > Advanced Settings

Queue Length : 65535

2.  调整IIS 7的appConcurrentRequestLimit设置

由原来的默认5000改成100000。

c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

在%systemroot%\System32\inetsrv\config\applicationHost.config中能够查看到该设置：
[html] view plaincopy

    <serverRuntime appConcurrentRequestLimit="100000" />   

3. 调整machine.config中的processModel>requestQueueLimit的设置

由原来的默认5000改成100000。
[html] view plaincopy

    <configuration>  
        <system.web>  
            <processModel requestQueueLimit="100000"/>   

4. 修改注册表，调整IIS 7支持的同时TCPIP链接数

由原来的默认5000改成100000。

reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameteris /v MaxConnections /t REG_DWORD /d 100000 

完成上述4个设置，就基本能够支持10万个同时请求。若是访问量达到10万以上，就能够考虑将程序和数据库按功能模块划分部署到多个服务器分担访问压力。另外能够考虑软硬件负载均衡。硬件负载均衡可以直接经过智能交换机实现，处理能力强，并且与系统无关，可是价格贵,配置困难，不能区分实习系统与应状态。因此硬件负载均衡适用于一大堆设备，大访问量，简单应用。软件负载均衡是基于系统与应用的，能过更好地根据系统与应用的情况来分配负载。性价比高。PCL负载均衡软件，Linux下的LVS软件。

 

二。对数据库层面的处理

      当两个用户同时访问一个页面，一个用户可能更新的是另外一个用户已经删除的记录。或者，在一个用户加载页面跟他点击删除按钮之间的时间里，另外一个用户修改了这条记录的内容。因此须要考虑数据库锁的问题

有下面三中并发控制策略可供选择：

Ø 什么都不作 –若是并发用户修改的是同一条记录，让最后提交的结果生效（默认的行为）

Ø 开放式并发（Optimistic Concurrency） - 假定并发冲突只是偶尔发生，绝大多数的时候并不会出现； 那么，当发生一个冲突时，仅仅简单的告知用户，他所做的更改不能保存，由于别的用户已经修改了同一条记录

Ø 保守式并发（Pessimistic Concurrency） – 假定并发冲突常常发生，而且用户不能容忍被告知本身的修改不能保存是因为别人的并发行为；那么，当一个用户开始编辑一条记录，锁定该记录，从而防止其余用户编辑或删除该记录，直到他完成并提交本身的更改

当多个用户试图同时修改数据时，须要创建控制机制来防止一个用户的修改对同时操做的其余用户所做的修改产生不利的影响。处理这种状况的系统叫作“并发控制”。
并发控制的类型

一般，管理数据库中的并发有三种常见的方法：

    保守式并发控制 - 在从获取记录直到记录在数据库中更新的这段时间内，该行对用户不可用。
    开放式并发控制 - 只有当实际更新数据时，该行才对其余用户不可用。更新将在数据库中检查该行并肯定是否进行了任何更改。若是试图更新已更改的记录，则将致使并发冲突。
    最后的更新生效 - 只有当实际更新数据时，该行才对其余用户不可用。可是，不会将更新与初始记录进行比较；而只是写出记录，这可能就改写了自上次刷新记录后其余用户所进行的更改。

保守式并发

保守式并发一般用于两个目的。第一，在某些状况下，存在对相同记录的大量争用。在数据上放置锁所费的成本小于发生并发冲突时回滚更改所费的成本。

在事务过程当中不宜更改记录的状况下，保守式并发也很是有用。库存应用程序即是一个很好的示例。假定有一个公司表明正在为一名潜在的客户检查库存。您一般要锁定记录，直到生成订单为止，这一般会将该项标记为“已订购”状态并将其从可用库存中移除。若是未生成订单，则将释放该锁，以便其余检查库存的用户获得准确的可用库存计数。

可是，在断开的结构中没法进行保守式并发控制。链接打开的时间只够读取数据或更新数据，所以不能长时间地保持锁。此外，长时间保留锁的应用程序将没法进行伸缩。
开放式并发

在开放式并发中，只有在访问数据库时才设置并保持锁。这些锁将防止其余用户在同一时间更新记录。除了进行更新这一确切的时刻以外，数据始终可用。有关更多信息，请参见开放式并发。

当试图更新时，已更改行的初始版本将与数据库中的现有行进行比较。若是二者不一样，更新将失败，并引起并发错误。这时，将由您使用所建立的业务逻辑来协调这两行。
最后的更新生效

当使用“最后的更新生效”时，不会对初始数据进行检查，而只是将更新写入数据库。很明显，可能会发生如下状况：

    用户 A 从数据库获取一项记录。
    用户 B 从数据库获取相同的记录，对其进行修改，而后将更新后的记录写回数据库。
    用户 A 修改“旧”记录并将其写回数据库。 

在上述状况中，用户 A 永远也不会看到用户 B 做出的更改。若是您计划使用并发控制的“最后的更新生效”方法，则要确保这种状况是能够接受的。
ADO.NET 和 Visual Studio .NET 中的并发控制

由于数据结构基于断开的数据，因此 ADO.NET 和 Visual Studio .NET 使用开放式并发。所以，您须要添加业务逻辑，以利用开放式并发解决问题。

若是您选择使用开放式并发，则能够经过两种常规的方法来肯定是否已发生更改：版本方法（实际版本号或日期时间戳）和保存全部值方法。
版本号方法

在版本号方法中，要更新的记录必须具备一个包含日期时间戳或版本号的列。当读取该记录时，日期时间戳或版本号将保存在客户端。而后，将对该值进行部分更新。

处理并发的一种方法是仅当 WHERE 子句中的值与记录上的值匹配时才进行更新。该方法的 SQL 表示形式为：

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE DateTimeStamp = @origDateTimeStamp

或者，可使用版本号进行比较：

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE RowVersion = @origRowVersionValue

若是日期时间戳或版本号匹配，则代表数据存储区中的记录未被更改，而且能够安全地使用数据集中的新值对该记录进行更新。若是不匹配，则将返回错误。您能够编写代码，在 Visual Studio .NET 中实现这种形式的并发检查。您还必须编写代码来响应任何更新冲突。为了确保日期时间戳或版本号的准确性，您须要在表上设置触发器，以便在发生对行的更改时，对日期时间戳或版本号进行更新。
保存全部值方法

使用日期时间戳或版本号的替代方法是在读取记录时获取全部字段的副本。ADO.NET 中的 DataSet 对象维护每一个修改记录的两个版本：初始版本（最初从数据源中读取的版本）和修改版本（表示用户更新）。当试图将记录写回数据源时，数据行中的初始值将与数据源中的记录进行比较。若是它们匹配，则代表数据库记录在被读取后还没有通过更改。在这种状况下，数据集中已更改的值将成功地写入数据库。

对于数据适配器的四个命令（DELETE、INSERT、SELECT 和 UPDATE）来讲，每一个命令都有一个参数集合。每一个命令都有用于初始值和当前值（或修改值）的参数。

 

 
对于第二种状况的处理：

由于是大并发请求，也能采用第一种状况的处理方法，另外由于是对大数据量进行检索，因此须要考虑查询效率的问题

调大数据库链接池中的链接数

1.对表按查询条件创建索引

2.对查询语句进行优化

3.能够考虑对查询数据使用缓存

 

对于第三种状况的处理：

也能采用第一种状况的处理方法，另外由于是对同一个表进行更新操做，能够考虑使用下面的处理方法：

1.先将数据保存到缓存中，当数据达到必定的数量后，再更新到数据库中

2.将表按索引划分(分表，分区)，如：对于一个存储全国人民信息的表，这个数据量是很大的，若是按省划分为多个表，在将全国的人民信息按省存储到相应的表中，而后根据省份对相应的并进行查询和更新，这样大并发和大数据量的问题就会减少不少

若是还有其余更好的方法，但愿你们能指点一二