大數(shù)據(jù)量并發(fā)處理

大并發(fā)大數(shù)據(jù)量請(qǐng)求的處理方法
大并發(fā)大數(shù)據(jù)量請(qǐng)求一般會(huì)分為幾種情況：
1.大量的用戶同時(shí)對(duì)系統(tǒng)的不同功能頁面進(jìn)行查找，更新操作
2.大量的用戶同時(shí)對(duì)系統(tǒng)的同一個(gè)頁面，同一個(gè)表的大數(shù)據(jù)量進(jìn)行查詢操作
3.大量的用戶同時(shí)對(duì)系統(tǒng)的同一個(gè)頁面，同一個(gè)表進(jìn)行更新操作

對(duì)于第一種情況一般處理方法如下：
一。對(duì)服務(wù)器層面的處理
1. 調(diào)整IIS 7應(yīng)用程序池隊(duì)列長度
由原來的默認(rèn)1000改為65535。
IIS Manager > ApplicationPools > Advanced Settings

Queue Length : 65535

2.  調(diào)整IIS 7的appConcurrentRequestLimit設(shè)置

由原來的默認(rèn)5000改為100000。

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

在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到該設(shè)置：
[html] view plaincopy

    <serverRuntime appConcurrentRequestLimit="100000" />   

[html] view plain copy

    <serverRuntime appConcurrentRequestLimit="100000" />   

3. 調(diào)整machine.config中的processModel>requestQueueLimit的設(shè)置

由原來的默認(rèn)5000改為100000。
[html] view plaincopy

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

[html] view plain copy

    <configuration>  
        <system.web>  
            <processModel requestQueueLimit="100000"/>   
4. 修改注冊(cè)表，調(diào)整IIS 7支持的同時(shí)TCPIP連接數(shù)
由原來的默認(rèn)5000改為100000。
reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameteris /v MaxConnections /t REG_DWORD /d 100000
完成上述4個(gè)設(shè)置，就基本可以支持10萬個(gè)同時(shí)請(qǐng)求。如果訪問量達(dá)到10萬以上，就可以考慮將程序和數(shù)據(jù)庫按功能模塊劃分部署到多個(gè)服務(wù)器分擔(dān)訪問壓力。另外可以考慮軟硬件負(fù)載均衡。硬件負(fù)載均衡能夠直接通過智能交換機(jī)實(shí)現(xiàn)，處理能力強(qiáng)，而且與系統(tǒng)無關(guān)，但是價(jià)格貴,配置困難，不能區(qū)分實(shí)習(xí)系統(tǒng)與應(yīng)狀態(tài)。所以硬件負(fù)載均衡適用于一大堆設(shè)備，大訪問量，簡單應(yīng)用。軟件負(fù)載均衡是基于系統(tǒng)與應(yīng)用的，能過更好地根據(jù)系統(tǒng)與應(yīng)用的狀況來分配負(fù)載。性價(jià)比高。PCL負(fù)載均衡軟件，Linux下的LVS軟件。
二。對(duì)數(shù)據(jù)庫層面的處理
      當(dāng)兩個(gè)用戶同時(shí)訪問一個(gè)頁面，一個(gè)用戶可能更新的是另一個(gè)用戶已經(jīng)刪除的記錄。或者，在一個(gè)用戶加載頁面跟他點(diǎn)擊刪除按鈕之間的時(shí)間里，另一個(gè)用戶修改了這條記錄的內(nèi)容。所以需要考慮數(shù)據(jù)庫鎖的問題
