CN103714487A - 轨道交通的票务系统及其购票验票方法 - Google Patents

Abstract

本发明公开了一种轨道交通的票务系统，包括：通用服务器、应用服务器和车站系统终端，通用服务器包括车票数据库，通用服务器配置成为应用服务器提供余票查询、售票、退票、登乘检验以及交易记录的服务，并根据应用服务器的服务指令更新所述车票数据库；应用服务器，配置成接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器；车站系统终端包括售票终端和登乘终端。本系统通过设置应用服务器作为一个中间层，应用服务器采用面向服务（SOA）的体系结构。通过应用服务器来处理业务逻辑，通过通用服务器来处理数据存储。通过业务逻辑和数据存储的分离，提高系统的灵活性、扩展性、易维护性和易升级性，降低了车票数据库的海量检索压力。

Description

轨道交通的票务系统及其购票验票方法

技术领域

本发明涉及城际轨道交通领域，特别涉及一种城际轨道交通的票务系统及其购票验票方法。

背景技术

在经济发达、人口稠密的大型都市经济圈中，主要中心城镇通常需承担经济圈内各城市间的客流，又兼顾城市组团、次中心城镇之间的客流，城际轨道为机场、火车站、公路客运枢纽对外客运提供集散服务，可以说是城际间的“公交”系统。

城际轨道交通相对于城市地铁而言，其距离较短，但是相对于客运专线而言，其距离较长。所以，在城际轨道交通中具备了地铁人流量大的特征，也具备了客运专线需要进行席位售卖的特征。

这就对城际轨道交通的票务系统提出了一个特别高的要求，需要其票务系统可以快速有效的应对大量的购票请求，同时大量的购票请求不至于影响整个票务系统的正常运转。

传统的方式都是，车站内的终端直接与管理中心的主服务器进行连接，但是大量终端直接与主服务器进行连接，并发送相应的服务请求，这就会造成主服务器的接收的信息量出暴增的情形，导致无法及时处理车站内终端的服务请求，甚至导致整个系统瘫痪。

发明内容

本发明的目的是提供一种可以有效应用于城际轨道交通的票务系统。

根据本发明的一个方面，提供的轨道交通票务系统，包括：通用服务器、应用服务器和车站系统终端，

通用服务器包括车票数据库，通用服务器配置成为应用服务器提供余票查询、售票、退票、登乘检验以及交易记录的服务，并根据应用服务器的服务指令更新车票数据库；

应用服务器，配置成接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器；

车站系统终端包括售票终端和登乘终端，售票终端配置于接收乘客的余票查询请求、售票请求、退票请求和改签请求，并将服务请求传递至应用服务器，登乘终端配置于接收乘客的登乘请求，并将服务请求传递到应用服务器。

本发明的有益效果是，本系统通过设置应用服务器作为一个中间层，应用服务器采用面向服务（SOA）的体系结构，其中使用了webservice,xml,socket跨平台数据传输服务，运用面向对象的技术，利用模块化设计思想，实现票务相关的业务流程。通过应用服务器来处理业务逻辑，通过通用服务器来处理数据存储。通过业务逻辑和数据存储的分离，提高系统的灵活性、扩展性、易维护性和易升级性，降低了车票数据库的海量检索压力，同时对票务系统的车票数据库形成一个保护。

票务系统根据不同的使用场景可以使用不同的技术进行通信，采用消息队列保障数据可靠传输，采用WebService满足跨平台、可互操作性要求，采用Socket通信使信息交互简单、高效，同时，数据传输过程中采用多线程、加密与解密技术。

在实体车站内可以设置车站的备用通用服务器和备用应用服务器。当实体车站与应用服务器的链接中断时，车站系统终端可以自动链接到车站的备用通用服务器和备用应用服务器。车站的登乘业务，售票业务不受影响，可继续服务。待与应用服务器恢复链接时，车站系统终端自动链接到应用服务器和通用服务器。车站的备用应用服务器和备用通用服务器也会相应链接到应用服务器以及通用服务器。同时，车站的备用应用服务器和备用通用服务器可以通过数据同步工具自动的将离线时的数据同步到应用服务器以及通用服务器。

