基于Asp.net的高考填報志愿系統高并發負載解決方案

李曉寧 張浩

摘 要：本文以當前全國各省普通高考網上填報系統因并發量過高而極易造成網站的癱瘓的現象著手，設計了普通高校招生網上填報志愿系統的高并發負載解決方案。本系統在盡可能的采用傳統的網站高并發負載優化策略的同時，還針對系統本身的特點從宏觀架構及微觀技術實現手段上都加以研究分析，制定針對網上填報志愿系統的高負載解決方案。宏觀上本系統利用了面向服務的程序設計方式將系統分為網站程序層、數據緩存層、數據庫層的三層進行設計，實現了系統中應用程序、數據操作、數據存儲上的物理及邏輯分離，因此系統應對高并發負載具有了分布式解決能力，實現了系統的可擴展性。微觀上，本系統利用了目前許多提高系統性能的新技術新方法，使網站程序運行具有了高效性。本系統的有以下幾個特點及創新：（1）架設數據緩存庫服務器，建立完善的內存數據緩存管理機制，利用面向服務的技術進行網站程序和數據緩存之間的通訊。（2）WEB程序與數據庫隔離，增加系統的安全性。（3）軟件程序負載均衡與硬件負載均衡結合應對大并發訪問。（4）WEB服務器設置內存字典，使用哈希表進行數據映射，解決頻繁數據查詢。（5）網站程序層、數據緩存層、數據庫層的分層結構設計，方便系統擴展。通過測試和實踐證明，使用多種方法對WEB程序進行優化設計及把內存數據庫作為向數據庫中寫入數據前的緩沖的思路，能很好的增加網上填報志愿系統一類的大數據量的網上應用程序的吞吐能力，從而完成高并發負載的網上填報志愿需求。

關鍵詞：高并發 負載 WCF 內存數據庫 優化

中圖分類號：TP319 文獻標識碼：A 文章編號：1672-3791（2013）03（c）-0043-05

隨著近年來教育部對“陽光工程”的施行和“平行志愿投檔”的推廣，加強了我國高校招生的公平性和透明性。其中“填報志愿”是考生選擇大學的方式，決定著考生一生的發展道路，因此確保志愿信息采集的公平性、及時性、準確性、安全性也成為了各級招生部門工作的重要環節。目前招生部門采用的高考志愿信息采集主要有兩種方式：一是的傳統的涂卡方式，招生部門發放給考生志愿信息采集卡，由考生根據學校和專業代碼填圖志愿后，統一利用光標閱讀機（OMR）進行讀卡；二是開發網上填報志愿系統（以下簡稱網報系統）利用網頁進行志愿信息采集。網上填報志愿針對過去的錄卡報志愿網報系統有以下幾個方面的優勢。

（1）直觀、高效。

考生通過通過互聯網登錄網報系統。考生可以在下拉菜單中做出選擇，填入學校和專業代碼即可。部分操作熟練的考生十分鐘之內就可以完成志愿填報。

（2）簡化流程。

采用讀卡填報志愿方式流程是讓每位考生向老師索取志愿卡后填涂信息，再到招生辦讀出志愿信息，回來后考生改錯，再由招辦工作人員重新改正，然后考生確認信息，這些環節不能有半點差錯。網上報志愿簡化了這些流程，考生可以在任何接入互聯網的電腦上填報志愿并在網上確認。

（3）錯誤率減少。

通過涂卡的方式報志愿時，考生先查找好報考的院校及專業代碼，然后根據代碼的數字在信息卡上相應的代表位置涂黑，由于填涂過程不能直觀的反應出所填報的院校及專業，所以很容易因涂錯位置而發生填報錯誤。通過網上報志愿考生所錄入的院校及專業的代碼可以及時的進行翻譯和校驗，大大減少了填報錯誤的發生。

