大數據量、大併發請求的處理方法

大併發大數據量請求通常會分爲幾種狀況：

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.將表按索引劃分(分表，分區)，如：對於一個存儲全國人民信息的表，這個數據量是很大的，若是按省劃分爲多個表，在將全國的人民信息按省存儲到相應的表中，而後根據省份對相應的並進行查詢和更新，這樣大併發和大數據量的問題就會減少不少

若是還有其餘更好的方法，但願你們能指點一二