在一些实施方式中，应用服务器为双层结构，包括第一逻辑层和第二逻辑层，第一逻辑层用于处理所述售票请求，并将相应的服务指令发送给第二逻辑层进行分析，再传递给通用服务器；第二逻辑层用于处理所述余票查询请求、退票请求和改签请求，并将相应的服务指令传递给通用服务器。

其有益效果是，通过将应用服务器分成两个逻辑层，将售票请求先由第一逻辑层来单独处理，然后将其余的服务请求全部交由第二逻辑层来处理。由于售票请求瞬间信息处理量会非常的大，所以仅将售票请求交由第一逻辑层来单独处理，可以保证售票请求的处理不会被其它服务请求所影响。售票终端发来的售票请求在经过第一逻辑层的处理后，形成售票指令，售票指令还会再发送至第二逻辑层进行指令分析，指令分析的主要内容包括：分析车票的地域和区域，车票的票价和种类，当前车票是否符合售卖规则，当前车票的用途，以及当前车票的票款的支付方式。将这些信息分析完成，如果确认当前车票是可以进行售卖的，则第二逻辑层将相应的售票指令发送到通用服务器中进行售票操作，如果指令分析完成后，确认当前车票是不可以进行售卖的，则向售票终端返回无票信息。由于将售票请求和其它的票务一些请求进行了分离，所以应用服务器不需要在不同的服务请求处理中进行不断的切换，大大提高了售票请求的处理效率。同时，由于其它服务请求是由另外的第二逻辑层来处理的，即使其它服务请求再多，也不会影响到其它售票请求的处理。尤其不会出现，想买票的买不到，想退改签的又退不了票、改签不了车票，导致车票的无端浪费。

在一些实施方式中，通用服务器为双机热备份结构；应用服务器利用云技术，采用服务器集群方式部署成云端；车站系统终端根据业务处理需要向应用服务器请求相应的服务，实现业务流程控制和处理。

其有益效果是，采用双机热备份方式，确保了服务的稳定、可靠，避免了单点故障，同时，能满足应用服务器短时间内或瞬间超大并发请求需要；应用服务可以采用服务器集群方式部署成云端，高效地使用服务器资源，保障线路或区域中心、车站系统终端设备请求能及时得到正确响应和处理。同时，应用服务器采用云技术，也可以提供更好的可扩展性。如果票务系统需要增加相应的功能，就可以很方便的在云端增加相应服务模块即可以。不需要对通用服务器和车站终端设备进行大范围的改动，可扩展性增强了。

在一些实施方式中，应用服务器包括管理服务模块、售票模块、检票模块和席位管理模块；

管理服务模块，配置成对运营规则和售卖计划进行管理；

售票模块，配置成对乘客提出余票查询请求、售票请求、退票请求和改签请求进行处理；

检票模块，配置成检测乘客进站和出站时所刷票卡的信息进行检查；

席位管理模块，配置成提供席位的生成、搜索、占用、修改和删除处理服务。

在一些实施方式中，应用服务器还包括旅客管理模块、储值卡模块、票价计算模块、路径计算模块、发票服务模块；

旅客管理模块，配置成包括常旅客管理子模块、特殊旅客管理子模块、旅客电子账户管理子模块和个性化服务管理子模块；

储值卡模块，配置成对乘客持有的储值卡进行管理，所述储值卡的交易数据存储于通用服务器；

票价计算模块，配置成完成票务系统的车票票价计算的功能；

路径计算模块，配置成对旅行线路进行规划计算，为旅客提供存在的各种换乘路径方案；

发票服务模块，配置成根据旅客的乘车记录，设置给予旅客自助打印的发票设备。