采用網上填報志愿是發展必然趨勢，也是互聯網高速發展及計算機普及的產物。隨著部分省份對網上填報志愿的率先嘗試并取得較好的社會反響，網上填報志愿已成為考生志愿信息采集的最好方法。同時，進行網上填報志愿的省份也都面臨著一個嚴峻的問題：由于考生人數多，并且訪問時間集中同時單個考生修改及查詢頻率又高，極高的瞬時并發操作請求致使系統和數據庫超負荷運行，系統不能及時響應訪問請求，舊的請求還未處理完，新的訪問請求又到來，從而導致服務器處于假死狀態。一旦進入假死狀態，用戶的操作就會得不到響應，頁面長時間打不開會延誤考生填報志愿，造成不良的社會影響，甚至致使考生不能完成填報志愿造成重大責任事故。

如何有效的對系統進行高并發負載已成為網報系統的瓶頸和使用上的軟肋，也制約了網上填報志愿在全國范圍內的推廣，目前各省教育考試部門都在針對這一問題進行積極的探索。我們就對這一問題在Asp.net平臺上提出解決方案：根據木桶原理，要想提高系統的整體能力就需要找到系統的瓶頸加以解決。我們首先分析了整個系統的結構，由于網報系統需要響應大量的考生訪問，并且每個考生的訪問都要進行大量的數據查詢存取操作，因此網站不同功能之間的處理能力和速度上的差別也就成為了系統存在的瓶頸。本著為處理壓力較大的模塊增加擴展，為處理速度較慢的模塊設計緩沖這一理念，我們對系統中的應用程序、數據操作和數據存儲這三大應用功能進行了分層設計，將系統分為網站程序層、緩存數據庫層和數據庫層。網站程序處理壓力大，該層要進行可擴展性設計；數據庫層存在速度較慢，該層要由數據緩存層進行緩沖設計，（如圖1）所示。下面分別對各層的設計進行分析。

1 網站程序層

該層使用最新的ASP.NET技術進行開發，部署在WEB服務器上。肩負著同考生進行交互，實現志愿填報業務邏輯；完成志愿代碼翻譯查詢，通過WCF服務從數據緩存層中讀取數據。由于該層的負載壓力大，因此需要很好的橫向擴展設計。

（1）負載均衡。

同時由于程序的主要負載都集中在網站程序上，為了應對大并發的負載，我們把網站程序在每臺WEB服務器上都設計為獨立運行，采用F5負載均衡設備為用戶訪問提供20分鐘的會話保持。這樣就為程序提高了良好的橫向擴展性和可靠性，如果WEB服務出現負載飽和時，只需添加服務器即可實現負載分流，（如圖2）所示。

（2）內存數據字典。

在填報志愿過程中查詢最頻繁的就是計劃表，計劃庫表放著招生院校的層次、批次和其專業的科類、計劃性質等信息，總記錄數為3萬條左右。通過計劃表查詢將考生填寫的院校編碼和專業編碼翻譯成院校名稱和專業名稱，并判斷考生是否將院校代碼和專業填錯并提醒考生不要誤報達不到要求的專業浪費報考機會，因此計劃表能否正確、高效、快速的查詢對網報系統能否正常運行起著至關重要的作用。以某省50萬考生來計算，對計劃表的查詢量達十一億次，顯然在集中的時間段內應對如此大量的查詢請求數據庫已經很難負載。內存數據字典，是將計劃表在程序首次運行時加載到每臺WEB服務器內存中，可供程序直接在內存中訪問的數據集合。通過測試內存的讀取速度為18000多M/S，寫入速度在15000左右（HP GX580服務器），而現在最好的固態硬盤讀取速度也就能到400多M/S，相對于磁盤內存的數據讀寫速度要高出幾個數量級。所以從內存中讀取數據相比從磁盤上讀取能夠極大地減少查詢時間提高應用的性。

2 數據緩存層

