車站車票管理系統(tǒng)

摘 要隨著當(dāng)今社會(huì)信息技術(shù)的高速發(fā)展，計(jì)算機(jī)技術(shù)在交通方面的應(yīng)用更加明顯，尤其是在車站的管理系統(tǒng)的應(yīng)用。通過(guò)不同地點(diǎn)的客戶端訪問(wèn)票務(wù)中心的服務(wù)器，實(shí)現(xiàn)全國(guó)車票的統(tǒng)一管理。本文根據(jù)具體的車站管理以及票務(wù)管理，運(yùn)用基于IOCP（完成端口）模型實(shí)現(xiàn)的模擬車站管理系統(tǒng)，通過(guò)VC+ 6.0編譯器和SQL Server 2000數(shù)據(jù)庫(kù)管理系統(tǒng)，模擬車站管理系統(tǒng)的功能特點(diǎn)、程序的編寫(xiě)和編譯過(guò)程，給出了系統(tǒng)的需求分析、設(shè)計(jì)與實(shí)現(xiàn)，從售票、訂票，退票，查詢票信息、車輛調(diào)度、設(shè)置等多方面對(duì)系統(tǒng)做了設(shè)計(jì)與分析。售票員管理售票，訂票等票務(wù)服務(wù)，車輛調(diào)度員實(shí)現(xiàn)對(duì)車輛的調(diào)度管理，普通客戶對(duì)票的查詢。經(jīng)測(cè)試，系統(tǒng)運(yùn)行穩(wěn)定，能基本滿足車站對(duì)系統(tǒng)在功能和性能上的需求。關(guān)鍵字：車站管理系統(tǒng)，數(shù)據(jù)庫(kù)管理系統(tǒng)，套接字，完成端口模型，多線程AbstractAlong with the rapid development of modern information technology, the computer technology is more obvious in the transportation aspects application，especially in management system management systems application。Visits the ticket clerk center through the different places client side server，realizes the national ticket global administration。Manage according to the concrete station management as well as the ticket clerk ，utilization simulation station management system management system which (Complete Port) the model realizes based on IOCP , through the VC+ 6.0 compilers and SQL Server 2000 database management system , simulates the station management system management systems function characteristic , procedure compilation and compilation process, has given systems demand analysis, the design with realizes, from the booking, the order form, return a ticket, the inquiry ticket information, the vehicles dispatch, the establishment and so on multi-aspects have made the design and the analysis to the system. The ticket seller manages the booking, orders ticket and so on ticket clerks to serve, the dispatcher realizes to vehicles dispatch management, ordinary customer to ticket inquiry. After the test, the systems operation is stable, can satisfy the station basically to the system in the function and the performance demand.Keywords：Station management system management system, DBMS, Socket, Complete port，Multithreading44摘 要IAbstractII1 緒 論1.1 課題背景31.2課題研究目的和意義31.3 開(kāi)發(fā)目標(biāo)42 可行性研究2.1經(jīng)濟(jì)可行性52.2技術(shù)可行性52.3操作可行性53需求分析3.1任務(wù)概述63.2功能需求分析63.2.1系統(tǒng)管理63.2.2調(diào)度管理63.2.3票務(wù)管理73.3 數(shù)據(jù)流圖84概要設(shè)計(jì)4.1 系統(tǒng)整體框架設(shè)計(jì)104.2系統(tǒng)流程圖104.3 系統(tǒng)用例114.4售票訂票流程圖124.5活動(dòng)圖134.6序列圖155詳細(xì)設(shè)計(jì)5.1服務(wù)器設(shè)計(jì)165.1.1線程模型。165.1.2 SOCK模型175.1.3通信數(shù)據(jù)幀格式和粘連包處理215.2客戶端程序設(shè)計(jì)285.3客戶端未來(lái)展望29六 數(shù)據(jù)庫(kù)設(shè)計(jì)6.1數(shù)據(jù)庫(kù)概念設(shè)計(jì)316.2 數(shù)據(jù)庫(kù)的邏輯設(shè)計(jì)336.3 數(shù)據(jù)庫(kù)的實(shí)現(xiàn)336.4數(shù)據(jù)庫(kù)訪問(wèn)356.4.1數(shù)據(jù)庫(kù)訪問(wèn)技術(shù)簡(jiǎn)介356.4.2數(shù)據(jù)庫(kù)訪問(wèn)技術(shù)比較36七 系統(tǒng)結(jié)果分析7.1 服務(wù)器啟動(dòng)界面397.2 登陸窗口397.3 售票397.4車票查詢407.5退票查詢418總結(jié)與展望429致 謝43參考文獻(xiàn)44 1 緒 論1.1 課題背景在當(dāng)今社會(huì)，計(jì)算機(jī)占據(jù)了非常重要的位置，這些大部分都是通過(guò)使用軟件而提高生產(chǎn)、管理效率來(lái)體現(xiàn)的。本文研究的火車站售票系統(tǒng)正好就是這樣性質(zhì)的一個(gè)軟件。鐵路運(yùn)輸一直都是我國(guó)重要的經(jīng)濟(jì)命脈，而且由于我國(guó)是內(nèi)陸國(guó)家，這鐵路運(yùn)輸?shù)囊饬x就顯得更加突出了，對(duì)于這樣重要的一件事，當(dāng)然需要良好的管理了。經(jīng)過(guò)幾十年的發(fā)展，事實(shí)早就證明了使用計(jì)算機(jī)軟件來(lái)輔助自己比單純的人工處理手段高明的多，在這樣的背景下，研究這樣的課題的意義也就不言而喻了。在以前，像售票這樣的事，都是人工處理的，人工處理的缺點(diǎn)是顯而易見(jiàn)的，成本大、處理的速度慢、出錯(cuò)的幾率比較大，效率是很低的?，F(xiàn)在，在世界各國(guó)，火車售票使用的基本上都是員工操作計(jì)算機(jī)的模式，在這里，計(jì)算機(jī)主要是借助軟件用來(lái)存儲(chǔ)、更新數(shù)據(jù)的，并有統(tǒng)計(jì)帳目的功能。嚴(yán)格的說(shuō)，這并不是智能化，但是，這樣的處理模式比已往的人工處理的好處顯然還是很明顯的，所有的數(shù)據(jù)都由數(shù)據(jù)庫(kù)管理，可以隨時(shí)動(dòng)態(tài)的提取、存儲(chǔ)數(shù)據(jù)，并可以將修改后的數(shù)據(jù)覆蓋掉原有的數(shù)據(jù)。所以，開(kāi)發(fā)火車站售票系統(tǒng)軟件是很有意義、有必要的。1.2課題研究目的和意義(1)研究目的為了應(yīng)對(duì)交通運(yùn)輸行業(yè)的迅猛發(fā)展，尤其是火車運(yùn)輸業(yè)的發(fā)展和適應(yīng)實(shí)名制后顧客買票的問(wèn)題，針對(duì)不同類型不同規(guī)模的售票點(diǎn)，開(kāi)發(fā)實(shí)時(shí)，高效，智能的火車票售票系統(tǒng)顯得尤為重要。本次系統(tǒng)就是在實(shí)際考察火車站售票過(guò)程在實(shí)踐調(diào)查情況下提出的，旨在模擬現(xiàn)有的火車站工作流程并且加入新的功能，做到實(shí)時(shí)，安全，廣泛。目前全國(guó)火車售票系統(tǒng)已日趨完善，并且已經(jīng)對(duì)實(shí)名制進(jìn)行了改進(jìn)，但是客戶自主購(gòu)買車票和預(yù)訂車票問(wèn)題并不理想，由于網(wǎng)頁(yè)響應(yīng)速度慢，所以我想將此系統(tǒng)做成C/S工作模式，運(yùn)用visual C +開(kāi)發(fā)工具開(kāi)發(fā)出實(shí)時(shí)的售票系統(tǒng)，以滿足客戶自主買票的需求。(2)研究意義火車站市場(chǎng)的管理和規(guī)范問(wèn)題，是困擾我們多年的一個(gè)老問(wèn)題，也是政府管理中的一個(gè)難點(diǎn)，訂票是客運(yùn)業(yè)務(wù)中的一個(gè)最基本的業(yè)務(wù)，表面上看，它只是火車站業(yè)務(wù)的一個(gè)簡(jiǎn)單的部分，但是它涉及到管理與客戶服務(wù)等多方面，因此，過(guò)去傳統(tǒng)的售票方式已經(jīng)不能滿足現(xiàn)代客運(yùn)業(yè)務(wù)流量劇增的客觀要求，這就要求一種全新的訂票方式網(wǎng)上訂票，來(lái)緩解訂票高峰時(shí)期的客運(yùn)壓力，并為用戶提供方便快捷的訂票服務(wù)。本次設(shè)計(jì)便是利用開(kāi)發(fā)工具Visual c+ 6.0和SQL Server同開(kāi)發(fā)的一個(gè)火車站網(wǎng)上訂票系統(tǒng)，它能方便快捷地運(yùn)用在火車站訂票業(yè)務(wù)的營(yíng)運(yùn)之中。1.3 開(kāi)發(fā)目標(biāo)本系統(tǒng)開(kāi)發(fā)意在實(shí)現(xiàn)售票員快速、準(zhǔn)確、方便地的完成查詢、售票、改簽、退票等操作，使得顧客短時(shí)間內(nèi)獲取所需的準(zhǔn)確信息、節(jié)約時(shí)間，最終提高顧客滿意程度。另外，本系統(tǒng)還可對(duì)運(yùn)價(jià)、車次、終點(diǎn)進(jìn)行調(diào)整，對(duì)各類報(bào)表進(jìn)行維護(hù)和統(tǒng)計(jì)，有利于鐵道部門(mén)分析報(bào)表結(jié)果適時(shí)作出路線、車次、票價(jià)的調(diào)度，最終實(shí)現(xiàn)鐵路線路保持暢通運(yùn)行，為旅客提供優(yōu)質(zhì)滿意的服務(wù)。其次，本系統(tǒng)可減少一定人力資源，一名售票員或一個(gè)窗口可以“同步”完成查詢、售票、改簽以及退票等所有基本功能；本系統(tǒng)界面操作簡(jiǎn)單，功能全面，能夠很好滿足火車站售票需求。這樣，可以有效的利用適當(dāng)?shù)娜肆ν瓿苫疖囌镜母鞣N服務(wù)。最后，本系統(tǒng)還提供功能強(qiáng)大的管理功能，即實(shí)現(xiàn)人員、車次、運(yùn)價(jià)、終點(diǎn)站的修改以及各類報(bào)表的維護(hù)和打印，方便鐵道部門(mén)信息管理。2 可行性研究該階段通過(guò)對(duì)系統(tǒng)目標(biāo)的初步調(diào)研和分析，提出可行性方案并進(jìn)行論證。我們?cè)谶@里主要從技術(shù)可行性、經(jīng)濟(jì)可行性和操作可行性三方面進(jìn)行分析。2.1經(jīng)濟(jì)可行性開(kāi)發(fā)該系統(tǒng)所需的相關(guān)資料可以通過(guò)已存在的網(wǎng)上訂票系統(tǒng)進(jìn)行調(diào)查采集,所需的其他應(yīng)用軟件、硬件系統(tǒng)也易于獲得.因此,開(kāi)發(fā)成本較低。而引進(jìn)使用本系統(tǒng)后，與傳統(tǒng)方式相比，具有高效率、低成本、高質(zhì)量的特點(diǎn)，可以節(jié)省不少人力、物力及財(cái)力。所以，從經(jīng)濟(jì)的角度來(lái)看，該系統(tǒng)可行。2.2技術(shù)可行性開(kāi)發(fā)工具：Visual C+ 6.0數(shù)據(jù)庫(kù)環(huán)境：SQL Server 2000系統(tǒng)環(huán)境：Microsoft Windows XP系統(tǒng)實(shí)現(xiàn)依靠相對(duì)熟悉的C+語(yǔ)言和SQL Server2000數(shù)據(jù)庫(kù)系統(tǒng)，其基本操作實(shí)質(zhì)還是對(duì)數(shù)據(jù)庫(kù)進(jìn)行添加、刪除、查找等操作,具體技術(shù)問(wèn)題后面討論。2.3操作可行性系統(tǒng)采用菜單式，實(shí)現(xiàn)用戶與數(shù)據(jù)庫(kù)的交互，界面簡(jiǎn)潔友好，操作方便。用戶只需對(duì)訂票流程和業(yè)務(wù)調(diào)查了解即可，不需掌握數(shù)據(jù)庫(kù)等相關(guān)知識(shí)。3需求分析3.1任務(wù)概述車站是發(fā)行車票、提供車輛從而方便旅客出行的單位。車站售票系統(tǒng)在正常運(yùn)行中需要使用的主要是售票員、調(diào)度人員、車站管理人員和系統(tǒng)維護(hù)人員。其主要業(yè)務(wù)包括訂票、售票、退票和補(bǔ)票等?；诎踩院推渌鞣矫娴脑蚩紤]，本售票系統(tǒng)設(shè)計(jì)成C/S模式。車站客運(yùn)系統(tǒng)的主要流程是：根據(jù)客流的分布情況制定票額分配計(jì)劃和車輛的調(diào)度信息，通過(guò)預(yù)定、發(fā)票等方式售出車票，并就車票出售情況做出關(guān)于售票的財(cái)務(wù)統(tǒng)計(jì)報(bào)表、客運(yùn)統(tǒng)計(jì)報(bào)表。而由統(tǒng)計(jì)產(chǎn)生的數(shù)據(jù)將成為客流分析的基本數(shù)據(jù)。對(duì)于旅客來(lái)說(shuō)，想要買票先到車站的售票大廳向售票員查詢相關(guān)的車次信息，若有票則出示身份證件可以現(xiàn)場(chǎng)購(gòu)買，若旅客不方便出行則可以打電話到車站訂票，此時(shí)需要身份證號(hào)碼和聯(lián)系電話。對(duì)于售票員來(lái)說(shuō)根據(jù)旅客的訂票信息在規(guī)定的時(shí)間內(nèi)提醒旅客持身份證前來(lái)買票。3.2功能需求分析3.2.1系統(tǒng)管理（1）用戶權(quán)限：本售票系統(tǒng)的用戶包括售票員、調(diào)度員、車站內(nèi)部的高級(jí)管理人員和系統(tǒng)維護(hù)人員。不同的人員登錄系統(tǒng)時(shí)選擇不同的用戶角色，不同的角色具有不同的權(quán)限。售票員的權(quán)限是進(jìn)入車票數(shù)據(jù)庫(kù)查看車票信息并修改車票的狀態(tài)；調(diào)度員登錄系統(tǒng)主要是安排車輛及車次的調(diào)度信息；管理人員包括車站領(lǐng)導(dǎo)及財(cái)務(wù)管理人員，財(cái)務(wù)管理人員主要是看每個(gè)售票員的售票信息和車票狀態(tài)；系統(tǒng)維護(hù)人員主要是檢查系統(tǒng)對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份工作。（2）站點(diǎn)管理主要是考慮每條線路上車輛的其起始站點(diǎn)及停靠站點(diǎn)。3.2.2調(diào)度管理（1）車次調(diào)度：車次調(diào)度包括車次的增加、刪除和調(diào)整。車站根據(jù)客流的分布情況制定每條線路上的車次信息，當(dāng)某段時(shí)間某條線路上客流過(guò)多或過(guò)少時(shí)車站就需要增加或刪除一些車次，調(diào)整是指根據(jù)特殊情況延遲或提前某次車的發(fā)車時(shí)間。（2）線路管理：包括增加線路、修改線路、刪除線路和調(diào)整線路，車站調(diào)研人員根據(jù)客流的分布情況做出開(kāi)辟某些新線路、刪除原有線路或修改某些線路。（3）票價(jià)管理：包括審定票價(jià)、修改票價(jià)和線路票價(jià)浮動(dòng)。3.2.3票務(wù)管理 （1）訂票：旅客訂票有兩張方式：一是電話預(yù)定，旅客將車票信息告知售票員，售票員登錄系統(tǒng)查詢車票信息，若有票旅客需要留下身份證號(hào)碼和聯(lián)系電話方便旅客買票；二是到車站訂票，步驟同上。（2）退票：旅客因特殊原因需要退票，則需要在規(guī)定的時(shí)間內(nèi)攜帶原車票和身份證到車站去退票并繳納退票手續(xù)費(fèi)。（3）售票：售票員根據(jù)訂票信息通過(guò)旅客留下的電話號(hào)碼聯(lián)系快到時(shí)間而未來(lái)買票的旅客來(lái)買票，同時(shí)為直接買票的旅客打印車票。（4）補(bǔ)票：客戶因某種原因車票丟失了，應(yīng)先持身份證到制定地點(diǎn)掛失車票，經(jīng)過(guò)掛失的車票在檢票的時(shí)候不能通過(guò)，然后根據(jù)原有車票信息打印新的車票，旅客需要繳納一定的手續(xù)費(fèi)。圖3.1 系統(tǒng)功能圖3.3 數(shù)據(jù)流圖圖3.2 頂層圖圖3.3 售票0層圖圖3.4 訂票1層圖圖3.5 售票1層圖圖3.6 退票1層圖4概要設(shè)計(jì)4.1 系統(tǒng)整體框架設(shè)計(jì)本系統(tǒng)將采取C/S三層架構(gòu)模式實(shí)現(xiàn)對(duì)車站的管理，服務(wù)器主用完成端口模型實(shí)現(xiàn)，客戶端用基于對(duì)話框的框架進(jìn)行設(shè)計(jì)。只有服務(wù)器能直接訪問(wèn)數(shù)據(jù)庫(kù)，保證了數(shù)據(jù)庫(kù)的安全性。圖4.1 系統(tǒng)框架圖4.2系統(tǒng)流程圖本系統(tǒng)具體的操作流程是用戶輸入自己的登陸信息，登陸成功后，售票員進(jìn)入票務(wù)操作界面，車站管理員進(jìn)入管理界面，普通用戶不需登陸，這樣可以理解為自助機(jī)。在售票界面，售票員、車站管理員和普通用戶都可以進(jìn)行車票查詢，但是只有售票員才能進(jìn)行售票，車票預(yù)訂在售票員和普通用戶權(quán)限下都可以進(jìn)行操作。車站管理員可以對(duì)車次，車票，車站，路線進(jìn)行相應(yīng)管理。具體流程見(jiàn)圖：不同人員售票系統(tǒng)數(shù)據(jù)庫(kù)提供所需信息查詢數(shù)據(jù)庫(kù)顯示查詢結(jié)果反饋給購(gòu)票者圖4.2 流程圖4.3 系統(tǒng)用例用例圖用于顯示若干角色以及這些角色與系統(tǒng)提供的用例之間的連接關(guān)系。用例模型是把應(yīng)滿足用戶需求的基本功能聚合起來(lái)表示的強(qiáng)大工具，對(duì)于正在構(gòu)造的新系統(tǒng)，用例描述系統(tǒng)應(yīng)該作什么，對(duì)于已構(gòu)造完畢的系統(tǒng)，用例則反映了系統(tǒng)能夠完成什么樣的功能。用例模型的基本組成部件是用例、角色和系統(tǒng)。用例用于描述胸膛那個(gè)的功能，也就是從外部用戶的角度觀察，系統(tǒng)應(yīng)支持哪些功能，幫助分析人員理解系統(tǒng)的行為，他是對(duì)系統(tǒng)功能的宏觀描述。一個(gè)完整的系統(tǒng)中通常包含若干個(gè)用例，每個(gè)用例具體說(shuō)明應(yīng)完成的功能，代表系統(tǒng)的所有基本功能。角色是與系統(tǒng)進(jìn)行交互的外部實(shí)體，它可以是系統(tǒng)用戶，也可以是其他系統(tǒng)或硬件設(shè)備，總之，凡是需要與系統(tǒng)進(jìn)行交互的任何東西都可以稱作角色。系統(tǒng)的邊界線以內(nèi)的區(qū)域則抽象表示系統(tǒng)能夠?qū)崿F(xiàn)的所有基本功能。在用例模型中，系統(tǒng)仿佛是實(shí)現(xiàn)各種用例的“黑盒子”，我們只關(guān)心該系統(tǒng)實(shí)現(xiàn)了哪些功能，并不關(guān)心內(nèi)部的具體實(shí)現(xiàn)細(xì)節(jié)。根據(jù)本系統(tǒng)的需求分析，本系統(tǒng)中存在的角色：售票員，車站管理員，普通客戶，打印機(jī)。所以可得到系統(tǒng)的用例圖。如圖圖4.3 用例圖對(duì)于本系統(tǒng)而言，具體功能是非常多的，此處只列舉售票操作的圖。4.4售票訂票流程圖售票訂票是本系統(tǒng)最基本的功能，售票功能的流程是：售票員登陸，根據(jù)客戶提供的車次或者是車站信息對(duì)車票進(jìn)行查詢，有票時(shí)向客戶進(jìn)行售票，系統(tǒng)修改數(shù)據(jù)庫(kù)，打印機(jī)打印車票。訂票可以客戶在自助機(jī)上進(jìn)行，也可以由售票員進(jìn)行。訂票功能的流程是：客戶在自助機(jī)上根據(jù)車次或車站信息對(duì)車票進(jìn)行查詢，有票時(shí)展現(xiàn)車票信息和余票信息，客戶自助訂票，系統(tǒng)修改數(shù)據(jù)庫(kù)，產(chǎn)生訂單。圖4.4 售票訂票流程圖4.5活動(dòng)圖活動(dòng)圖顯示動(dòng)作及其結(jié)果。活動(dòng)圖著重描述操作實(shí)現(xiàn)中所完成的工作以及用例實(shí)例或?qū)ο笾械幕顒?dòng)。活動(dòng)圖是狀態(tài)圖的一個(gè)變種，與狀態(tài)圖的目的有一些小的差別，活動(dòng)圖的主要目的是描述動(dòng)作及對(duì)象狀態(tài)改變的結(jié)果。當(dāng)狀態(tài)中的動(dòng)作被執(zhí)行時(shí)，活動(dòng)圖中的狀態(tài)直接轉(zhuǎn)移到下一個(gè)階段。活動(dòng)圖和狀態(tài)圖的另一個(gè)區(qū)別是活動(dòng)圖中的動(dòng)作可以放在泳道中。泳道聚合一組活動(dòng)，并指定負(fù)責(zé)人和所屬組織?；顒?dòng)組是另一種描述交互的方式，描述采取何種動(dòng)作，做什么，何時(shí)發(fā)生，以及在何處發(fā)生。活動(dòng)圖可以用作下述目的：（1）描述一個(gè)操作執(zhí)行過(guò)程中（操作實(shí)現(xiàn)的實(shí)例化）所完成的工作（動(dòng)作）。這是活動(dòng)圖最常見(jiàn)的用途。（2）描述對(duì)象內(nèi)部的工作。（3）顯示如何執(zhí)行一組相關(guān)的動(dòng)作，以及這些動(dòng)作如何影響他們周圍的對(duì)象。（4）顯示用例的實(shí)例是如何執(zhí)行動(dòng)作以及如何改變對(duì)象狀態(tài)。（5）說(shuō)明一次活動(dòng)中的角色、工作流、組織和對(duì)象是如何工作的。圖4.5 活動(dòng)圖4.6序列圖序列圖描述對(duì)象是如何交互的，并且將重點(diǎn)放在消息序列上，也就是說(shuō)，描述消息是如何在對(duì)象間發(fā)送和接收德?tīng)枴Ｐ蛄袌D有兩個(gè)坐標(biāo)軸：縱坐標(biāo)軸顯示時(shí)間，橫坐標(biāo)軸顯示對(duì)象。序列圖也顯示特殊情況下的對(duì)象交互：在系統(tǒng)執(zhí)行期間的某一時(shí)間點(diǎn)發(fā)生在對(duì)象間的特殊交互。在序列圖的橫坐標(biāo)軸上是與序列有關(guān)的對(duì)象。每一個(gè)對(duì)象的表示方法是：矩形框中寫(xiě)有對(duì)象和/或類名，且名字下面有下劃線。同時(shí)，有一條縱向的虛線表示對(duì)象在序列中的執(zhí)行情況（即：發(fā)送和接收的消息，對(duì)象的活動(dòng)），這條虛線稱為對(duì)象的“生命線”。對(duì)象間的通信用對(duì)象的生命線之間的水平的消息線來(lái)表示。消息線的箭頭說(shuō)明消息的類型，如同步，異步或簡(jiǎn)單。瀏覽序列圖的方法是：從上到下查看對(duì)象交換的消息。圖4.6 序列圖5詳細(xì)設(shè)計(jì)5.1服務(wù)器設(shè)計(jì)服務(wù)器是本系統(tǒng)的核心模塊，其一端連接中心數(shù)據(jù)庫(kù)，另一端連接各客戶端節(jié)點(diǎn)，是系統(tǒng)的業(yè)務(wù)處理和信息交互的中心節(jié)點(diǎn)。其模型圖為：圖5.1 系統(tǒng)模型圖其穩(wěn)定性要求和響應(yīng)時(shí)間有較高要求。設(shè)計(jì)思想從以下幾個(gè)方面進(jìn)行描述：5.1.1線程模型。主線程為界面線程，當(dāng)啟動(dòng)服務(wù)時(shí)，系統(tǒng)創(chuàng)建監(jiān)聽(tīng)線程，用于監(jiān)聽(tīng)到達(dá)的客戶端連接，當(dāng)客戶端到達(dá)時(shí)，將客戶端信息等級(jí)到服務(wù)器的列表框中。監(jiān)聽(tīng)線程創(chuàng)建服務(wù)服務(wù)線程，此服務(wù)線程用于接收客戶端傳來(lái)的消息，對(duì)消息進(jìn)行分析，并將消息投遞到不同的業(yè)務(wù)線程中。根據(jù)不同的業(yè)務(wù)類型，服務(wù)線程創(chuàng)建三條業(yè)務(wù)線程，即時(shí)業(yè)務(wù)線程，非即時(shí)業(yè)務(wù)線程，查詢線程。具體的線程模型見(jiàn)圖：圖5.2 線程模型/創(chuàng)建三條業(yè)務(wù)線程m_pDoPacketThreadForSearch=new CDoPacketThreadForSearch;m_pDoPacketThreadForSearch-CreatThread();m_pDoPacketThreadForJiShi=new CDoPacketThreadForJiShi;m_pDoPacketThreadForJiShi-CreatThread();m_pDoPacketThreadForNotJiShi=new CDoPacketThreadForNotJiShi;m_pDoPacketThreadForNotJiShi-CreatThread();5.1.2 SOCK模型Windows平臺(tái)常用的模型有阻塞模型、select模型、WSAAsyncSelect模型、WSAEventSelect模型、Overlap模型、完成端口（IOCP）模型?？紤]到服務(wù)點(diǎn)的規(guī)模和采用多線程的特點(diǎn)，選用IOCP模型。根據(jù)業(yè)務(wù)類別分別基于TCP或UDP協(xié)議開(kāi)發(fā)。完成端口簡(jiǎn)介完成端口模型 (I/O completion ports)是迄今為止為復(fù)雜的一種I/O模型，假如一個(gè)程序需要管理為數(shù)多的套接字，那么采用這種模型往往可以達(dá)到最佳的系統(tǒng)性能,因其設(shè)計(jì)的復(fù)雜性,只有應(yīng)用程序需要同時(shí)管理數(shù)百乃至上千個(gè)套接字的時(shí)候,而且希望隨著系統(tǒng)內(nèi)安裝CPU 數(shù)量的增多,應(yīng)用程序的性能呈線性提升時(shí),才考慮采用完成端口模型。完成端口模型是唯一適用于高負(fù)載服務(wù)器的一種技術(shù)。我們可以把完成端口看成系統(tǒng)維護(hù)的一個(gè)隊(duì)列，操作系統(tǒng)把重疊IO操作完成的事件通知放到該隊(duì)列里。一個(gè)socket被創(chuàng)建后，可以在任何時(shí)刻和一個(gè)完成端口聯(lián)系起來(lái)，當(dāng)與完成端口相關(guān)聯(lián)的socket上的異步I/O 完成時(shí)，操作系統(tǒng)會(huì)向完成端口發(fā)送一個(gè)完成通知包。通過(guò)GetQueuedCompletionStatus()函數(shù)可以獲取I/O操作結(jié)果。由于一個(gè)完成端口能夠管理為數(shù)眾多的套接字，所以用完成端口編寫(xiě)的服務(wù)器程序能夠達(dá)到最佳的系統(tǒng)性能。而且隨著服務(wù)器CPU數(shù)量的增加，應(yīng)用程序的性能也會(huì)得到線形的提高。線程的數(shù)量一般來(lái)說(shuō)，一個(gè)應(yīng)用程序可以創(chuàng)建多個(gè)工作器線程來(lái)處理完成端口上的通知事件。但是在理想的情況下，應(yīng)該對(duì)應(yīng)一個(gè)CPU創(chuàng)建一個(gè)線程。因?yàn)樵谕瓿啥丝诶硐肽Ｐ椭?，每個(gè)線程都可以從系統(tǒng)獲得一定的時(shí)間片，輪番運(yùn)行并檢查完成端口。但是在實(shí)際開(kāi)發(fā)的時(shí)候，還要考慮這些線程是否牽涉到其他堵塞操作的情況。如果某線程進(jìn)行堵塞操作，系統(tǒng)則將其掛起，讓別的線程獲得運(yùn)行時(shí)間。因此，如果有這樣的情況，可以多創(chuàng)建幾個(gè)線程來(lái)盡量利用時(shí)間。重疊I/O 用完成端口編寫(xiě)的服務(wù)器程序有如此高的系統(tǒng)性能，重疊I/O功不可沒(méi)。比起阻塞的I/O操作，重疊I/O最大的優(yōu)勢(shì)是應(yīng)用程序投遞了一個(gè)發(fā)送或接受請(qǐng)求以后直接就返回。對(duì)于那種需要很長(zhǎng)時(shí)間才能完成的操作來(lái)說(shuō)，重疊I/O機(jī)制尤其有用，因?yàn)榘l(fā)起重疊操作的線程在重疊請(qǐng)求發(fā)出后就可以自由的做別的事情了。Windows Sockets 2引入了重疊I/O的概念并且要求所有的傳輸協(xié)議提供者都支持這一功能。重疊I/O僅能在由WSASocket()函數(shù)打開(kāi)的套接口上使用（使用WSA_FLAG_OVERLAPPED標(biāo)記）。對(duì)于接收數(shù)據(jù)，應(yīng)用程序使用WSARecv()函數(shù)來(lái)提供存放接收數(shù)據(jù)的緩沖區(qū)。如果數(shù)據(jù)在WSARecv()函數(shù)接收以前已經(jīng)到達(dá)套接字的接受緩沖區(qū)，那么調(diào)用WSARecv()函數(shù)，接收的數(shù)據(jù)就可以立即被存放進(jìn)用戶緩沖區(qū)，函數(shù)返回值是0，如果數(shù)據(jù)在WSARecv()函數(shù)接收之前沒(méi)有到達(dá)套接字的接受緩沖區(qū)，那么調(diào)用WSARecv()返回SOCKET_ERROR，并且錯(cuò)誤代碼是WSA_IO_PENDING，當(dāng)數(shù)據(jù)到來(lái)的時(shí)候，操作系統(tǒng)直接把數(shù)據(jù)拷貝進(jìn)應(yīng)用程序的緩沖區(qū)。發(fā)送函數(shù)WSASend()發(fā)送數(shù)據(jù)的時(shí)候，如果套接字的發(fā)送緩沖區(qū)有足夠的空間，那么將數(shù)據(jù)拷貝到套接字的發(fā)送緩沖區(qū)，函數(shù)返回值是0。如果套接字的發(fā)送緩沖區(qū)沒(méi)有空間，那么WSASend()返回SOCKET_ERROR，并且錯(cuò)誤代碼是WSA_IO_PENDING，在系統(tǒng)處理完套接字的發(fā)送緩沖區(qū)后，系統(tǒng)直接把數(shù)據(jù)交給了TCP，繞過(guò)了套接字的發(fā)送緩沖區(qū)。Overlapped的用法在重疊IO的過(guò)程中，Overlapped的使用非常重要，當(dāng)一個(gè)重疊IO被發(fā)起，一個(gè)Overlapped結(jié)構(gòu)體的指針就要作為參數(shù)傳遞給系統(tǒng)。當(dāng)操作完成，GetQueueCompletionStatus可以返回指向同一個(gè)Overlapped結(jié)構(gòu)的指針。為了辨認(rèn)和定位這個(gè)已完成的操作，開(kāi)發(fā)人員最好定義自己的Overlapped結(jié)構(gòu)，以包含一些自己定義的關(guān)于操作本身的額外信息。使用AcceptEx由于高性能的服務(wù)器在很短的時(shí)間內(nèi)要響應(yīng)大量的連接，所以采用AcceptEx函數(shù)。AcceptEx函數(shù)是微軟的Winsosk 擴(kuò)展函數(shù)，這個(gè)函數(shù)與accept的區(qū)別就是：accept是阻塞的，一直要到有客戶端連接上來(lái)后accept才返回，所以同時(shí)面對(duì)大量的連接，accept顯然難以滿足要求。而AcceptEx是異步的，直接就返回了，而且我們可以利用AcceptEx可以發(fā)出多個(gè)AcceptEx調(diào)用等待客戶端連接。另外，如果我們可以預(yù)見(jiàn)到客戶端一連接上來(lái)后就會(huì)發(fā)送數(shù)據(jù)，那么可以隨著AcceptEx投遞一個(gè)BUFFER進(jìn)去，這樣如果連接建立成功，就可以接收客戶端發(fā)出的數(shù)據(jù)到BUFFER里，這樣的話，一次AcceptEx調(diào)用相當(dāng)于accpet和recv的一次連續(xù)調(diào)用。IOCP工作流程：主線程工作流程1、創(chuàng)建一個(gè)I/O 完成端口；2、創(chuàng)建一個(gè)listen_socket并listen_socket添加到完成端口；3、將套接字綁定到一個(gè)已知的地址4、創(chuàng)建一個(gè)socket，調(diào)用AcceptEx（）函數(shù)，將socket作為AccpetEx的一個(gè)參數(shù)，用于下一個(gè)客戶機(jī)的連接。重復(fù)此步驟若干次。5、在listen_socket上用WSAEventSelect（）注冊(cè)FD_ACCEPT事件6、主線程進(jìn)入循環(huán)，等待listen_socket上的FD_ACCEPT事件7、如果發(fā)生FD_ACCEPT事件，則說(shuō)明已經(jīng)投遞的套接字已經(jīng)用完，則調(diào)用步驟5，再投遞一定數(shù)量的AcceptEx（），如果發(fā)生了WAIT_TIMEOUT時(shí)間，則調(diào)用CheckConnection()函數(shù)，刪除已經(jīng)連接但是沒(méi)有發(fā)送數(shù)據(jù)的socket。圖5.3 主線程圖工作者線程的步驟如下1、創(chuàng)建擴(kuò)展重疊結(jié)構(gòu)2、工作者線程循環(huán)調(diào)用GetQueuedCompletionStatus函數(shù)以獲取I/O操作結(jié)果；3、GetQueuedCompletionStatus()中WSAOVERLAPPED的結(jié)果來(lái)判斷完成端口上是接受到了新的連接、有數(shù)據(jù)接受，還是要發(fā)送數(shù)據(jù)。4、如果接受到了新的連接，將新套接字句柄用CreateIoCompletionPort函數(shù)關(guān)聯(lián)到完成端口，如果要接受數(shù)據(jù)則調(diào)用WSARecv（），如果要發(fā)送數(shù)據(jù)，調(diào)用WSASend（）。因?yàn)槭钱惒胶瘮?shù)，WSASend和WSARecv會(huì)直接返回，實(shí)際的發(fā)送或接收數(shù)據(jù)的操作由Windows 系統(tǒng)完成。圖5.4 工作線程圖5.1.3通信數(shù)據(jù)幀格式和粘連包處理TCP通信是基于數(shù)據(jù)流的，不區(qū)分邊界，可能出現(xiàn)粘連包，數(shù)據(jù)在傳輸過(guò)程中可能被竊取或篡改，數(shù)據(jù)幀的種類繁多等等，在設(shè)計(jì)數(shù)據(jù)幀時(shí)必須考慮到上述問(wèn)題。所以，在通信時(shí)的數(shù)據(jù)包中都包含了包長(zhǎng)、協(xié)議類型、校驗(yàn)和，數(shù)據(jù)通過(guò)相應(yīng)的加密算法加密。（1）數(shù)據(jù)幀格式如表5.1表5.1 數(shù)據(jù)幀格式表包長(zhǎng)（4字節(jié)）業(yè)務(wù)代碼（4字節(jié)）用戶數(shù)據(jù)段（K字節(jié)）校驗(yàn)和（8字節(jié)）數(shù)據(jù)幀包括4字節(jié)的包長(zhǎng)字段，4字節(jié)的業(yè)務(wù)字段，K字節(jié)的用戶數(shù)據(jù)字段，8字節(jié)的校驗(yàn)和。（2）粘連包處理方法由于車票管理的數(shù)據(jù)量是非常大的，多以出現(xiàn)粘連包是在所難免的，粘連包出現(xiàn)的問(wèn)題主要是半包問(wèn)題，所以必須解決這個(gè)問(wèn)題，在此方案中，處理粘連包的方法是，在服務(wù)器中存在4個(gè)包隊(duì)列：即時(shí)業(yè)務(wù)包隊(duì)列，非即時(shí)業(yè)務(wù)包隊(duì)列，查詢業(yè)務(wù)包隊(duì)列，半包隊(duì)列，首先取得包的前4個(gè)字節(jié)得到包應(yīng)該的長(zhǎng)度a，計(jì)算獲得包的總長(zhǎng)度b，如果a = b則是正常包，進(jìn)行正常處理，如果如果a b，則根據(jù)a的值在包中取得相應(yīng)長(zhǎng)度的數(shù)據(jù)，并將b的長(zhǎng)度減去a，然后循環(huán)如此，直到包結(jié)束或者是出現(xiàn)半包停止，若果a s=g_BaseObj.m_iter-s)/如果有就半包添加到收到的數(shù)據(jù)的開(kāi)始部位，并且報(bào)的長(zhǎng)度進(jìn)行改編char temp1024;memset(temp,0,1024);memcpy(temp,g_BaseObj.m_iter-msg,sizeof(g_BaseObj.m_iter-msg);strncpy(temp+sizeof(g_BaseObj.m_iter-msg),pPerIO-buf,nLen);strncpy(pPerIO-buf,temp,sizeof(temp);nLen=atoi(pPerIO-buf);/構(gòu)造消息節(jié)點(diǎn)if（nLenLen）MESSAGE MsgNode;MsgNode.s=pPerHandle-s;char tempbuf1024;ZeroMemory(tempbuf,0,1024);strncpy(tempbuf,pPerIO-buf+4,Len-4);MsgNode.msg.Format(%s,tempbuf); /去掉包長(zhǎng)字段（4字節(jié)）nLen-=Len;if (nLen!=0)strncpy(pPerIO-buf,pPerIO-buf+Len,nLen);pPerIO-bufnLen=0;memcpy(intLen,pPerIO-buf,4);Len=atoi(intLen);elsebreak;if (nLens;char tempbuf1024;ZeroMemory(tempbuf,0,1024);strncpy(tempbuf,pPerIO-buf,Len);MsgNode.msg.Format(%s,tempbuf); /去掉包長(zhǎng)字段（4字節(jié)）EnterCriticalSection(&g_BaseObj.m_cs_HalfPacket);g_BaseObj.m_MessageList_HalfPacket.push_front(MsgNode);LeaveCriticalSection(&g_BaseObj.m_cs_HalfPacket);g_BaseObj.m_HalfPacket+;break;（3）數(shù)據(jù)安全保障算法。中心數(shù)據(jù)庫(kù)由業(yè)務(wù)中間件定時(shí)維護(hù)，如果存放中心數(shù)據(jù)庫(kù)的硬盤(pán)損毀或出現(xiàn)無(wú)法訪問(wèn)的故障時(shí)，沒(méi)有備份的數(shù)據(jù)就會(huì)丟失。因此，在中間件執(zhí)行更改數(shù)據(jù)庫(kù)數(shù)據(jù)的指令時(shí)，相應(yīng)的SQL指令被存儲(chǔ)到一個(gè)按日期命名的文本文件中，且該文本文件與數(shù)據(jù)庫(kù)文件不在同一個(gè)硬盤(pán)上，這樣，一旦硬盤(pán)出現(xiàn)故障，數(shù)據(jù)庫(kù)無(wú)法訪問(wèn)時(shí)，執(zhí)行文本文件中的相應(yīng)SQL語(yǔ)句就可以恢復(fù)數(shù)據(jù)。這一塊具體沒(méi)有實(shí)現(xiàn)。（4）線程之間同步和互斥訪問(wèn)數(shù)據(jù)庫(kù)問(wèn)題由于數(shù)據(jù)量大且信息種類多樣，為了同時(shí)滿足對(duì)數(shù)據(jù)的讀取、存放和顯示，必須在軟件運(yùn)行期間開(kāi)啟多條線程進(jìn)行應(yīng)對(duì)。由于服務(wù)器中存在3條業(yè)務(wù)線程，服務(wù)線程需要向業(yè)務(wù)隊(duì)列中投遞業(yè)務(wù)，業(yè)務(wù)線程需要從業(yè)務(wù)隊(duì)列中取業(yè)務(wù)代碼，由于3條業(yè)務(wù)線程是異步執(zhí)行的，所以業(yè)務(wù)線程需要從而對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)就存在互斥訪問(wèn)問(wèn)題，以免出現(xiàn)數(shù)據(jù)混亂的局面。在window環(huán)境下，一個(gè)進(jìn)程等同于一個(gè)容器，而線程則是容器內(nèi)的實(shí)體，線程才是程序的最小執(zhí)行單元。對(duì)于進(jìn)程中，若多條線程在任意時(shí)刻都有可能訪問(wèn)到某個(gè)全局資源，那么這個(gè)全局資源被稱為是臨界資源。在這種情況下，必須保護(hù)臨界資源，多線程必須互斥的對(duì)其訪問(wèn)。在本監(jiān)控系統(tǒng)中，將多條線程做成類似生產(chǎn)者消費(fèi)者模型，滿足了系統(tǒng)對(duì)數(shù)據(jù)并發(fā)控制的需要。此模型的原理即是：一條線程負(fù)責(zé)生產(chǎn)數(shù)據(jù)，其他線程負(fù)責(zé)讀取由該線程生產(chǎn)的數(shù)據(jù)。只需對(duì)數(shù)據(jù)訪問(wèn)部分做到同步即可。為了解決線程同步問(wèn)題，win32 API提供了多種同步控制對(duì)象。包括：互斥對(duì)象、信號(hào)對(duì)象、事件對(duì)象、排斥區(qū)對(duì)象(關(guān)鍵代碼段)在介紹這些對(duì)象之前，必須先介紹等待函數(shù)，因?yàn)樗麄兌家褂玫却瘮?shù)。Win32 API提供了一組能使線程阻塞其自身執(zhí)行的等待函數(shù)。等待函數(shù)未返回時(shí)，線程處于等待狀態(tài)，此時(shí)線程只是消耗很少的CPU時(shí)間。使用等待函數(shù)既可以保證線程的同步，又可以提高程序的運(yùn)行效率。最常用的等待函數(shù)為：WaitForSingleObject, WaitForMultipleObjects。1）.Mutex對(duì)象的狀態(tài)在它不被任何線程擁有時(shí)才有信號(hào)。Mutex對(duì)象很適合用來(lái)協(xié)調(diào)多個(gè)線程對(duì)共享資源的互斥訪問(wèn)?？梢园凑障铝胁襟E使用該對(duì)象：.建立互斥對(duì)象，得到句柄:HANDLE CreateMutex()。.在線程可能產(chǎn)生沖突的區(qū)域前（即訪問(wèn)共享資源前）調(diào)用WaitForSingleObject()將句柄傳給函數(shù)，請(qǐng)求占用Mutex對(duì)象。.共享資源訪問(wèn)結(jié)束，釋放對(duì)Mutex對(duì)象的占用：ReleaseMutex(hMutex)。Mutex對(duì)象在同一時(shí)刻只能被一個(gè)線程占用，當(dāng)Mutex對(duì)象被一個(gè)線程占用時(shí)，若另一個(gè)線程想占用它，則必須等到前一個(gè)線程釋放。2）.信號(hào)對(duì)象允許同時(shí)對(duì)多個(gè)線程共享資源進(jìn)行訪問(wèn)，在創(chuàng)建對(duì)象時(shí)指定最大可同時(shí)訪問(wèn)的線程數(shù)。當(dāng)一個(gè)線程申請(qǐng)?jiān)L問(wèn)成功后，信號(hào)對(duì)象中的計(jì)數(shù)器減一，調(diào)用ReleaseSemaphore函數(shù)后，信號(hào)對(duì)象中的計(jì)數(shù)器加一。其中，計(jì)數(shù)器值大于或等于0，但小于或等于創(chuàng)建時(shí)指定的最大值。如果一個(gè)應(yīng)用在創(chuàng)建一個(gè)信號(hào)對(duì)象時(shí)，將其計(jì)數(shù)器的初始值設(shè)為0，就阻塞了其他線程，保護(hù)了資源。等初始化完成后，調(diào)用ReleaseSemaphore函數(shù)將其計(jì)數(shù)器增加至最大值，則可進(jìn)行正常的存取訪問(wèn)。 其使用步驟與Mutex對(duì)象類似，這里不再贅述。3）.事件對(duì)象(Event)是最簡(jiǎn)單的對(duì)象，它包括有信號(hào)和無(wú)信號(hào)兩種狀態(tài)。.創(chuàng)建事件對(duì)象HANDLE CreateEvent(NULL,FALSE,TRUE,NULL)/自動(dòng)重置事件HANDLE CreateEvent(NULL,TRUE,FALSE,NULL)/手工重置事件.在線程訪問(wèn)共享資源之前調(diào)用 WaitForSingleObject()。.重新設(shè)置成有信號(hào)狀態(tài) SetEvent(EVENT_HANDLE )。4）.排斥區(qū)對(duì)象 在排斥區(qū)中異步執(zhí)行時(shí)，它只能在同一進(jìn)程的線程之間共享資源處理。使用排斥區(qū)的方法則使同步管理的效率更高。.使用時(shí)先定義一個(gè)CRITICAL_SECTION結(jié)構(gòu)的排斥區(qū)對(duì)象: VOID InitializeCriticalSection(LPCRITICAL_SECTION)。.當(dāng)一個(gè)線程使用排斥區(qū)時(shí)，調(diào)用函數(shù)：EnterCriticalSection( ); .當(dāng)要求退出排斥區(qū)時(shí)，調(diào)用函數(shù)：LeaveCriticalSection( ); /釋放對(duì)排斥區(qū)對(duì)象的占用在這四種多線程同步的方法中，優(yōu)先選用關(guān)鍵代碼段（排斥區(qū)對(duì)象）方法。其使用簡(jiǎn)單且速度較快，而Mutex對(duì)象與事件對(duì)象等屬于內(nèi)核對(duì)象，運(yùn)行速度較慢。故本系統(tǒng)中采用第四種同步方法。考慮到本系統(tǒng)里需要用到的線程存在于一個(gè)進(jìn)程之中和5個(gè)臨界區(qū)，即即時(shí)業(yè)務(wù)隊(duì)列，非即時(shí)業(yè)務(wù)隊(duì)列，查詢業(yè)務(wù)隊(duì)列，半包隊(duì)列，數(shù)據(jù)庫(kù)訪問(wèn)這些對(duì)象對(duì)應(yīng)的關(guān)鍵區(qū)，所以采用關(guān)鍵代碼段來(lái)實(shí)現(xiàn)線程同步和互斥。在服務(wù)器開(kāi)啟服務(wù)的時(shí)候?qū)﹃P(guān)鍵區(qū)進(jìn)行初始化：InitializeCriticalSection(&g_BaseObj.m_cs_noJiShiTX);InitializeCriticalSection(&g_BaseObj.m_cs_jiShiTX);InitializeCriticalSection(&g_BaseObj.m_cs_search);InitializeCriticalSection(&g_BaseObj.m_cs_HalfPacket);InitializeCriticalSection(&g_BaseObj.m_cs_datebase);在停止服務(wù)時(shí)刪除關(guān)鍵區(qū)：DeleteCriticalSection(&g_BaseObj.m_cs_jiShiTX);DeleteCriticalSection(&g_BaseObj.m_cs_noJiShiTX);DeleteCriticalSection(&g_BaseObj.m_cs_search);DeleteCriticalSection(&g_BaseObj.m_cs_HalfPacket);DeleteCriticalSection(&g_BaseObj.m_cs_datebase);在需要訪問(wèn)臨界區(qū)的時(shí)候：業(yè)務(wù)線程從隊(duì)列中取走業(yè)務(wù)代碼：EnterCriticalSection(&g_BaseObj.m_cs_jiShiTX);if(!g_BaseObj.m_MessageList_jiShiTx.empty()/list操作，新元素插入list頭，取元素從list尾部msg_node=g_BaseObj.m_MessageList_jiShiTx.back(); g_BaseObj.m_MessageList_jiShiTx.pop_back();g_BaseObj.m_Jishi_Packet-; /即時(shí)交易包未處理數(shù)目elseLeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX); Sleep(10);continue;LeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX);服務(wù)線程向隊(duì)列中投遞業(yè)務(wù)：if(iBusinessType=0)/插入g_MessageList_jiShiTxEnterCriticalSection(&g_BaseObj.m_cs_jiShiTX);g_BaseObj.m_MessageList_jiShiTx.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_Jishi_Packet+; /即時(shí)交易包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX);else if(iBusinessType=1)/插入g_MessageList_noJiShiTxEnterCriticalSection(&g_BaseObj.m_cs_noJiShiTX);g_BaseObj.m_MessageList_noJiShiTx.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_NoJishi_Packet+;/非即時(shí)交易包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_noJiShiTX);else if (iBusinessType=2)/插入g_MessageList_SearchEnterCriticalSection(&g_BaseObj.m_cs_search);g_BaseObj.m_MessageList_Search.push_front(MsgNode);/list操作，新元素插入list頭，取元素從list尾部g_BaseObj.m_Search_Packet+;/查詢包未處理數(shù)目LeaveCriticalSection(&g_BaseObj.m_cs_search);（5）全局隊(duì)列和全局結(jié)構(gòu)的設(shè)計(jì)本系統(tǒng)中由于處理數(shù)據(jù)內(nèi)容是龐大的，所以應(yīng)該有相應(yīng)的結(jié)構(gòu)來(lái)存儲(chǔ)以便統(tǒng)一管理數(shù)據(jù)。并且由于本系統(tǒng)中幾乎所有的線程都需要用到一些數(shù)據(jù)結(jié)構(gòu)，所以將這些數(shù)據(jù)結(jié)構(gòu)存放在統(tǒng)一的類里，此類是一個(gè)全局類。類中包括的結(jié)構(gòu)有消息節(jié)點(diǎn)結(jié)構(gòu)：套接字信息，消息數(shù)據(jù)。套接字信息提供客戶端套接字，以便于服務(wù)器進(jìn)行操作之后向客戶端發(fā)送數(shù)據(jù)和粘連包的處理，消息數(shù)據(jù)即為客戶端發(fā)送的請(qǐng)求，包括4字節(jié)的包長(zhǎng)，8字節(jié)的校驗(yàn)和字段，K個(gè)字段的數(shù)據(jù)。/消息節(jié)點(diǎn)類typedef struct _messageSOCKET s;CString msg;MESSAGE,*PMESSAGE;業(yè)務(wù)節(jié)點(diǎn)結(jié)構(gòu)：業(yè)務(wù)代碼，業(yè)務(wù)類別。業(yè)務(wù)代碼是服務(wù)器與客戶端協(xié)定的業(yè)務(wù)協(xié)議，不同的代號(hào)代表不同業(yè)務(wù)，是面向開(kāi)發(fā)人員的。業(yè)務(wù)類別有3類，即時(shí)業(yè)務(wù)，非即時(shí)業(yè)務(wù)和查詢業(yè)務(wù)。/業(yè)務(wù)代碼節(jié)點(diǎn)類typedef struct _BusinessTypechar BusinessId5; /業(yè)務(wù)id，如“0001”，“0002”byte bBusinessType; /業(yè)務(wù)類別，0-即時(shí)業(yè)務(wù)，1-非即時(shí)業(yè)務(wù)，2-查詢BUSINESS_TYPE;車輛信息結(jié)構(gòu)：車次，始發(fā)站，終點(diǎn)站，開(kāi)車時(shí)間，到站時(shí)間。由于本系統(tǒng)初衷是實(shí)現(xiàn)全國(guó)任意車站（必須在路線之內(nèi)）的售票工作，所以用此結(jié)構(gòu)體來(lái)查詢車票。/車輛信息結(jié)構(gòu)體typedef struct _carmessage CString carID;CString Startstation;CString Endstation;CString Starttime;CString Endtime;CARMESSAGE,*PCARMESSAGE;typedef struct _carPrice CString length;CString price;CARPRICE,*PCARPRICE;/per_handle數(shù)據(jù)typedef struct _PER_HANDLE_DATA SOCKET s;sockaddr_in clientaddr;PER_HANDLE_DATA,*PPER_HANDLE_DATA;/per_I/O數(shù)據(jù)typedef struct _PER_IO_DATA OVERLAPPED ol;char bufBUFFER_SIZE;int nOperationType;PER_IO_DATA,*PPER_IO_DATA;本系統(tǒng)中使用的關(guān)鍵代碼段和鏈表CRITICAL_SECTION m_cs_search; /查詢隊(duì)列操作關(guān)鍵區(qū)CRITICAL_SECTION m_cs_jiShiTX; /即時(shí)交易隊(duì)列操作關(guān)鍵區(qū)CRITICAL_SECTION m_cs_noJiShiTX;