在一些实施方式中，通用服务器和应用服务器处均配置负载均衡设备，减少用户等待响应的时间，通用服务器和应用服务器使用双电源、双网络适配器和RAID磁盘阵列。其有益效果是，为保障通用服务器和应用服务器资源的合理利用，首先，在关键业务和并发用户量大的节点处配置负载均衡设备，减少用户等待响应的时间，其次，单个重负载的运算分担到服务器上做并行处理，实现对流量的科学分配和服务器资源的有效利用。按照各类服务器集群配置方案，每个集群单独配置负载均衡器，负载均衡器通过冗余配置避免单点故障。为了保障系统高可靠性和高可用性，配置了集群和多域控制器，硬件还使用双电源、双网络适配器、RAID磁盘阵列，防止单点故障所出现的问题，提高系统和设备运行的完整性和一致性。

根据本发明的一个方面，提供的轨道交通票务系统的购票验票方法，包括步骤：

车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器；

应用服务器接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器；

通用服务器为应用服务器提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器的服务指令更新通用服务器内的车票数据库。

其有益效果是，车站终端接收到的所有服务请求，都会先传递到一个应用服务器当中，应用服务器采用的是面向服务的体系结构。应用服务器会将所有的服务请求进行分类，分类处理后，再将不同类服务请求相应的服务指令传递给通用服务器，通用服务器只需要根据相应的服务指令提供相应服务，并相应更新车票数据库即可以。

整个票务系统的服务处理过程，都是通过应用服务器来处理大量的服务请求。而通用服务器主要负责数据的存储更新。再处理部分和存储部分分离开来，从而可以提高大量服务请求的处理效率。

在一些实施方式中，车票数据库保存有计划余量表，所述计划余量表包括计划编号、车次、车厢顺序号、ＯＤ站序集、席位总数量；

所述车票数据库，配置成

当售票终端收到乘客的售票请求后，席位总数量减1；

当售票终端收到乘客的退票请求后，席位总数量加1；

当售票终端收到乘客的余票查询请求后，返回席位总数量的当前值。

在一些实施方式中，车票数据库当中还保存有席位占用表，所述席位占用表包括车次车厢编号、车厢顺序号、包厢号、席位顺序号、席位属性、席位ＯＤ占用、席别定义、位置号；

所述车票数据库，配置成

当售票终端收到乘客的售票请求时，当前席位的席位ＯＤ占用项标记为已占用；

当售票终端收到乘客的退票请求时，当前席位的席位ＯＤ占用项恢复为未占用。

根据本发明的一个方面，提供的轨道交通票务系统的购票验票方法，其包括步骤：

车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器；

应用服务器接收车站系统终端传递来的服务请求，并进行分类；

应用服务器的第一逻辑层接收售票请求，处理后生成相应的服务指令，服务指令经过第二逻辑层的分析后，再传递给通用服务器；

应用服务器的第二逻辑层接收余票查询请求、退票请求、改签请求和登乘请求，处理后生成相应的服务指令并传递给通用服务器；

通用服务器为应用服务器提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器的服务指令更新通用服务器内的车票数据库。

其有益效果是，将车站终端接收到的所有服务请求进行一个分类后的分流过程。售票请求全部传递给第一逻辑层处理，其它请求全部由第二逻辑层处理。这样售票请求和其它请求的处理就是分开独立的，相互之间并不影响。从而可以加快售票的效果，也得到应用服务器可以同时处理更多的售票请求，而不至于导致系统瘫痪。

附图说明

图1为本发明一实施方式的轨道交通的票务系统的结构原理示意图；

图2为本发明一实施方式的轨道交通的票务系统的逻辑原理示意图；

图3为本发明一实施方式的轨道交通的票务系统的应用服务器的原理示意图；

图4为本发明又一实施方式的轨道交通的票务系统的购票验票方法的流程示意图；

图5为本发明另一实施方式的轨道交通的票务系统的购票验票方法的流程示意图。

具体实施方式

下面结合附图1至图5对本发明作进一步详细的说明。