在填報志愿過程中，按50萬考生每個考生可以填報8個批次，每個批次可以填報5所院校，其中1秒中有1000個考生在操作志愿數據的情況下計算，就要滿足1秒鐘內在兩千多萬記錄中進行四萬次數據修改操作的需求。面對苛刻的高并發負載需求，傳統數據庫很難實現。要完成如果高速的操作，IO速度極高的內存將會是最合適的場所，所以需要自行開發內存數據庫作為數據緩存層來實現這一需求。該層是整個網報系統的數據處理中心，部署在專門設立的緩存服務器上。數據緩存層運行有一套完成的數據維護機制。實現增、刪、查、改的數據操作；實現監聽、應答的通訊機制；實現數據備份和回復功能。作為網站程序層和數據庫層的速度差異緩沖，該層也就成為了系統中數據操作、交互的核心。

構建內存數據緩存層后，我們對內存數據庫和SQLSERVER數據庫進行了2萬次數據讀寫效率對比測試，如圖3所示。

設計時我們需要考慮以下幾個方面。

（1）數據操作模式。

作為內存數據庫和前面的內存字典不一樣，不僅僅要完成對數據的查詢請求，還要完成對數據的增加、刪除、修改的操作。

（2）通訊機制。

如果沒有通訊內存數據庫就是聾子和啞巴，對外是發揮不了任何作用的，因此在內存數據庫中還要建立對請求的監聽和應答機制。

（3）數據備份。

內存作為高速暫時存儲器，其數據在斷電后會立刻丟失，因此要將內存中的數據寫入到數據庫中并妥善存儲在硬盤上才能確保數據不會丟失。

我們將上述功能通過數據緩存、通訊、調度三個模塊來實現，這些模塊的分工如下。

（1）數據緩存模塊。

該模塊負責在內存中存放數據，并在運行期間維護數據的完整性；數據緩存層初始化運行時從數據庫中加載數據并建立索引；提供數據查詢接口函數；定時將改動的數據以xml文件保存到硬盤上供調度程序寫入數據庫。該模塊是內存數據庫的實現基礎，由于這些功是在內存中實現，需要考慮以下幾個方面。

①數據占用空間。

在志愿表中一條考生志愿信息經計算形成數據對象存儲后每條記錄的大小為1K左右。按50萬考生每個考生填報8個批次，每批報5所院校計算，內存數據庫中所存儲的數據最大容量為22400000×1K，即22.4GB。加上windows2008和WCF服務需要占用的2～3G內存空間，我們需求的最低內存容量為26GB。

②數據安全。

內存作為暫存器，斷電后造成數據丟失，針對該問題我們采用了定時增量日志備份來完成，即內存數據庫每隔1秒鐘（這個時間間隔可以任意設置）會將每次對數據進行的修改操作以XML格式存儲為操作日志文件。如果發生斷電事故，最多會丟失1秒鐘內未及時保存到磁盤的操作日志，因此可以將事故影響控制在可控范圍之內。

③存放形式。

內存中數據存放的方式有很多種選擇，如數組、鏈表、隊列、哈希表、字典等。通過對數據操作的分析，緩存服務形式就是以最快的速度響應網站程序層的讀寫請求，所以最重要的因素就是從海量數據中定位單條數據的速度，因此哈希表是承載數據的最佳形式。

④數據查詢。

內存表在建立后查詢操作是通過在哈希表中建立關鍵碼來完成的，查詢效率很高。在考生數據表中，我們通過初始化在具有唯一性的考生號來設立關鍵碼并預留查函數接口來構建查詢語句，根據通訊模塊調用傳遞的參數篩選符合條件的數據并返回。

（2）通訊模塊。

