CN106920149A - 一种支持多方联网票务的方法 - Google Patents

Abstract

本发明公开了一种支持多方联网票务的方法，该方法包括：在各个站务公司建立相应配载线路，并且建立班次档案；集团范围内，将有公共途经站点的若干个不同站务公司的班次档案配置成组；集团范围内，将班次档案组发班，将待售车票推入中心票务服务器；将票务信息推送到指定票务服务器；票务客户端向本地应用服务器发送查询票务信息的请求；本地应用服务器将结果返回给票务客户端；票务客户端发送对某班次的锁票请求；若锁票成功，票务客户端发送售票请求；本地应用服务器将购票结果返回给发出请求的票务客户端；票务客户端根据购票结果进行后续票务操作。本发明提供的方法解决了各站务公司独立组织运输车辆方式导致高运输成本，低效益的问题。

Description

一种支持多方联网票务的方法

技术领域

本发明涉及互联网技术领域，特别涉及一种支持多方联网票务的方法。

背景技术

目前的公路客运集团票务系统主要以集团内部各站务公司为单位进行独立地操作与管理，在各个站务公司部署单独的票务服务器，各站的票务终端对应的锁票，售票，退票等操作都集中在这个票务服务器中完成，与其它各站互相隔离，从而避免了单点故障导致整个集团票务活动中止的状况。

同时，各个站务公司票务服务器本地化，能有效实现负载均衡，减小网络开销，从而减少票务操作的响应时间，很大程度上提升票务操作的效率和准确率。

但是，目前的公路客运集团票务系统还存在一些问题：

例如，对于若干站务公司都支持到达，但是单个站务公司购票乘客一般极少量的某些站点，因为每个站务公司是独立的票务服务器，所以每个站务公司都必须发布到达相应站点的班次并且提供运输车辆进行运输，站务运输成本高而上客率极低。特别是针对相对偏远的站点，这种高成本低收益的对比更加明显；

又例如，如果希望能各个站务公司单独售票，运输公司集中运输的话，又极有可能出现一个座位在多个站被多位乘客购买，出现总购票人数多于车辆总座位数的不合理情况。

公路客运集团各站务公司票务系统独立运作，当面对在各站务公司去往某些偏远站点的乘客稀少的现状时，各站务公司独立组织运输车辆方式必然导致高运输成本，低效益的问题。而若采用独立售票但集中运输的解决方案情况，公路客运集团内各站务公司之间分布式的票务服务器架构又无法确保满足票务信息的一致性和唯一性要求。因此，十分有必要在维持公路客运集团各站务公司票务系统独立运作且票务信息全局一致的前提下，提供一种支持多方联网的票务操作方法。

发明内容

本发明要解决的技术问题在于针对现有技术中的缺陷，提供一种支持多方联网票务的方法。

本发明解决其技术问题所采用的技术方案是：一种支持多方联网票务的方法，基于支持多方联网票务的服务器，所述支持多方联网票务的服务器，包括票务客户端、本地应用服务器、本地票务服务器和中心票务服务器；包括以下步骤：：

1)在各个站务公司建立配载线路，建立配载线路的一般步骤如下所述：根据实际客运需求，在票务活动所涉及到的多方站务公司内建立公用线路模板并关联建立包含若干途经站点的配载线路，需要设定的信息包括：线路名称，线路代码，起点站，终点站，所属线路模板，车型，车级，是否高速，以及线路上各个途经站点的途经顺序和从起点出发到达该站的默认价格信息；

2)在各个站务公司内建立班次档案；建立配载班次档案的步骤如下所述：根据实际需求，在多方站务公司内，在已有配载线路下，配载班次档案信息包括：所属线路，班次号，售卖类型，进站口，检票口；

集团范围内，将有公共途经站点的若干个不同站务公司的班次档案配置成配载组；

3)票务客户端根据用户需求向本地应用服务器发送查询途经某站的所有班次的票务信息的请求；

