车站车票管理系统

摘 要随着当今社会信息技术的高速发展，计算机技术在交通方面的应用更加明显，尤其是在车站的管理系统的应用。通过不同地点的客户端访问票务中心的服务器，实现全国车票的统一管理。本文根据具体的车站管理以及票务管理，运用基于IOCP（完成端口）模型实现的模拟车站管理系统，通过VC+ 6.0编译器和SQL Server 2000数据库管理系统，模拟车站管理系统的功能特点、程序的编写和编译过程，给出了系统的需求分析、设计与实现，从售票、订票，退票，查询票信息、车辆调度、设置等多方面对系统做了设计与分析。售票员管理售票，订票等票务服务，车辆调度员实现对车辆的调度管理，普通客户对票的查询。经测试，系统运行稳定，能基本满足车站对系统在功能和性能上的需求。关键字：车站管理系统，数据库管理系统，套接字，完成端口模型，多线程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 开发目标42 可行性研究2.1经济可行性52.2技术可行性52.3操作可行性53需求分析3.1任务概述63.2功能需求分析63.2.1系统管理63.2.2调度管理63.2.3票务管理73.3 数据流图84概要设计4.1 系统整体框架设计104.2系统流程图104.3 系统用例114.4售票订票流程图124.5活动图134.6序列图155详细设计5.1服务器设计165.1.1线程模型。165.1.2 SOCK模型175.1.3通信数据帧格式和粘连包处理215.2客户端程序设计285.3客户端未来展望29六 数据库设计6.1数据库概念设计316.2 数据库的逻辑设计336.3 数据库的实现336.4数据库访问356.4.1数据库访问技术简介356.4.2数据库访问技术比较36七 系统结果分析7.1 服务器启动界面397.2 登陆窗口397.3 售票397.4车票查询407.5退票查询418总结与展望429致 谢43参考文献44 1 绪 论1.1 课题背景在当今社会，计算机占据了非常重要的位置，这些大部分都是通过使用软件而提高生产、管理效率来体现的。本文研究的火车站售票系统正好就是这样性质的一个软件。铁路运输一直都是我国重要的经济命脉，而且由于我国是内陆国家，这铁路运输的意义就显得更加突出了，对于这样重要的一件事，当然需要良好的管理了。经过几十年的发展，事实早就证明了使用计算机软件来辅助自己比单纯的人工处理手段高明的多，在这样的背景下，研究这样的课题的意义也就不言而喻了。在以前，像售票这样的事，都是人工处理的，人工处理的缺点是显而易见的，成本大、处理的速度慢、出错的几率比较大，效率是很低的。现在，在世界各国，火车售票使用的基本上都是员工操作计算机的模式，在这里，计算机主要是借助软件用来存储、更新数据的，并有统计帐目的功能。严格的说，这并不是智能化，但是，这样的处理模式比已往的人工处理的好处显然还是很明显的，所有的数据都由数据库管理，可以随时动态的提取、存储数据，并可以将修改后的数据覆盖掉原有的数据。所以，开发火车站售票系统软件是很有意义、有必要的。1.2课题研究目的和意义(1)研究目的为了应对交通运输行业的迅猛发展，尤其是火车运输业的发展和适应实名制后顾客买票的问题，针对不同类型不同规模的售票点，开发实时，高效，智能的火车票售票系统显得尤为重要。本次系统就是在实际考察火车站售票过程在实践调查情况下提出的，旨在模拟现有的火车站工作流程并且加入新的功能，做到实时，安全，广泛。目前全国火车售票系统已日趋完善，并且已经对实名制进行了改进，但是客户自主购买车票和预订车票问题并不理想，由于网页响应速度慢，所以我想将此系统做成C/S工作模式，运用visual C +开发工具开发出实时的售票系统，以满足客户自主买票的需求。(2)研究意义火车站市场的管理和规范问题，是困扰我们多年的一个老问题，也是政府管理中的一个难点，订票是客运业务中的一个最基本的业务，表面上看，它只是火车站业务的一个简单的部分，但是它涉及到管理与客户服务等多方面，因此，过去传统的售票方式已经不能满足现代客运业务流量剧增的客观要求，这就要求一种全新的订票方式网上订票，来缓解订票高峰时期的客运压力，并为用户提供方便快捷的订票服务。本次设计便是利用开发工具Visual c+ 6.0和SQL Server同开发的一个火车站网上订票系统，它能方便快捷地运用在火车站订票业务的营运之中。1.3 开发目标本系统开发意在实现售票员快速、准确、方便地的完成查询、售票、改签、退票等操作，使得顾客短时间内获取所需的准确信息、节约时间，最终提高顾客满意程度。另外，本系统还可对运价、车次、终点进行调整，对各类报表进行维护和统计，有利于铁道部门分析报表结果适时作出路线、车次、票价的调度，最终实现铁路线路保持畅通运行，为旅客提供优质满意的服务。其次，本系统可减少一定人力资源，一名售票员或一个窗口可以“同步”完成查询、售票、改签以及退票等所有基本功能；本系统界面操作简单，功能全面，能够很好满足火车站售票需求。这样，可以有效的利用适当的人力完成火车站的各种服务。最后，本系统还提供功能强大的管理功能，即实现人员、车次、运价、终点站的修改以及各类报表的维护和打印，方便铁道部门信息管理。2 可行性研究该阶段通过对系统目标的初步调研和分析，提出可行性方案并进行论证。我们在这里主要从技术可行性、经济可行性和操作可行性三方面进行分析。2.1经济可行性开发该系统所需的相关资料可以通过已存在的网上订票系统进行调查采集,所需的其他应用软件、硬件系统也易于获得.因此,开发成本较低。而引进使用本系统后，与传统方式相比，具有高效率、低成本、高质量的特点，可以节省不少人力、物力及财力。所以，从经济的角度来看，该系统可行。2.2技术可行性开发工具：Visual C+ 6.0数据库环境：SQL Server 2000系统环境：Microsoft Windows XP系统实现依靠相对熟悉的C+语言和SQL Server2000数据库系统，其基本操作实质还是对数据库进行添加、删除、查找等操作,具体技术问题后面讨论。2.3操作可行性系统采用菜单式，实现用户与数据库的交互，界面简洁友好，操作方便。用户只需对订票流程和业务调查了解即可，不需掌握数据库等相关知识。3需求分析3.1任务概述车站是发行车票、提供车辆从而方便旅客出行的单位。车站售票系统在正常运行中需要使用的主要是售票员、调度人员、车站管理人员和系统维护人员。其主要业务包括订票、售票、退票和补票等。基于安全性和其他各方面的原因考虑，本售票系统设计成C/S模式。车站客运系统的主要流程是：根据客流的分布情况制定票额分配计划和车辆的调度信息，通过预定、发票等方式售出车票，并就车票出售情况做出关于售票的财务统计报表、客运统计报表。而由统计产生的数据将成为客流分析的基本数据。对于旅客来说，想要买票先到车站的售票大厅向售票员查询相关的车次信息，若有票则出示身份证件可以现场购买，若旅客不方便出行则可以打电话到车站订票，此时需要身份证号码和联系电话。对于售票员来说根据旅客的订票信息在规定的时间内提醒旅客持身份证前来买票。3.2功能需求分析3.2.1系统管理（1）用户权限：本售票系统的用户包括售票员、调度员、车站内部的高级管理人员和系统维护人员。不同的人员登录系统时选择不同的用户角色，不同的角色具有不同的权限。售票员的权限是进入车票数据库查看车票信息并修改车票的状态；调度员登录系统主要是安排车辆及车次的调度信息；管理人员包括车站领导及财务管理人员，财务管理人员主要是看每个售票员的售票信息和车票状态；系统维护人员主要是检查系统对数据库进行备份工作。（2）站点管理主要是考虑每条线路上车辆的其起始站点及停靠站点。3.2.2调度管理（1）车次调度：车次调度包括车次的增加、删除和调整。车站根据客流的分布情况制定每条线路上的车次信息，当某段时间某条线路上客流过多或过少时车站就需要增加或删除一些车次，调整是指根据特殊情况延迟或提前某次车的发车时间。（2）线路管理：包括增加线路、修改线路、删除线路和调整线路，车站调研人员根据客流的分布情况做出开辟某些新线路、删除原有线路或修改某些线路。（3）票价管理：包括审定票价、修改票价和线路票价浮动。3.2.3票务管理 （1）订票：旅客订票有两张方式：一是电话预定，旅客将车票信息告知售票员，售票员登录系统查询车票信息，若有票旅客需要留下身份证号码和联系电话方便旅客买票；二是到车站订票，步骤同上。（2）退票：旅客因特殊原因需要退票，则需要在规定的时间内携带原车票和身份证到车站去退票并缴纳退票手续费。（3）售票：售票员根据订票信息通过旅客留下的电话号码联系快到时间而未来买票的旅客来买票，同时为直接买票的旅客打印车票。（4）补票：客户因某种原因车票丢失了，应先持身份证到制定地点挂失车票，经过挂失的车票在检票的时候不能通过，然后根据原有车票信息打印新的车票，旅客需要缴纳一定的手续费。图3.1 系统功能图3.3 数据流图图3.2 顶层图图3.3 售票0层图图3.4 订票1层图图3.5 售票1层图图3.6 退票1层图4概要设计4.1 系统整体框架设计本系统将采取C/S三层架构模式实现对车站的管理，服务器主用完成端口模型实现，客户端用基于对话框的框架进行设计。只有服务器能直接访问数据库，保证了数据库的安全性。图4.1 系统框架图4.2系统流程图本系统具体的操作流程是用户输入自己的登陆信息，登陆成功后，售票员进入票务操作界面，车站管理员进入管理界面，普通用户不需登陆，这样可以理解为自助机。在售票界面，售票员、车站管理员和普通用户都可以进行车票查询，但是只有售票员才能进行售票，车票预订在售票员和普通用户权限下都可以进行操作。车站管理员可以对车次，车票，车站，路线进行相应管理。具体流程见图：不同人员售票系统数据库提供所需信息查询数据库显示查询结果反馈给购票者图4.2 流程图4.3 系统用例用例图用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。用例模型是把应满足用户需求的基本功能聚合起来表示的强大工具，对于正在构造的新系统，用例描述系统应该作什么，对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。用例模型的基本组成部件是用例、角色和系统。用例用于描述胸膛那个的功能，也就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，他是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其他系统或硬件设备，总之，凡是需要与系统进行交互的任何东西都可以称作角色。系统的边界线以内的区域则抽象表示系统能够实现的所有基本功能。在用例模型中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节。根据本系统的需求分析，本系统中存在的角色：售票员，车站管理员，普通客户，打印机。所以可得到系统的用例图。如图图4.3 用例图对于本系统而言，具体功能是非常多的，此处只列举售票操作的图。4.4售票订票流程图售票订票是本系统最基本的功能，售票功能的流程是：售票员登陆，根据客户提供的车次或者是车站信息对车票进行查询，有票时向客户进行售票，系统修改数据库，打印机打印车票。订票可以客户在自助机上进行，也可以由售票员进行。订票功能的流程是：客户在自助机上根据车次或车站信息对车票进行查询，有票时展现车票信息和余票信息，客户自助订票，系统修改数据库，产生订单。图4.4 售票订票流程图4.5活动图活动图显示动作及其结果。活动图着重描述操作实现中所完成的工作以及用例实例或对象中的活动。活动图是状态图的一个变种，与状态图的目的有一些小的差别，活动图的主要目的是描述动作及对象状态改变的结果。当状态中的动作被执行时，活动图中的状态直接转移到下一个阶段。活动图和状态图的另一个区别是活动图中的动作可以放在泳道中。泳道聚合一组活动，并指定负责人和所属组织。活动组是另一种描述交互的方式，描述采取何种动作，做什么，何时发生，以及在何处发生。活动图可以用作下述目的：（1）描述一个操作执行过程中（操作实现的实例化）所完成的工作（动作）。这是活动图最常见的用途。（2）描述对象内部的工作。（3）显示如何执行一组相关的动作，以及这些动作如何影响他们周围的对象。（4）显示用例的实例是如何执行动作以及如何改变对象状态。（5）说明一次活动中的角色、工作流、组织和对象是如何工作的。图4.5 活动图4.6序列图序列图描述对象是如何交互的，并且将重点放在消息序列上，也就是说，描述消息是如何在对象间发送和接收德尔。序列图有两个坐标轴：纵坐标轴显示时间，横坐标轴显示对象。序列图也显示特殊情况下的对象交互：在系统执行期间的某一时间点发生在对象间的特殊交互。在序列图的横坐标轴上是与序列有关的对象。每一个对象的表示方法是：矩形框中写有对象和/或类名，且名字下面有下划线。同时，有一条纵向的虚线表示对象在序列中的执行情况（即：发送和接收的消息，对象的活动），这条虚线称为对象的“生命线”。对象间的通信用对象的生命线之间的水平的消息线来表示。消息线的箭头说明消息的类型，如同步，异步或简单。浏览序列图的方法是：从上到下查看对象交换的消息。图4.6 序列图5详细设计5.1服务器设计服务器是本系统的核心模块，其一端连接中心数据库，另一端连接各客户端节点，是系统的业务处理和信息交互的中心节点。其模型图为：图5.1 系统模型图其稳定性要求和响应时间有较高要求。设计思想从以下几个方面进行描述：5.1.1线程模型。主线程为界面线程，当启动服务时，系统创建监听线程，用于监听到达的客户端连接，当客户端到达时，将客户端信息等级到服务器的列表框中。监听线程创建服务服务线程，此服务线程用于接收客户端传来的消息，对消息进行分析，并将消息投递到不同的业务线程中。根据不同的业务类型，服务线程创建三条业务线程，即时业务线程，非即时业务线程，查询线程。具体的线程模型见图：图5.2 线程模型/创建三条业务线程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平台常用的模型有阻塞模型、select模型、WSAAsyncSelect模型、WSAEventSelect模型、Overlap模型、完成端口（IOCP）模型。考虑到服务点的规模和采用多线程的特点，选用IOCP模型。根据业务类别分别基于TCP或UDP协议开发。完成端口简介完成端口模型 (I/O completion ports)是迄今为止为复杂的一种I/O模型，假如一个程序需要管理为数多的套接字，那么采用这种模型往往可以达到最佳的系统性能,因其设计的复杂性,只有应用程序需要同时管理数百乃至上千个套接字的时候,而且希望随着系统内安装CPU 数量的增多,应用程序的性能呈线性提升时,才考虑采用完成端口模型。完成端口模型是唯一适用于高负载服务器的一种技术。我们可以把完成端口看成系统维护的一个队列，操作系统把重叠IO操作完成的事件通知放到该队列里。一个socket被创建后，可以在任何时刻和一个完成端口联系起来，当与完成端口相关联的socket上的异步I/O 完成时，操作系统会向完成端口发送一个完成通知包。通过GetQueuedCompletionStatus()函数可以获取I/O操作结果。由于一个完成端口能够管理为数众多的套接字，所以用完成端口编写的服务器程序能够达到最佳的系统性能。而且随着服务器CPU数量的增加，应用程序的性能也会得到线形的提高。线程的数量一般来说，一个应用程序可以创建多个工作器线程来处理完成端口上的通知事件。但是在理想的情况下，应该对应一个CPU创建一个线程。因为在完成端口理想模型中，每个线程都可以从系统获得一定的时间片，轮番运行并检查完成端口。但是在实际开发的时候，还要考虑这些线程是否牵涉到其他堵塞操作的情况。如果某线程进行堵塞操作，系统则将其挂起，让别的线程获得运行时间。因此，如果有这样的情况，可以多创建几个线程来尽量利用时间。重叠I/O 用完成端口编写的服务器程序有如此高的系统性能，重叠I/O功不可没。比起阻塞的I/O操作，重叠I/O最大的优势是应用程序投递了一个发送或接受请求以后直接就返回。对于那种需要很长时间才能完成的操作来说，重叠I/O机制尤其有用，因为发起重叠操作的线程在重叠请求发出后就可以自由的做别的事情了。Windows Sockets 2引入了重叠I/O的概念并且要求所有的传输协议提供者都支持这一功能。重叠I/O仅能在由WSASocket()函数打开的套接口上使用（使用WSA_FLAG_OVERLAPPED标记）。对于接收数据，应用程序使用WSARecv()函数来提供存放接收数据的缓冲区。如果数据在WSARecv()函数接收以前已经到达套接字的接受缓冲区，那么调用WSARecv()函数，接收的数据就可以立即被存放进用户缓冲区，函数返回值是0，如果数据在WSARecv()函数接收之前没有到达套接字的接受缓冲区，那么调用WSARecv()返回SOCKET_ERROR，并且错误代码是WSA_IO_PENDING，当数据到来的时候，操作系统直接把数据拷贝进应用程序的缓冲区。发送函数WSASend()发送数据的时候，如果套接字的发送缓冲区有足够的空间，那么将数据拷贝到套接字的发送缓冲区，函数返回值是0。如果套接字的发送缓冲区没有空间，那么WSASend()返回SOCKET_ERROR，并且错误代码是WSA_IO_PENDING，在系统处理完套接字的发送缓冲区后，系统直接把数据交给了TCP，绕过了套接字的发送缓冲区。Overlapped的用法在重叠IO的过程中，Overlapped的使用非常重要，当一个重叠IO被发起，一个Overlapped结构体的指针就要作为参数传递给系统。当操作完成，GetQueueCompletionStatus可以返回指向同一个Overlapped结构的指针。为了辨认和定位这个已完成的操作，开发人员最好定义自己的Overlapped结构，以包含一些自己定义的关于操作本身的额外信息。使用AcceptEx由于高性能的服务器在很短的时间内要响应大量的连接，所以采用AcceptEx函数。AcceptEx函数是微软的Winsosk 扩展函数，这个函数与accept的区别就是：accept是阻塞的，一直要到有客户端连接上来后accept才返回，所以同时面对大量的连接，accept显然难以满足要求。而AcceptEx是异步的，直接就返回了，而且我们可以利用AcceptEx可以发出多个AcceptEx调用等待客户端连接。另外，如果我们可以预见到客户端一连接上来后就会发送数据，那么可以随着AcceptEx投递一个BUFFER进去，这样如果连接建立成功，就可以接收客户端发出的数据到BUFFER里，这样的话，一次AcceptEx调用相当于accpet和recv的一次连续调用。IOCP工作流程：主线程工作流程1、创建一个I/O 完成端口；2、创建一个listen_socket并listen_socket添加到完成端口；3、将套接字绑定到一个已知的地址4、创建一个socket，调用AcceptEx（）函数，将socket作为AccpetEx的一个参数，用于下一个客户机的连接。重复此步骤若干次。5、在listen_socket上用WSAEventSelect（）注册FD_ACCEPT事件6、主线程进入循环，等待listen_socket上的FD_ACCEPT事件7、如果发生FD_ACCEPT事件，则说明已经投递的套接字已经用完，则调用步骤5，再投递一定数量的AcceptEx（），如果发生了WAIT_TIMEOUT时间，则调用CheckConnection()函数，删除已经连接但是没有发送数据的socket。图5.3 主线程图工作者线程的步骤如下1、创建扩展重叠结构2、工作者线程循环调用GetQueuedCompletionStatus函数以获取I/O操作结果；3、GetQueuedCompletionStatus()中WSAOVERLAPPED的结果来判断完成端口上是接受到了新的连接、有数据接受，还是要发送数据。4、如果接受到了新的连接，将新套接字句柄用CreateIoCompletionPort函数关联到完成端口，如果要接受数据则调用WSARecv（），如果要发送数据，调用WSASend（）。因为是异步函数，WSASend和WSARecv会直接返回，实际的发送或接收数据的操作由Windows 系统完成。图5.4 工作线程图5.1.3通信数据帧格式和粘连包处理TCP通信是基于数据流的，不区分边界，可能出现粘连包，数据在传输过程中可能被窃取或篡改，数据帧的种类繁多等等，在设计数据帧时必须考虑到上述问题。所以，在通信时的数据包中都包含了包长、协议类型、校验和，数据通过相应的加密算法加密。（1）数据帧格式如表5.1表5.1 数据帧格式表包长（4字节）业务代码（4字节）用户数据段（K字节）校验和（8字节）数据帧包括4字节的包长字段，4字节的业务字段，K字节的用户数据字段，8字节的校验和。（2）粘连包处理方法由于车票管理的数据量是非常大的，多以出现粘连包是在所难免的，粘连包出现的问题主要是半包问题，所以必须解决这个问题，在此方案中，处理粘连包的方法是，在服务器中存在4个包队列：即时业务包队列，非即时业务包队列，查询业务包队列，半包队列，首先取得包的前4个字节得到包应该的长度a，计算获得包的总长度b，如果a = b则是正常包，进行正常处理，如果如果a b，则根据a的值在包中取得相应长度的数据，并将b的长度减去a，然后循环如此，直到包结束或者是出现半包停止，若果a s=g_BaseObj.m_iter-s)/如果有就半包添加到收到的数据的开始部位，并且报的长度进行改编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);/构造消息节点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); /去掉包长字段（4字节）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); /去掉包长字段（4字节）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）数据安全保障算法。中心数据库由业务中间件定时维护，如果存放中心数据库的硬盘损毁或出现无法访问的故障时，没有备份的数据就会丢失。因此，在中间件执行更改数据库数据的指令时，相应的SQL指令被存储到一个按日期命名的文本文件中，且该文本文件与数据库文件不在同一个硬盘上，这样，一旦硬盘出现故障，数据库无法访问时，执行文本文件中的相应SQL语句就可以恢复数据。这一块具体没有实现。（4）线程之间同步和互斥访问数据库问题由于数据量大且信息种类多样，为了同时满足对数据的读取、存放和显示，必须在软件运行期间开启多条线程进行应对。由于服务器中存在3条业务线程，服务线程需要向业务队列中投递业务，业务线程需要从业务队列中取业务代码，由于3条业务线程是异步执行的，所以业务线程需要从而对数据库的访问就存在互斥访问问题，以免出现数据混乱的局面。在window环境下，一个进程等同于一个容器，而线程则是容器内的实体，线程才是程序的最小执行单元。对于进程中，若多条线程在任意时刻都有可能访问到某个全局资源，那么这个全局资源被称为是临界资源。在这种情况下，必须保护临界资源，多线程必须互斥的对其访问。在本监控系统中，将多条线程做成类似生产者消费者模型，满足了系统对数据并发控制的需要。此模型的原理即是：一条线程负责生产数据，其他线程负责读取由该线程生产的数据。只需对数据访问部分做到同步即可。为了解决线程同步问题，win32 API提供了多种同步控制对象。包括：互斥对象、信号对象、事件对象、排斥区对象(关键代码段)在介绍这些对象之前，必须先介绍等待函数，因为他们都要使用等待函数。Win32 API提供了一组能使线程阻塞其自身执行的等待函数。等待函数未返回时，线程处于等待状态，此时线程只是消耗很少的CPU时间。使用等待函数既可以保证线程的同步，又可以提高程序的运行效率。最常用的等待函数为：WaitForSingleObject, WaitForMultipleObjects。1）.Mutex对象的状态在它不被任何线程拥有时才有信号。Mutex对象很适合用来协调多个线程对共享资源的互斥访问。可以按照下列步骤使用该对象：.建立互斥对象，得到句柄:HANDLE CreateMutex()。.在线程可能产生冲突的区域前（即访问共享资源前）调用WaitForSingleObject()将句柄传给函数，请求占用Mutex对象。.共享资源访问结束，释放对Mutex对象的占用：ReleaseMutex(hMutex)。Mutex对象在同一时刻只能被一个线程占用，当Mutex对象被一个线程占用时，若另一个线程想占用它，则必须等到前一个线程释放。2）.信号对象允许同时对多个线程共享资源进行访问，在创建对象时指定最大可同时访问的线程数。当一个线程申请访问成功后，信号对象中的计数器减一，调用ReleaseSemaphore函数后，信号对象中的计数器加一。其中，计数器值大于或等于0，但小于或等于创建时指定的最大值。如果一个应用在创建一个信号对象时，将其计数器的初始值设为0，就阻塞了其他线程，保护了资源。等初始化完成后，调用ReleaseSemaphore函数将其计数器增加至最大值，则可进行正常的存取访问。 其使用步骤与Mutex对象类似，这里不再赘述。3）.事件对象(Event)是最简单的对象，它包括有信号和无信号两种状态。.创建事件对象HANDLE CreateEvent(NULL,FALSE,TRUE,NULL)/自动重置事件HANDLE CreateEvent(NULL,TRUE,FALSE,NULL)/手工重置事件.在线程访问共享资源之前调用 WaitForSingleObject()。.重新设置成有信号状态 SetEvent(EVENT_HANDLE )。4）.排斥区对象 在排斥区中异步执行时，它只能在同一进程的线程之间共享资源处理。使用排斥区的方法则使同步管理的效率更高。.使用时先定义一个CRITICAL_SECTION结构的排斥区对象: VOID InitializeCriticalSection(LPCRITICAL_SECTION)。.当一个线程使用排斥区时，调用函数：EnterCriticalSection( ); .当要求退出排斥区时，调用函数：LeaveCriticalSection( ); /释放对排斥区对象的占用在这四种多线程同步的方法中，优先选用关键代码段（排斥区对象）方法。其使用简单且速度较快，而Mutex对象与事件对象等属于内核对象，运行速度较慢。故本系统中采用第四种同步方法。考虑到本系统里需要用到的线程存在于一个进程之中和5个临界区，即即时业务队列，非即时业务队列，查询业务队列，半包队列，数据库访问这些对象对应的关键区，所以采用关键代码段来实现线程同步和互斥。在服务器开启服务的时候对关键区进行初始化：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);在停止服务时删除关键区：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);在需要访问临界区的时候：业务线程从队列中取走业务代码：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-; /即时交易包未处理数目elseLeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX); Sleep(10);continue;LeaveCriticalSection(&g_BaseObj.m_cs_jiShiTX);服务线程向队列中投递业务：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+; /即时交易包未处理数目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+;/非即时交易包未处理数目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+;/查询包未处理数目LeaveCriticalSection(&g_BaseObj.m_cs_search);（5）全局队列和全局结构的设计本系统中由于处理数据内容是庞大的，所以应该有相应的结构来存储以便统一管理数据。并且由于本系统中几乎所有的线程都需要用到一些数据结构，所以将这些数据结构存放在统一的类里，此类是一个全局类。类中包括的结构有消息节点结构：套接字信息，消息数据。套接字信息提供客户端套接字，以便于服务器进行操作之后向客户端发送数据和粘连包的处理，消息数据即为客户端发送的请求，包括4字节的包长，8字节的校验和字段，K个字段的数据。/消息节点类typedef struct _messageSOCKET s;CString msg;MESSAGE,*PMESSAGE;业务节点结构：业务代码，业务类别。业务代码是服务器与客户端协定的业务协议，不同的代号代表不同业务，是面向开发人员的。业务类别有3类，即时业务，非即时业务和查询业务。/业务代码节点类typedef struct _BusinessTypechar BusinessId5; /业务id，如“0001”，“0002”byte bBusinessType; /业务类别，0-即时业务，1-非即时业务，2-查询BUSINESS_TYPE;车辆信息结构：车次，始发站，终点站，开车时间，到站时间。由于本系统初衷是实现全国任意车站（必须在路线之内）的售票工作，所以用此结构体来查询车票。/车辆信息结构体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数据typedef struct _PER_HANDLE_DATA SOCKET s;sockaddr_in clientaddr;PER_HANDLE_DATA,*PPER_HANDLE_DATA;/per_I/O数据typedef struct _PER_IO_DATA OVERLAPPED ol;char bufBUFFER_SIZE;int nOperationType;PER_IO_DATA,*PPER_IO_DATA;本系统中使用的关键代码段和链表CRITICAL_SECTION m_cs_search; /查询队列操作关键区CRITICAL_SECTION m_cs_jiShiTX; /即时交易队列操作关键区CRITICAL_SECTION m_cs_noJiShiTX;