轉好文---基於Asp.net的高考填報志願系統高併發負載解決方案

地址:http://www.xzbu.com/8/view-4288184.htm

摘 要：本文以當前全國各省普通高考網上填報系統因併發量太高而極易形成網站的癱瘓的現象着手，設計了普通高校招生網上填報志願系統的高併發負載解決方案。本 系統在儘量的採用傳統的網站高併發負載優化策略的同時，還針對系統自己的特色從宏觀架構及微觀技術實現手段上都加以研究分析，制定針對網上填報志願系統 的高負載解決方案。宏觀上本系統利用了面向服務的程序設計方式將系統分爲網站程序層、數據緩存層、數據庫層的三層進行設計，實現了系統中應用程序、數據操 做、數據存儲上的物理及邏輯分離，所以系統應對高併發負載具備了分佈式解決能力，實現了系統的可擴展性。微觀上，本系統利用了目前許多提升系統性能的新技 術新方法，使網站程序運行具備了高效性。本系統的有如下幾個特色及創新：（1）架設數據緩存庫服務器，創建完善的內存數據緩存管理機制，利用面向服務的技 術進行網站程序和數據緩存之間的通信。（2）WEB程序與數據庫隔離，增長系統的安全性。（3）軟件程序負載均衡與硬件負載均衡結合應對大併發訪 問。（4）WEB服務器設置內存字典，使用哈希表進行數據映射，解決頻繁數據查詢。（5）網站程序層、數據緩存層、數據庫層的分層結構設計，方便系統擴 展。經過測試和實踐證實，使用多種方法對WEB程序進行優化設計及把內存數據庫做爲向數據庫中寫入數據前的緩衝的思路，能很好的增長網上填報志願系統一類 的大數據量的網上應用程序的吞吐能力，從而完成高併發負載的網上填報志願需求。
中國論文網 http://www.xzbu.com/8/view-4288184.htm
　　關鍵詞：高併發 負載 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所示，事物響應時間對好比圖七、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.