4）本地应用服务器根据请求查询条件、本地票务服务器和中心票务服务器的配置信息，查找本地班次，获得本地班次所属班次组；同时，本地应用服务器向中心票务服务器发送查询某班次组实时票务信息的请求；

5）中心票务服务器根据班次组编号以及日期等条件查询票务信息并返回结果给发出请求的本地应用服务器；

6）本地应用服务器在获取了从本地票务服务器和中心票务服务器返回的票务数据后，结合数据库中拿到的班次信息，将包含班次号，发班时刻，进站口，检票口，当前剩余票数等信息在内的结果返回给发出请求的票务客户端；

7）票务客户端向本地应用服务器发送对某班次的锁票请求；票务客户端向配置文件中所配置的本地应用服务器发送查询某天从某站务公司出发到达某站的所有班次以及这些班次的票务信息的请求，该请求应包含以下参数：日期，终点站，是否查询配载班次。

8）本地应用服务器向中心票务服务器发送对所查询班次所属的班次组进行锁票操作的请求；

9）中心票务服务器根据请求内容尝试锁票，并且将锁票操作结果返回给发出请求的本地应用服务器；

本地应用服务器将锁票结果返回给发出请求的票务客户端；

若锁票成功，则票务客户端可进行售票操作，若锁票失败，则票务客户端给出锁票失败提示；

10）若上一步锁票成功，票务客户端向本地应用服务器发送售票请求；

本地应用服务器根据请求的本地班次获取其班次组编号，根据时间，座位数等信息向中心票务服务器发送购票请求；

中心票务服务器尝试将对应车票移出配载班次票池，并将结果返回给发出请求的本地应用服务器；

本地应用服务器将购票结果返回给发出请求的票务客户端；票务客户端根据购票结果进行下一步票务操作。

按上述方案，所述步骤2）中将配载班次档案配置成配载组的一般步骤如下所述：根据实际需求选择一条线路模板，在给出的各个站务公司的属于此线路模板的配载班次档案列表中选择需要的班次档案，需要为配载班次档案组设定的信息包括：配载组编号，总座位数，生效日期，失效日期，运行天数，间隔天数，公共途经站点以及各个配载班次档案的发班时刻与次序，其中，生效日期，失效日期，运行天数，间隔天数与配载组某天能否发布班次组相关；配载组编号作为后续票务操作的重要参数信息，应该保证其唯一性；最终途经站点应该是所有组内班次本身的途经站点的交集的子集。

本发明产生的有益效果是：本发明在维持公路客运集团各站务公司票务系统独立运作且票务信息全局一致的前提下，提供一种支持多方联网的票务操作方法。本发明提供的方法解决了各站务公司独立组织运输车辆方式导致高运输成本，低效益的问题；同时，通过各个站务公司票务服务器本地化，能有效实现负载均衡，减小网络开销，从而减少票务操作的响应时间，很大程度上提升票务操作的效率和准确率。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1是本发明实施例的方法流程图；

图2是本发明实施例的多方联网票务操作时序图；

图3是本发明实施例的多方服务器集群关系图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

如图1所示，一种支持多方联网票务的方法，包括以下步骤：

1、多方范围内，建立配载线路及配载班次档案并将配载班次档案配置成配载组。

其中，建立配载线路的一般步骤如下所述：根据实际客运需求，在票务活动所涉及到的多方站务公司内建立公用线路模板并关联建立包含若干途经站点的配载线路，需要设定的信息包括：线路名称，线路代码，起点站，终点站，所属线路模板，车型，车级，是否高速，以及线路上各个途经站点的途经顺序和从起点出发到达该站的默认价格等信息。

例如，在武昌站务公司，“武汉-安庆”线路模板下，建立一条线路名称为“付家坡-安庆（配载）”，代码为“WC-AQ”，起点站为付家坡，按顺序途经太湖，月山，潜山，宿松，终点为安庆，车型为座席，车级为高一级的高速配载线路，并且为每个途经站点设置默认价格。