有下面三中并發(fā)控制策略可供選擇：
什么都不做 –如果并發(fā)用戶修改的是同一條記錄，讓最后提交的結(jié)果生效（默認(rèn)的行為）
開放式并發(fā)（Optimistic Concurrency） - 假定并發(fā)沖突只是偶爾發(fā)生，絕大多數(shù)的時(shí)候并不會(huì)出現(xiàn)； 那么，當(dāng)發(fā)生一個(gè)沖突時(shí)，僅僅簡單的告知用戶，他所作的更改不能保存，因?yàn)閯e的用戶已經(jīng)修改了同一條記錄
保守式并發(fā)（Pessimistic Concurrency） – 假定并發(fā)沖突經(jīng)常發(fā)生，并且用戶不能容忍被告知自己的修改不能保存是由于別人的并發(fā)行為；那么，當(dāng)一個(gè)用戶開始編輯一條記錄，鎖定該記錄，從而防止其他用戶編輯或刪除該記錄，直到他完成并提交自己的更改
當(dāng)多個(gè)用戶試圖同時(shí)修改數(shù)據(jù)時(shí)，需要建立控制機(jī)制來防止一個(gè)用戶的修改對(duì)同時(shí)操作的其他用戶所作的修改產(chǎn)生不利的影響。處理這種情況的系統(tǒng)叫做“并發(fā)控制”。
并發(fā)控制的類型
通常，管理數(shù)據(jù)庫中的并發(fā)有三種常見的方法：
    保守式并發(fā)控制 - 在從獲取記錄直到記錄在數(shù)據(jù)庫中更新的這段時(shí)間內(nèi)，該行對(duì)用戶不可用。
    開放式并發(fā)控制 - 只有當(dāng)實(shí)際更新數(shù)據(jù)時(shí)，該行才對(duì)其他用戶不可用。更新將在數(shù)據(jù)庫中檢查該行并確定是否進(jìn)行了任何更改。如果試圖更新已更改的記錄，則將導(dǎo)致并發(fā)沖突。
    最后的更新生效 - 只有當(dāng)實(shí)際更新數(shù)據(jù)時(shí)，該行才對(duì)其他用戶不可用。但是，不會(huì)將更新與初始記錄進(jìn)行比較；而只是寫出記錄，這可能就改寫了自上次刷新記錄后其他用戶所進(jìn)行的更改。
保守式并發(fā)
保守式并發(fā)通常用于兩個(gè)目的。第一，在某些情況下，存在對(duì)相同記錄的大量爭用。在數(shù)據(jù)上放置鎖所費(fèi)的成本小于發(fā)生并發(fā)沖突時(shí)回滾更改所費(fèi)的成本。
在事務(wù)過程中不宜更改記錄的情況下，保守式并發(fā)也非常有用。庫存應(yīng)用程序便是一個(gè)很好的示例。假定有一個(gè)公司代表正在為一名潛在的客戶檢查庫存。您通常要鎖定記錄，直到生成訂單為止，這通常會(huì)將該項(xiàng)標(biāo)記為“已訂購”狀態(tài)并將其從可用庫存中移除。如果未生成訂單，則將釋放該鎖，以便其他檢查庫存的用戶得到準(zhǔn)確的可用庫存計(jì)數(shù)。
但是，在斷開的結(jié)構(gòu)中無法進(jìn)行保守式并發(fā)控制。連接打開的時(shí)間只夠讀取數(shù)據(jù)或更新數(shù)據(jù)，因此不能長時(shí)間地保持鎖。此外，長時(shí)間保留鎖的應(yīng)用程序?qū)o法進(jìn)行伸縮。
開放式并發(fā)
在開放式并發(fā)中，只有在訪問數(shù)據(jù)庫時(shí)才設(shè)置并保持鎖。這些鎖將防止其他用戶在同一時(shí)間更新記錄。除了進(jìn)行更新這一確切的時(shí)刻之外，數(shù)據(jù)始終可用。有關(guān)更多信息，請(qǐng)參見開放式并發(fā)。
當(dāng)試圖更新時(shí)，已更改行的初始版本將與數(shù)據(jù)庫中的現(xiàn)有行進(jìn)行比較。如果兩者不同，更新將失敗，并引發(fā)并發(fā)錯(cuò)誤。這時(shí)，將由您使用所創(chuàng)建的業(yè)務(wù)邏輯來協(xié)調(diào)這兩行。
最后的更新生效
當(dāng)使用“最后的更新生效”時(shí)，不會(huì)對(duì)初始數(shù)據(jù)進(jìn)行檢查，而只是將更新寫入數(shù)據(jù)庫。很明顯，可能會(huì)發(fā)生以下情況：
    用戶 A 從數(shù)據(jù)庫獲取一項(xiàng)記錄。
    用戶 B 從數(shù)據(jù)庫獲取相同的記錄，對(duì)其進(jìn)行修改，然后將更新后的記錄寫回?cái)?shù)據(jù)庫。
    用戶 A 修改“舊”記錄并將其寫回?cái)?shù)據(jù)庫。