图1至图3，示意性地显示了根据本发明的一种实施方式的轨道交通的票务系统，如图1至图3所示，轨道交通的票务系统，包括：通用服务器100、应用服务器200和车站系统终端，其中，通用服务器100选用带数据库系统的大型服务器计算机，应用服务器200为采用云技术，集群式布置的众多小型服务器计算机。车站系统终端主要为车站内的售票员用计算机、自动售票机和登乘闸机等。

在通用服务器100内设有车票数据库101，通用服务器100为应用服务器200提供余票查询、售票、退票、登乘检验以及交易记录的服务，并根据应用服务器200的服务指令更新车票数据库101；

应用服务器200接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器100；

车站系统终端包括售票终端301和登乘终端302，售票终端301配置于接收乘客的余票查询请求、售票请求、退票请求和改签请求，并将服务请求传递至应用服务器200，登乘终端302配置于接收乘客的登乘请求，并将服务请求传递到应用服务器200。

其中，应用服务器200为双层结构，包括第一逻辑层201和第二逻辑层202，第一逻辑层201用于处理所述售票请求，并将相应的服务指令传递给通用服务器100；第二逻辑层202用于处理所述余票查询请求、退票请求和改签请求，并将相应的服务指令传递给通用服务器100。

首先，本系统通过置一个应用服务器200作为一个中间层，应用服务器200采用面向服务（SOA）的体系结构，其中使用了webservice,xml,socket等跨平台数据传输服务，运用面向对象的技术，利用模块化设计思想，实现票务相关的业务流程。通过应用服务器200来处理业务逻辑，通过通用服务器100来处理数据存储。通过业务逻辑和数据存储的分离，提高系统的灵活性、扩展性、易维护性和易升级性，降低了车票数据库101的海量检索压力，同时对票务系统的车票数据库101形成一个保护。本发明可以根据不同的使用场景可以使用不同的技术进行通信，采用消息队列保障数据可靠传输，采用WebService满足跨平台、可互操作性要求，采用Socket通信使信息交互简单、高效，同时，数据传输过程中采用多线程、加密与解密技术。

本发明当中，还将应用服务器200分成了两个逻辑层，主要包括第一逻辑层201和第二逻辑层202，将售票请求先全部由第一逻辑层201来单独处理，然后将其余的服务请求都是直接交由第二逻辑层202来处理。由于售票请求瞬间信息处理量会非常的大，所以将售票请求由第一逻辑层201来单独处理，可以保证售票请求的处理不会被其它服务请求所影响。售票终端301发来的售票请求在经过第一逻辑层201的处理后，形成售票指令，售票指令还会再发送至第二逻辑层202进行指令分析，指令分析的主要内容包括：分析车票的地域和区域，车票的票价和种类，当前车票是否符合售卖规则，当前车票的用途，以及当前车票的票款的支付方式。将这些信息分析完成，如果确认当前车票是可以进行售卖的，则第二逻辑层202将相应的售票指令发送到通用服务器100中进行售票操作，如果指令分析完成后，确认当前车票是不可以进行售卖的，则向售票终端返回无票信息。由于将售票请求和其它的票务一些请求进行了分离，所以应用服务器200不需要在不同的服务请求处理中进行不断的切换，大大提高了售票请求的处理效率。同时，由于其它服务请求是由另外的第二逻辑层202来处理的，即使其它服务请求再多，也不会影响到其它售票请求的处理。尤其不会出现，想买票的买不到，想退改签的又退不了票、改签不了车票，导致车票的无端浪费。

同时，为了保证整个系统在外网连接中断的特殊情况下正常运行。在实体车站内可以设置车站的备用通用服务器100和备用应用服务器200，这里的备用通用服务器100和备用应用服务器200均可以采用稍小型的服务器计算机，以节省系统架设的成本。当实体车站与应用服务器200的链接中断时，车站系统终端可以自动链接到车站的备用通用服务器100和备用应用服务器200，车站的登乘业务，售票业务不受影响，可继续服务，待与应用服务器200恢复链接时，车站系统终端自动链接到应用服务器200和通用服务器100，车站的备用应用服务器200和备用通用服务器100也会相应链接到应用服务器200以及通用服务器100。同时，车站的备用应用服务器200和备用通用服务器100可以通过数据同步工具自动的将离线时的数据同步到应用服务器200以及通用服务器100。