其中，建立配载班次档案的一般步骤如下所述：根据实际需求，在多方站务公司内，在已有配载线路下，建立配载班次档案，需要设定的信息包括：所属线路，班次号，售卖类型，进站口，检票口等。需要说明的是，配载班次档案所属的站务公司与其所在的配载线路所属的站务公司是保持一致的，线路模板在多方范围内公用，但是配载线路一定是属于某站务公司的；班次号具有唯一性。

例如，在武昌站务公司的“付家坡-安庆（配载）”线路下，建立一个班次号为“FJ0001P”，售卖类型为全网售，进站口为12进站口，检票口为A11检票口的配载班次档案，则此配载班次档案在不主动过滤途经站点的情况下，将从付家坡出发，按顺序途经太湖，月山，潜山，宿松，并最终到达安庆。

其中，将配载班次档案配置成配载组的一般步骤如下所述：根据实际需求选择一条线路模板，在给出的各个站务公司的属于此线路模板的配载班次档案列表中选择需要的班次档案，需要为配载班次档案组设定的信息包括：配载组编号，总座位数，生效日期，失效日期，运行天数，间隔天数，公共途经站点以及各个配载班次档案的发班时刻与次序，其中，生效日期，失效日期，运行天数，间隔天数与配载组某天能否发布班次组相关；配载组编号作为后续票务操作的重要参数信息，应该保证其唯一性；最终途经站点应该是所有组内班次本身的途经站点的交集的子集。

例如，选定“武汉-安庆”线路模板，选择预先创建好的武昌站务公司的“FJ0001P”班次档案以及宏基站务公司的“HJ0004P”配载班次档案创建配载组“AQPZS001”，并且设定座位数为39，运行天数为1，间隔天数为2，生效日期为2016-08-29，失效日期为2016-12-31，选取公共途经站点，设定途经站“FJ0001P”班次发班时刻为07:30，“HJ0004P”班次发班时刻为08:10，从发班时刻上可以看出，车先经过武昌站务公司，然后到宏基站务公司，再按照次序到各个途经站点。

需要说明的是，对于座位数，运行天数，间隔天数，途经站点这样的信息是控制在一个配载组上的，对于同一个配载组内的所有班次，上述信息是保持一致的。而对于具体的票价，班次计划的开停信息，每个站务公司可以各自定义，同组内不同班次之间可以不相同。

将配载班次档案配置成配载组需要至少满足以下条件：同一个配载班次档案至多只能参与到一个配载组；只有同一个线路模板下的班次档案才能配置到同一组；每个配载组至少包含2个配载班次档案；同一个组内不能存在两个或两个以上同属于同一站务公司的配载班次档案。

配置成功的配载组仍可在满足上述条件的前提下进行重配置操作，包括：增加或删除组内班次档案；对配载组的座位数，发班时刻等信息进行调整等。特别是在后续配载班次档案组已经发布过班次的情况下，以上修改能实时应用。

上述实体间存在以下约束：一条线路模板下，可以在不同站务公司内或者是同一站务公司内存在多条线路；一条配载线路下，可以根据实际需求创建若干个配载班次档案。

2、根据配载组中配载班次档案，生成班次计划，如下所述：

根据配载组的生效日期，失效日期，运行天数，间隔天数数据，给出今天及以后的某个发班日期能够发布的配载组集合；

具体的规则为，若同时满足：发班日期=生效日期+（运行天数+间隔天数）*m（m>0且为整数）+运行天数；生效日期<=发班日期<=失效日期，则这样的发班日期当天此配载组是允许发班的。所选择的的发班日期可以比当前日期大，即提前发班开始预售。例如，2016-8-29号可以发布2016-9-3号的班次。

在允许发班的配载组集合中，按照实际需求，对集合中部分或者全部配载组进行发班操作，这个操作包含的后台任务主要是将班次的静态信息存储入关系数据库，将票务信息按照一定的数据结构推送至中心票务服务器。

具体推送入中心票务服务器的车票数据格式为“发班日期:配载组编号:座位号”，还有其它的配套使用的辅助数据格式，如“发班日期:配载组编号:Lock”（表示某配载班次组锁票的集合）以提升票务操作性能。