在上述情況中，用戶 A 永遠(yuǎn)也不會(huì)看到用戶 B 作出的更改。如果您計(jì)劃使用并發(fā)控制的“最后的更新生效”方法，則要確保這種情況是可以接受的。
ADO.NET 和 Visual Studio .NET 中的并發(fā)控制
因?yàn)閿?shù)據(jù)結(jié)構(gòu)基于斷開的數(shù)據(jù)，所以 ADO.NET 和 Visual Studio .NET 使用開放式并發(fā)。因此，您需要添加業(yè)務(wù)邏輯，以利用開放式并發(fā)解決問題。
如果您選擇使用開放式并發(fā)，則可以通過兩種常規(guī)的方法來確定是否已發(fā)生更改：版本方法（實(shí)際版本號(hào)或日期時(shí)間戳）和保存所有值方法。
版本號(hào)方法
在版本號(hào)方法中，要更新的記錄必須具有一個(gè)包含日期時(shí)間戳或版本號(hào)的列。當(dāng)讀取該記錄時(shí)，日期時(shí)間戳或版本號(hào)將保存在客戶端。然后，將對(duì)該值進(jìn)行部分更新。
處理并發(fā)的一種方法是僅當(dāng) WHERE 子句中的值與記錄上的值匹配時(shí)才進(jìn)行更新。該方法的 SQL 表示形式為：
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE DateTimeStamp = @origDateTimeStamp
或者，可以使用版本號(hào)進(jìn)行比較：
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE RowVersion = @origRowVersionValue
如果日期時(shí)間戳或版本號(hào)匹配，則表明數(shù)據(jù)存儲(chǔ)區(qū)中的記錄未被更改，并且可以安全地使用數(shù)據(jù)集中的新值對(duì)該記錄進(jìn)行更新。如果不匹配，則將返回錯(cuò)誤。您可以編寫代碼，在 Visual Studio .NET 中實(shí)現(xiàn)這種形式的并發(fā)檢查。您還必須編寫代碼來響應(yīng)任何更新沖突。為了確保日期時(shí)間戳或版本號(hào)的準(zhǔn)確性，您需要在表上設(shè)置觸發(fā)器，以便在發(fā)生對(duì)行的更改時(shí)，對(duì)日期時(shí)間戳或版本號(hào)進(jìn)行更新。
保存所有值方法
使用日期時(shí)間戳或版本號(hào)的替代方法是在讀取記錄時(shí)獲取所有字段的副本。ADO.NET 中的 DataSet 對(duì)象維護(hù)每個(gè)修改記錄的兩個(gè)版本：初始版本（最初從數(shù)據(jù)源中讀取的版本）和修改版本（表示用戶更新）。當(dāng)試圖將記錄寫回?cái)?shù)據(jù)源時(shí)，數(shù)據(jù)行中的初始值將與數(shù)據(jù)源中的記錄進(jìn)行比較。如果它們匹配，則表明數(shù)據(jù)庫記錄在被讀取后尚未經(jīng)過更改。在這種情況下，數(shù)據(jù)集中已更改的值將成功地寫入數(shù)據(jù)庫。
對(duì)于數(shù)據(jù)適配器的四個(gè)命令（DELETE、INSERT、SELECT 和 UPDATE）來說，每個(gè)命令都有一個(gè)參數(shù)集合。每個(gè)命令都有用于初始值和當(dāng)前值（或修改值）的參數(shù)。
對(duì)于第二種情況的處理：
因?yàn)槭谴蟛l(fā)請(qǐng)求，也能采用第一種情況的處理方法，另外因?yàn)槭菍?duì)大數(shù)據(jù)量進(jìn)行檢索，所以需要考慮查詢效率的問題
1.對(duì)表按查詢條件建立索引
2.對(duì)查詢語句進(jìn)行優(yōu)化
3.可以考慮對(duì)查詢數(shù)據(jù)使用緩存
對(duì)于第三種情況的處理：
也能采用第一種情況的處理方法，另外因?yàn)槭菍?duì)同一個(gè)表進(jìn)行更新操作，可以考慮使用下面的處理方法：
1.先將數(shù)據(jù)保存到緩存中，當(dāng)數(shù)據(jù)達(dá)到一定的數(shù)量后，再更新到數(shù)據(jù)庫中
2.將表按索引劃分(分表，分區(qū))，如：對(duì)于一個(gè)存儲(chǔ)全國人民信息的表，這個(gè)數(shù)據(jù)量是很大的，如果按省劃分為多個(gè)表，在將全國的人民信息按省存儲(chǔ)到相應(yīng)的表中，然后根據(jù)省份對(duì)相應(yīng)的并進(jìn)行查詢和更新，這樣大并發(fā)和大數(shù)據(jù)量的問題就會(huì)減小很多