通訊模塊實現了數據緩存層與網絡程序層之間的交互，因此該模塊最為關鍵之處就是要建立一個可靠、高效的監聽、應答機制。我們采用了WCF服務去完成這種監聽應答機制。WCF（Windows Communication Foundation）是由微軟公司發展的一組數據通信的應用程序開發接口，WCF構建了一個在互聯系統中實現各個應用程序之間通信的分布式框架。在該框架內數據緩存層的通訊模塊與網站程序層的數據訪問類之間通過契約實現數據請求操作，與訪問請求發起者無關，從而使網站程序層的每臺服務器進行的訪問操作都是相互的獨立的，為網站程序層的可擴展性提供了保障。

（3）調度模塊。

該模塊負責數據緩存增量日志的定時備份；負責將數據緩存模塊保存的數據改動文件寫入到數據庫層中，將數據持久化。調度模塊負責內存數據庫與SQLSEVER數據庫之間的同步，是數據緩存層與數據庫層之間的橋梁。

調度模塊的運行機制是：數據緩存模塊每1秒鐘將發生變化的數據以一個XML文件的形式寫入磁盤中，調度模塊每隔5秒中（時間可以自行設定）將這些文件讀取寫并將這些操作寫入數據庫，然后這些XML文件壓縮打包后移動到磁盤中設定的備份目錄中。在大并發訪問發生時，因數據庫操作寫入速度遠比不上內存數據庫的操作速度，這時會發生待寫入XML文件的積攢的現象，但是只要有內存數據庫操作量較小于數據庫寫入的時段出現，這部分積攢的操作文件就可以按時間順序被逐漸寫入。通過這樣的原理，數據緩存層為數據庫層起到了緩沖的作用。

通過這樣的運行機制數據緩存層會在運行過程中就會產生一個可操作的數據庫副本和一個日志副本，這時如果數據庫發生故障，我們可以將保存的xml文件解壓后重新寫入到數據中，為系統的數據安全性提供了雙重保障。

由于數據緩存層的操作量會很大，要將這些操作保存在文件中，這就涉及到內存對象序列化。使用xml序列化內存對象，結果簡潔，讀寫效率高，同時也便于在一個文件中序列化多條數據，如圖4所示。

3 數據庫層

在網報系統中，由于采用了數據緩存層的設計，數據操作壓力集中在了內存數據庫中，而SQLSERVER僅作為數據持久存儲和少量的管理用數據查詢挖掘使用，因此網報系統中僅使用了一臺服務器作為數據庫服務器使用。

4 系統測試

構建測試環境

為了詳盡的對網報系統進行測試，確保系統的穩定運行。我們構建一個較為接近實際情況的運行實驗環境。該環境包括以下幾點。

（1）網報系統部署：測試環境中使用了7臺HP服務器。分配為：WEB服務器4臺，部署相同的網站程序層；WCF服務器2臺，一臺部署通訊模塊和數據緩存模塊，一臺部署調度模塊并且用于XML文件備份；數據庫服務器1臺，部署數據庫層。服務器部署情況如圖5所示。

（2）網絡部署：采用實際應用狀態下網絡拓撲結構，通過F5對WEB服務器進行負載均衡，具體網絡結構如圖6所示。

（3）測試服務器：采用1臺HP580服務器，用于測試軟件安裝，測試工具LoadRunner （V8.1）。

（4）測試方法：本次測試包括功能測試和性能測試。

功能測試：即黑盒測試，測試人員在了解被測評目標的功能規格、高層設計和操作規范等的基礎上，測試被測系統的可用性。

性能測試：對系統在多種并發連接數情況下的處理能力進行測試。本次測試主要采用Dynamic workload（動態負載模型）逐步增加并發用戶數，給系統逐步加載壓力，并且讓系統在該負載條件下持續運行一段時間，然后逐漸減少并發用戶數，檢驗被測系統是否能夠穩定運行，同時監測Web服務器和緩存服務器的性能。

志愿填報測試。

（1）測試目的。

分別測試從網站程序層內網單臺web服務器接入和外網4臺WEB服務器負載均衡接入網上填報志愿系統，測試在多用戶并發登錄時的處理能力。

（2）測試步驟。