实现这种将票务信息推送到指定票务服务器的功能需要在本地应用服务器上配置一系列的IP地址，端口号等信息，既需要本地票务服务器的配置，也需要中心票务服务器的配置。此部分重点在于说明配载班次档案的建立，配载组的配置以及发布的具体实施方式，实际情况下，每个站务公司还存在普通本地班次的建立以及发布的过程，发布普通本地班次时，票务信息将被推送到本地票务服务器，使用“日期:班次号:座位号”来唯一标识一张车票。

根据配载组中配载班次档案，生成班次计划包括：

根据实际班次营运日期，预先（提前一日或数日）制定班次计划并将票务信息推送到票务服务器。站务公司本地应用服务器保存有本地票务服务器以及中心票务服务器的编号、及IP地址列表。在生成班次计划时，班次信息将保存到数据库中，而票务信息则将根据班次的类型，分别推送至不同的票务服务器。具体规则是：各站务公司普通本地班次票务信息，推送至本地票务服务器；配载班次票务信息，推送至中心票务服务器。

在制定了班次计划之后，在票务活动进行的过程中，可以随时对既定的生成计划和中心票务服务器实时数据进行调整。联网实时票务数据的变更操作包括：

对于中心票务服务器中的联网实时票务数据，可以进行座数的增减操作、班次的开停操作，也可以在对配载组基础信息进行修改时，将相关变更推送至实时票务服务器，即刻生效。

本地应用服务器在本地保存的票务服务器IP地址列表中，查找到中心票务服务器的地址；并将实时票务数据的变更请求提交至中心票务服务器。

同一配载组内班次不要求同时发布，即可以将属于同一组的若干班次分几次发布，这种异步的方式不会影响到票务信息的业务正确性。

实际情况下，本地应用服务器，本地票务服务器，中心票务服务器的关系结构如图3所示，其中，票务服务器有主票务服务器和从票务服务器以避免单点故障，同时采用读写分离机制以有效提高票务服务器的运行效率。

3、对已经发布成功的配载组进行实时票务信息的修改，不论是配载班次组还是各个站务公司的普通本地班次，在发布之后都存在需要调整的可能性，主要可以通过以下两种方式实现：

A、可以对某一发布成功的配载班次组进行座位数的增减操作，途经站点的过滤操作，也可以针对组内某一特定配载班次调整其发班时刻，到达站点的价格，进站口，检票口等信息。

其中对座位数的调整应满足：调整后的座位数不能小于已售票数和已锁票数的和。座位数的增减操作对应到中心票务服务器的动作是增加或者减少一批“日期:配载组编号:座位数”结构的票务数据，同时维护包含Lock集合在内的其它辅助数据结构的数据，来保证票务信息的一致性。

B、将对配载班次档案组的修改，实时应用到与这个配载班次档案组对应的已发班的配载班次组上。

这种修改方案下，由于一个配载班次档案组可以在若干天里存在与之对应的配载班次组，对配载班次档案组的修改将被应用到该配载班次档案组今天及以后的所有配载班次组，包括以下信息的修改：座位数，途径站点等，而对于票价，发班时刻，进站口，检票口这些与具体班次有关的实时票务数据的修改，可以通过修改其对应的配载班次档案的信息并刷新到已发班班次上的方式来实现。

对于座位数的修改，所有涉及到的配载班次组都应该满足调整后的座位数不能小于已售票数和已锁票数的和，如果有一个不满足，则整个操作不能成功完成，此时需要应用A方法对配载班次组进行单独的修改而不能成功批量调整。

普通本地班次以及配载班次组成功发布之后，票务客户端可进行相应的票务操作，包括查询票务信息，锁票，购票，退票等，如图2时序图所示。

4、票务客户端请求获取班次及相关票务信息，如下所述：

票务客户端向配置文件中所配置的本地应用服务器发送查询某天从某站务公司出发到达某站点的所有班次以及这些班次的票务信息的请求，该请求应包含以下参数：日期，终点站，是否查询配载班次。