同时，为了保证数据的安全性。通用服务器100为双机热备份结构；应用服务器200采用服务器集群方式部署成云端；车站系统终端根据业务处理需要向应用服务器200请求相应的服务，实现业务流程控制和处理。

采用双机热备份方式，确保了服务的稳定、可靠，避免了单点故障，同时，能满足应用服务器200短时间内或瞬间超大并发请求需要；应用服务可以利用云技术，采用服务器集群方式部署成云端，高效地使用服务器资源，保障线路或区域中心、车站系统终端设备请求能及时得到正确响应和处理。同时，应用服务器200采集云技术，也可以提供更好的可扩展性。如果票务系统需要增加相应的功能，就可以很方便的在云端增加相应服务模块即可以。不需要对通用服务器100和车站终端设备进行大范围的改动，可扩展性增强了。

为保障通用服务器100和应用服务器200资源的合理利用首先，在关键业务和并发用户量大的节点处配置负载均衡设备，减少用户等待响应的时间，其次，单个重负载的运算分担到服务器上做并行处理，实现对流量的科学分配和服务器资源的有效利用。按照各类服务器集群配置方案，每个集群单独配置负载均衡器，负载均衡器通过冗余配置避免单点故障。

同时，为了保障系统高可靠性和高可用性，通用服务器100和应用服务器200都可以使用双电源、双网络适配器RAID磁盘阵列，防止单点故障所出现的问题，提高系统和设备运行的完整性和一致性。

应用服务器200可以包括管理服务模块203、售票模块204、检票模块205、席位管理模块206、旅客管理模块207、储值卡模块208、票价计算模块209、路径计算模块210和发票服务模块211；

管理服务模块203，配置成对运营规则和售卖计划进行管理；

售票模块204，配置成对乘客提出余票查询请求、售票请求、退票请求和改签请求进行处理；

检票模块205，配置成检测乘客进站和出站时所刷票卡的信息进行检查；

席位管理模块206，配置成提供席位的生成、搜索、占用、修改和删除处理服务。

旅客管理模块207，配置成包括常旅客管理子模块、特殊旅客管理子模块、旅客电子账户管理子模块和个性化服务管理子模块；

储值卡模块208，配置成对乘客持有的储值卡进行管理，所述储值卡的交易数据存储于通用服务器100；

票价计算模块209，配置成完成票务系统的车票票价计算的功能；

路径计算模块210，配置成对旅行线路进行规划计算，为旅客提供存在的各种换乘路径方案；

发票服务模块211，配置成根据旅客的乘车记录，设置给予旅客自助打印的发票设备。

如图4所示，示意性地显示了根据本发明的一种实施方式的轨道交通票务系统的购票验票方法，包括步骤：

步骤S401：车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器200；

步骤S402：应用服务器200接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器100；

步骤S403：通用服务器100为应用服务器200提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器200的服务指令更新通用服务器100内的车票数据库101。

车站终端接收到的所有服务请求，都会先传递到一个应用服务器200当中，应用服务器200采用的是面向服务的体系结构。应用服务器200会将所有的服务请求进行分类，分类处理后，再将不同类服务请求相应的服务指令传递给通用服务器100，通用服务器100只需要根据相应的服务指令提供相应服务，并相应更新车票数据库101即可以。

整个票务系统的服务处理过程，都是通过应用服务器200来处理大量的服务请求。而通用服务器100主要负责数据的存储更新。再处理部分和存储部分分离开来，从而可以提高大量服务请求的处理效率。

在车票数据库101中保存有计划余量表，计划余量表包括计划编号、车次、车厢顺序号、ＯＤ站序集、席位总数量；所述车票数据库101设置为：