①從內網單臺WEB服務器接入網報系統，驗證系統“志愿填報和修改”功能可用。

②利用LoadRunner錄制并保存為“tiaobao”的腳本，對腳本中實時參數VIEWSTATE和考生考號進行參數化。

③啟動LoadRunner負載生成器，加載“tianbao”腳本，設置并發用戶數為200，設置持續運行時間為“5 min”，并且選擇“運行前初始化所有Vuser”。

④執行負載測試，運行完成后，啟動“Mercury LoadRunner Analysis”生成并保存測試結果。

⑤依次調整步驟③中的并發用戶數為200、500、1000、1500、2000、2500，并分別重復步驟③～步驟④。

⑥從外網通過F5負載均衡4臺WEB服務器接入網報系統，并分別重復步驟②～步驟⑤，由于會話保持策略會持續將訪問指向同一臺服務器，此時將會話保持和session驗證均去掉，采用隨機發牌模式測試。

測試結果如表1所示，事物響應時間對比如圖7、8所示。

5 測試結果分析

測試期間在上述壓力條件下，從內網單臺服務器接入，占用了200 Mbps的帶寬，服務器CPU滿負荷運行，系統運行正常。從外網負載均衡接入，此時由4臺服務器共同負載，占用了500 Mbps的帶寬，服務器CPU資源有富余，平均事務響應時間遠低于內網，但性能沒有出現理論上的4倍提升，由此可見網絡設備會帶來一定的效率損耗，應用系統自身運行正常。性能測試完成后，CPU和內存占用均回落至正常水平，未出現內存泄露現象。

通過測試看出WCF數據緩存層成功的實現了高并發負載下的內存數據庫功能，在數據庫操繁忙的情況下為數據庫起到了緩沖的作用。通過F5負載均衡設備成功實現了WEB服務器的負載均衡，雖然單臺WEB服務器有一定的效率損耗，但是卻帶來了網站程序層的可擴展性，實戰狀態下如果系統出現負荷過高的情況，只需增加WEB服務器的數量即可實現系統性能的提升。

6 結論

實踐證明，對網報系統進行分層，網站程序進行可擴展設計和把內存數據庫作為向數據庫中寫入數據前的緩沖的思路，能很好的增加網上填報志愿系統一類的大數據量的網上應用程序的吞吐能力，從而完成高并發負載的網上填報志愿需求。不足之處是，這種形式需要占用大量的內存，對服務器內存有一定的硬件要求。在方案思路的基礎上還可以對以下幾方面進行完善。

（1）考慮將數據緩存層轉化為分布式應用系統從而增強其負載的數據量和安全性。

（2）數據在內存中的保存形式針對具體的業務應用做進一步的優化，在性能上還有挖掘的潛力。

（3）Xml數據文件在保存在磁盤上的操作可以考慮放在固態硬盤上可以能進一步提高讀寫性能。

參考文獻

[1]奚江華.圣殿祭司的ASP.NET3.5開發詳解II[M].電子工業出版社，2008.

[2]金益民.一種基于XML的WEB數據庫應用模型研究及應用[J].現代電子技術，2004.

[3]蔣金楠.WCF技術剖析[M].電子工業出版社，2009，6.

[8]曾凱，曾斌，楊英，等.擴展SQL跟蹤數據技術在數據性能診斷上的應用[J].計算機應用與軟件，2006，23（1）：128-130.

[9]盧成均.多層模式下通用數據存取層的設計與實現[J].計算機工程與設計，2007，28（13）：3265-3269.

[10]Andrews A，Offutt J，Alexander R.Testing Web applications by modeling with FSMS[J].Software Systems and Modeling，2005，4（3）：326-345.

[11]王昌輝，王遠景.基于URL路徑的Web信息檢索模型的研究[J].貴州教育學院學報（自然科學），2008，19：36-39.

[12]尚俊杰，秦衛中.ASP.NET程序設計案例教程[M].北京：清華大學出版社，2005.