其中，是否查询配载班的参数是配置在本地应用服务器配置文件中的，一般情况下，参数值为True，即允许查询配载班次，但在由于本地到中心的网络出现问题等原因导致本地应用服务器无法访问中心票务服务器的特殊情况下，这个参数将被设置为False，即本地应用服务器不对配载班次进行票务操作。

本地应用服务器根据所请求的内容在关系数据库中找到满足条件的所有普通本地班次以及在允许查询配载班次的条件下的本地配载班次集合。对于普通本地班次，本地应用服务器将逐一向本地票务服务器发送查询班次的票务信息，即本地票务服务器中“日期:班次号”集合和其它锁票集合差集的结果；对于本地配载班次，本地应用服务器将逐一查询本地配载班次所属配载班次组的信息，并且向中心票务服务器发送查询配载班次组票务信息的请求，即中心票务服务器中“日期: 配载组编号”集合和其它锁票集合差集的结果。

本地应用服务器在获取了从本地票务服务器和中心票务服务器返回的票务数据后，结合本地关系数据库中拿到的班次信息，将包含班次号，发班时刻，进站口，检票口，当前剩余票数等信息在内的结果返回给发出请求的票务客户端。

票务客户端根据上述结果来进行下一步票务操作。

5、票务客户端向本地应用服务器发送锁票请求尝试锁票，如下所述：

本地应用服务器在本地保存的票务服务器IP地址列表中，查找到中心票务服务器的地址；对于配载班次，各站务公司本地服务器必须将客户端请求中所包含的班次编号，根据其所属的配载组配置信息，转换为对应的配载组编号；使用班次营运日期加上配载组编号所形成的唯一标识符，将票务查询请求转发至中心票务服务器。

票务客户端在上述查询请求返回了结果的前提下，选择列表中某一班次向本地应用服务器发送锁票请求，尝试锁票操作，该请求应包含以下参数：具体班次，座位数。

本地应用服务器判断所请求的班次是普通本地班次还是配载班次，如果是普通本地班次，本地应用服务器将向本地票务服务器发送在某一具体班次上锁定指定座位数票的请求，该请求包含以下参数：日期，班次号，座位数。

本地票务服务器将尝试锁票，锁票操作主要包括将座位号加入“日期:班次号:Lock”集合，需要说明的是，即使在上述查询过程中查询得出的可售余票数大于此次请求的座位数，仍不能保证此次锁票成功；或者在上述查询过程中查询得出的可售余票数小于此次请求的座位数，仍不能确认此次锁票必然失败，因为票务数据实时性强，其它票务客户端在本次查询操作与锁票操作间隔时间内可能操作同一班次并已经锁票购票成功或者退票成功，因此当前实时票务数据和原先查询出来的结果可能存在不一致之处。本地票务服务器将锁票操作结果（成功/失败）返回给本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

如果所请求的班次是配载班次，本地应用服务器将首先查询本地关系数据库，找到该班次所属的配载班次组的数据，将对配载班次的锁票请求转换成对配载班次组的锁票请求。本地应用服务器向中心票务服务器发送在某一具体配载班次组上锁定指定座位数票的请求，该请求包含以下参数：日期，配载班次组编号，座位数。

中心票务服务器将尝试锁票，并且将操作结果返回给发出请求的本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

票务客户端根据锁票结果决定后续操作，例如，若锁票成功，票务客户端可以进一步进行购票操作；若锁票失败，票务客户端可以重新选择其它班次进行锁票购票操作。已经被成功锁定的票，根据相关参数的配置，可以被锁定一段时间。

例如，设定锁票时间为8分钟，当票被锁定之后开始自动倒计时，如果在八分钟内，购票操作因为某些原因没有完成，对票的锁定将自动失效，票又可以被重新锁定。

6、票务客户端向本地应用服务器发送购票请求尝试购票，如下所述：