当售票终端301收到乘客的售票请求后，席位总数量减1；

当售票终端301收到乘客的退票请求后，席位总数量加1；

当售票终端301收到乘客的余票查询请求后，返回席位总数量的当前值。

同时，在车票数据库101当中还保存有席位占用表，所述席位占用表包括车次车厢编号、车厢顺序号、包厢号、席位顺序号、席位属性、席位ＯＤ占用、席别定义、位置号；车票数据库101设置为：

当售票终端301收到乘客的售票请求时，当前席位的席位ＯＤ占用项标记为已占用；

当售票终端301收到乘客的退票请求时，当前席位的席位ＯＤ占用项恢复为未占用。

如图5所示，示意性地显示了根据本发明的一种实施方式的轨道交通票务系统的购票验票方法，其包括步骤：

步骤S501：车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器200；

步骤S502：应用服务器200接收车站系统终端传递来的服务请求，并进行分类；

步骤S503：应用服务器200的第一逻辑层201接收售票请求，处理后生成相应的服务指令，服务指令经过第二逻辑层（202）的分析后，再传递给通用服务器100；售票指令在第二逻辑层202进行的指令分析的主要内容包括：分析车票的地域和区域，车票的票价和种类，当前车票是否符合售卖规则，当前车票的用途，以及当前车票的票款的支付方式。将这些信息分析完成，如果确认当前车票是可以进行售卖的，则第二逻辑层202将相应的售票指令发送到通用服务器100中进行售票操作，如果指令分析完成后，确认当前车票是不可以进行售卖的，则向售票终端返回无票信息。

步骤S504：应用服务器200的第二逻辑层202接收余票查询请求、退票请求、改签请求和登乘请求，处理后生成相应的服务指令并传递给通用服务器100；

步骤S505：通用服务器100为应用服务器200提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器200的服务指令更新通用服务器100内的车票数据库101。

将车站终端接收到的所有服务请求进行一个分类后的分流过程。售票请求全部传递给第一逻辑层201处理，其它请求全部由第二逻辑层202处理。这样售票请求和其它请求的处理就是分开独立的，相互之间并不影响。从而可以加快售票的效果，也得到应用服务器200可以同时处理更多的售票请求，而不至于导致系统瘫痪。

以上所述的仅是本发明的一些实施方式。对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (10)

1.轨道交通票务系统，其特征在于，包括：通用服务器（100）、应用服务器（200）和车站系统终端，

所述通用服务器（100）包括车票数据库（101），通用服务器（100）配置成为应用服务器（200）提供余票查询、售票、退票、登乘检验以及交易记录的服务，并根据应用服务器（200）的服务指令更新所述车票数据库（101）；

所述应用服务器（200）配置成接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器（100）；

所述车站系统终端包括售票终端（301）和登乘终端（302），所述售票终端（301）配置成接收乘客的余票查询请求、售票请求、退票请求和改签请求，并将服务请求传递至应用服务器（200），所述登乘终端（302）配置成接收乘客的登乘请求，并将服务请求传递到应用服务器（200）。

2.根据权利要求1所述的轨道交通票务系统，其特征在于，所述应用服务器（200）为双层结构，包括第一逻辑层（201）和第二逻辑层（202），

所述第一逻辑层（201）用于处理所述售票请求，并将相应的服务指令发送给第一逻辑层（201）进行分析，再传递给通用服务器（100）；

所述第二逻辑层（202）用于处理所述余票查询请求、退票请求和改签请求，并将相应的服务指令传递给通用服务器（100）。

3.根据权利要求2所述的轨道交通票务系统，其特征在于，所述通用服务器（100）为双机热备份结构；所述应用服务器（200）采用服务器集群方式部署成云端；所述车站系统终端根据业务处理需要向应用服务器（200）请求相应的服务，实现业务流程控制和处理。

4.根据权利要求3所述的轨道交通票务系统，其特征在于，所述应用服务器（200）包括管理服务模块（203）、售票模块（204）、检票模块（205）和席位管理模块（206），