本地应用服务器在本地保存的票务服务器IP地址列表中，查找到中心票务服务器的地址；对于配载班次，各站务公司本地服务器必须将客户端请求中所包含的班次编号，根据其所属的配载组配置信息，转换为对应的配载组编号；本地应用服务器向中心票务服务器发送对所查询班次所属的班次组进行锁票操作的请求；中心票务服务器根据请求内容尝试锁票，并且将锁票操作结果返回给发出请求的本地应用服务器；本地应用服务器将锁票结果返回给发出请求的票务客户端；

若锁票成功，则票务客户端可进行售票操作，若锁票失败，则票务客户端给出锁票失败提示。

客户端售票请求的处理包括：

本地应用服务器根据请求的本地班次获取其班次组编号，根据时间、座位数等信息向中心票务服务器发送购票请求。在此过程中，本地应用服务器需要在本地保存的票务服务器IP地址列表中，查找到中心票务服务器的地址；对于配载班次，各站务公司本地应用服务器必须将客户端请求中所包含的班次编号，根据其所属的配载组配置信息，转换为对应的配载组编号；

中心票务服务器根据条件尝试将对应票移出票务服务器（票池），并将结果返回给发出请求的本地应用服务器；班次营运日期+配载组编号+车票座位号，可以在中心票务服务器中，唯一地标识一张配载班次的待售车票。

票务客户端在上述锁票操作成功的前提下，可以放弃购买，手动解锁车票或者等待锁定时间到期后车票自动解锁，也可进一步执行购票操作，尝试购票，该请求应包含以下参数：具体班次，座位号集合。

本地应用服务器判断所请求的班次是普通本地班次还是配载班次，如果是普通本地班次，本地应用服务器将向本地票务服务器发送在某一具体班次上购买某些座位号的车票请求，该请求包含以下参数：日期，班次号，座位号集合。

本地票务服务器将尝试购票，购票操作主要包括将座位号集合内所有票加入“日期:班次号:Saled”集合，删除“日期:班次号:座位号”车票数据等。一般来说，锁票成功后，购票操作基本能成功，本地票务服务器将购票操作结果（成功/失败）返回给本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

如果所请求的班次是配载班次，本地应用服务器将首先查询本地关系数据库，找到该班次所属的配载班次组的数据，将对配载班次的购票请求转换成对配载班次组的购票请求。本地应用服务器向中心票务服务器发送在某一具体配载班次组上购买指定座位号集合的车票请求，该请求包含以下参数：日期，配载班次组编号，座位号集合。

中心票务服务器将尝试购票，并且将操作结果返回给发出请求的本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

票务客户端获取结果后可进行其它票务操作。

7、票务客户端向本地应用服务器发送退票请求尝试退票，如下所述：

对于已经成功购票但是乘客因为某些原因不能乘坐需要退票的情况，票务客户端将根据需求向本地应用服务器发送退票请求及尝试退票操作。

本地应用服务器根据扫描到的车票票号信息查询本地关系数据库中该车票所属的班次信息，确认信息属实后可以选择退票操作，具体的手续费和退款将由售票员根据实际情况确定。

本地应用服务器查询出该车票所属的班次，座位数等信息，判断该退票所属班次是普通本地班次还是配载班次，如果是普通本地班次，本地应用服务器将向本地票务服务器发送退某一具体班次上已购买的某座位号的车票请求，该请求包含以下参数：日期，班次号，座位号。

本地票务服务器将尝试退票，退票操作主要包括将座位号从“日期:班次号:Saled”集合移除，加入“日期:班次号:座位号”数据，如果此前该班次上票已经售完，则可能还需要在本地票务服务器中尝试恢复“日期:班次号”集合。本地票务服务器将退票操作结果（成功/失败）返回给本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

如果该退票所属班次是配载班次，本地应用服务器将首先查询本地关系数据库，找到该班次所属的配载班次组信息，将对配载班次的退票请求转换成对配载班次组的退票请求。本地应用服务器将向中心票务服务器发送退某一具体配载班次组上已购买的某座位号的车票请求，该请求包含以下参数：日期，配载班次组编号，座位号。

中心票务服务器将尝试退票，并且将操作结果返回给发出请求的本地应用服务器，本地应用服务器将结果返回给发出请求的票务客户端。

票务客户端获取结果，如果成功则退票成功，该票仍可再次被购买。如果失败，则给出相应提示信息。

应当理解的是，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，而所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (3)

1.一种支持多方联网票务的方法，基于支持多方联网票务的服务器，所述支持多方联网票务的服务器，包括票务客户端、本地应用服务器、本地票务服务器和中心票务服务器；其特征在于，包括以下步骤：

1)在各个站务公司建立配载线路，建立配载线路的步骤如下所述：根据实际客运需求，在票务活动所涉及到的多方站务公司内建立公用线路模板并关联建立包含若干途经站点的配载线路；

2)在各个站务公司内建立班次档案；建立配载班次档案的一般步骤如下所述：根据实际需求，在多方站务公司内，在已有配载线路下，配载班次档案信息；配载班次档案中信息包括：所属线路，班次号，售卖类型，进站口，检票口；

集团范围内，将有公共途经站点的若干个不同站务公司的班次档案配置成配载组；

3)票务客户端根据用户需求向本地应用服务器发送查询途经某站的所有班次的票务信息的请求；

4）本地应用服务器根据请求查询条件、本地票务服务器和中心票务服务器的配置信息，查找本地班次，获得本地班次所属班次组；同时，本地应用服务器向中心票务服务器发送查询某班次组实时票务信息的请求；

5）中心票务服务器根据班次组编号以及日期等条件查询票务信息并返回结果给发出请求的本地应用服务器；

6）本地应用服务器在获取了从本地票务服务器和中心票务服务器返回的票务数据后，结合关系数据库中拿到的班次信息，将包含班次号，发班时刻，进站口，检票口，当前剩余票数等信息在内的结果返回给发出请求的票务客户端；

7）票务客户端向本地应用服务器发送对某班次的锁票请求；票务客户端向配置文件中所配置的本地应用服务器发送查询某天从某站务公司出发到达某站的所有班次以及这些班次的票务信息的请求，该请求包含以下参数：日期，终点站，是否查询配载班次；

8）本地应用服务器向中心票务服务器发送对所查询班次所属的班次组进行锁票操作的请求；

9）中心票务服务器根据请求内容尝试锁票，并且将锁票操作结果返回给发出请求的本地应用服务器；

本地应用服务器将锁票结果返回给发出请求的票务客户端；

若锁票成功，则票务客户端可进行售票操作，若锁票失败，则票务客户端给出锁票失败提示；

10）若上一步锁票成功，票务客户端向本地应用服务器发送售票请求；

本地应用服务器根据请求的本地班次获取其班次组编号，根据时间，座位数等信息向中心票务服务器发送购票请求；

中心票务服务器尝试将对应车票移出配载班次票池，并将结果返回给发出请求的本地应用服务器；

本地应用服务器将购票结果返回给发出请求的票务客户端；票务客户端根据购票结果进行下一步票务操作。

2.根据权利要求1所述的支持多方联网票务的方法，其特征在于，所述步骤1）中配载线路需要设定的信息包括：线路名称，线路代码，起点站，终点站，所属线路模板，车型，车级，是否高速，以及线路上各个途经站点的途经顺序和从起点出发到达该站的默认价格信息。

3.根据权利要求1所述的支持多方联网票务的方法，其特征在于，所述步骤2）中将配载班次档案配置成配载组的一般步骤如下所述：根据实际需求选择一条线路模板，在给出的各个站务公司的属于此线路模板的配载班次档案列表中选择需要的班次档案，需要为配载班次档案组设定的信息包括：配载组编号，总座位数，生效日期，失效日期，运行天数，间隔天数，公共途经站点以及各个配载班次档案的发班时刻与次序，其中，生效日期，失效日期，运行天数，间隔天数与配载组某天能否发布班次组相关；配载组编号作为后续票务操作的重要参数信息，应该保证其唯一性；最终途经站点应该是所有组内班次本身的途经站点的交集的子集。