所述管理服务模块（203）配置成对运营规则和售卖计划进行管理；

所述售票模块（204），配置成对乘客提出余票查询请求、售票请求、退票请求和改签请求进行处理；

所述检票模块（205）配置成检测乘客进站和出站时所刷票卡的信息进行检查；

所述席位管理模块（206）配置成提供席位的生成、搜索、占用、修改和删除处理服务。

5.根据权利要求4所述的轨道交通票务系统，其特征在于，所述应用服务器（200）还包括旅客管理模块（207）、储值卡模块（208）、票价计算模块（209）、路径计算模块（210）、发票服务模块（211）；

所述旅客管理模块（207）配置成包括常旅客管理子模块、特殊旅客管理子模块、旅客电子账户管理子模块和个性化服务管理子模块；

所述储值卡模块（208）配置成配置成对乘客持有的储值卡进行管理，所述储值卡的交易数据存储于通用服务器（100）；

所述票价计算模块（209）配置成完成票务系统的车票票价计算的功能；

所述路径计算模块（210）配置成对旅行线路进行规划计算，为旅客提供存在的各种换乘路径方案；

所述发票服务模块（211）配置成根据旅客的乘车记录，设置给予旅客自助打印的发票设备。

6.根据权利要求1至5中任一项所述的轨道交通票务系统，其特征在于，所述通用服务器（100）和应用服务器（200）处均配置负载均衡设备，减少用户等待响应的时间，通用服务器（100）和应用服务器（200）使用双电源、双网络适配器和RAID磁盘阵列。

7.在权利要求1所述的轨道交通票务系统中的购票验票方法，其特征在于，包括步骤：

车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器（200）；

应用服务器（200）接收车站系统终端传递来的服务请求，分类处理后，生成相应的服务指令并传递给通用服务器（100）；

通用服务器（100）为应用服务器（200）提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器（200）的服务指令更新通用服务器（100）内的车票数据库（101）。

8.根据权利要求7所述的购票验票方法，其特征在于，所述车票数据库（101）保存有计划余量表，所述计划余量表包括计划编号、车次、车厢顺序号、ＯＤ站序集、席位总数量；

所述车票数据库（101）配置成

当售票终端（301）收到乘客的售票请求后，席位总数量减1；

当售票终端（301）收到乘客的退票请求后，席位总数量加1；

当售票终端（301）收到乘客的余票查询请求后，返回席位总数量的当前值。

9.根据权利要求8所述的购票验票方法，其特征在于，所述车票数据库（101）中还保存有席位占用表，所述席位占用表包括车次车厢编号、车厢顺序号、包厢号、席位顺序号、席位属性、席位ＯＤ占用、席别定义、位置号；

所述车票数据库（101）配置成

当售票终端（301）收到乘客的售票请求时，当前席位的席位ＯＤ占用项标记为已占用；

当售票终端（301）收到乘客的退票请求时，当前席位的席位ＯＤ占用项恢复为未占用。

10.在权利要求2所述的轨道交通票务系统中的购票验票方法，其特征在于，包括步骤：

所述车站系统终端接收乘客的余票查询请求、售票请求、退票请求、改签请求和登乘请求，并将服务请求传递到应用服务器（200）；

应用服务器（200）接收车站系统终端传递来的服务请求，并进行分类；

应用服务器（200）的第一逻辑层（201）接收售票请求，处理后生成相应的服务指令，服务指令经过第二逻辑层（202）的分析后，再传递给通用服务器（100）；

应用服务器（200）的第二逻辑层（202）接收余票查询请求、退票请求、改签请求和登乘请求，处理后生成相应的服务指令并传递给通用服务器（100）；

通用服务器（100）为应用服务器（200）提供余票查询、售票、退票、改签、登乘检验以及交易记录的服务，并根据应用服务器（200）的服务指令更新通用服务器（100）内的车票数据库（101）。

Images