窄带网路结构下的区域客运联网售票可靠交易系统

摘要

本发明公开一种窄带网路结构下的区域客运联网售票可靠交易系统，包括客户终端、本地服务器端、中心服务器端和异地服务器端，售票分为本站售票、和跨站售票，其中，本站售票为客户终端仅与本地服务器端进行查询班次、取票价、锁票、取票号程序，不经过中心服务器端，然后本地服务器端进行数据入库，再与中心服务器端进行售票座位图更新，完成售票；跨站售票程序中将中心服务改进异站流程，将锁票终点扩展到异站，实现两个流程终点一致；并且采用消息队列技术机制实现交易数据的可靠传输，完成票务交易事务的处理，保证系统的高可用性与高安全性。

权利要求

1.一种窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：包括客户终端、本地服务器端、中心服务器端和异地服务器端，售票分为本站售票、和跨站售票，其中，本站售票为客户终端仅与本地服务器端进行查询班次、取票价、锁票、取票号程序，不经过中心服务器端，然后本地服务器端进行数据入库，再与中心服务器端进行售票座位图更新，完成售票；

跨站售票为客户终端经本地服务器端与中心服务器端进行班次查询；客户终端选择班次后经本地服务器端和中心服务器端与异地服务器端进行取票价，异地服务器端返回票价并附带座位数字符串至客户终端；客户终端经本地服务器端和中心服务器端与异地服务器端进行选座锁票；客户终端经本地服务器端与中心服务器端进行取票号；客户终端经本地服务器端和中心服务器端向异地服务器端发购买申请，异地服务器端进行售票更新后经中心服务器端和本地服务器端至本地入库，完成售票；且本地服务器端对客户终端发送的请求以对列的形式进行处理。

2.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述查询班次信息为发车站、日期和目的地。

3.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述本站售票程序中，由客户终端向本地服务器端发出更新中心申请，再由本地服务器端向中心服务器端上传数据，更新座位图，更新成功后经本地服务器端返回至客户终端，完成售票。

4.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述跨站售票程序中，客户终端向本地服务器端发查询班次请求，由本地服务器端向中心服务器端填写匹配查询班次。

5.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述异地服务器端返回票价包含检票口信息。

6.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述跨站售票锁票程序中，客户终端发选座锁位至本地服务器端，本地服务器端向中心服务器端发锁中心位请求，中心服务器端向异地服务器端发锁远程位，再由异地服务器端经过中心服务器端和本地服务器端向客户终端返回锁位。

7.根据权利要求6所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述异地服务器端设有站内监视异站锁票。

8.根据权利要求6所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述客户终端的乘客指定的锁位，因为锁冲突的原因而不能成功锁票时，服务自动选择下一系列符合条件的座位进行锁位。

9.根据权利要求1所述的窄带网路结构下的区域客运联网售票可靠交易系统，其特征在于：所述异地服务器端附带返回的班次座位字符串的格式是以逗号分割的座位状态序列，长度为座位数。

说明书

窄带网路结构下的区域客运联网售票可靠交易系统

技术领域

[0001] 本发明涉及联网售票系统技术领域，特别是指一种窄带网路结构下的区域客运联网售票可靠交易系统。

背景技术

[0002] 现代网络技术与计算机技术的飞速发展，交通工具的技术发展，以及道路建设的日益扩张，人类迁移活动能力的提升，对传统运输行业带来革新的命题，完成信息化改造是保持传统运输行业盈利水平，及提升服务质量的重要途径。

[0003] 目前，国人主要采用的长途出行方式有飞机、火车、客运汽车三种方式。在信息化建设方面，飞机出行方式无论是从调度与售票系统，由于国家管控级别高，机务票务相对独立封闭，以及建设规格较高，调度与票务相对集中，信息化基建容易形成统一的规划，用户群体平均水平较高，数量增长稳定，票务系统建设相对成熟。火车出行的信息化建设类似，在可控的渠道以及站场管理下稳步发展符合铁路运输特色的票务服务，其中以12306网站为代表的票务系统建设日趋成熟；只有汽车出行的方式目前尚处于各地市自行组织建设，区域运力由大量运输公司以及客运站场组织，区域联网面少点多，尚未形成跨地市、省级甚至国级的联网售票交易系统。

[0004] 而汽车出行与其他两种有着本质区别：第一、覆盖人数多，需求大，体现在省内外城市间商贸、旅游、求学等活动频繁，周边城乡的探亲来往、农贸商贸、务工等需求旺盛；长途班车的行包快运业务发展与区域小件物流的旺盛需求相得益彰。第二、灵活性更大，班车资源国营、民企参半，线路运营市场相对开放，带来服务质量、运力、价格各方面的差异化，以及调整的灵活性，对信息系统数据更新的即时性要求高。第三、网络质量参差不齐，多数区(县)、镇(乡)级客运站(收客点、售票点)间使用不稳定的网络链路连接，因经营成本问题往往采用窄带网络。第四、系统建设水平差异大，技术庞杂，体系迥异。由于各地历史发展的差异，在不同时期，采用不同架构体系，不同工具，建设了结构差异较大的当地票务系统，客观上造成联网交易可靠性上的困难，在技术上考虑异构数据库，以及异构平台的消息通信成为必选课题。第五、在核心城市区域联网交易存在高并发高数据读写应用场景。

[0005] 经过现实考察的大量的、具有代表性的客运票务系统以及区域性联网售票平台，一般都为了屏蔽差异性，设计为甲方售票系统——〉代理(前置服务器)——〉中心服务器——〉代理(前置服务器)——〉乙方售票系统的逻辑结构，以区域联网票务中心数据库记录为数据查询标准，成功入库作为最终交易有效的标志——中心数据库需要最及时的数据更新，包括班次、座位、票价等，与客运站数据库实现秒级同步，尤其是在核心城市春运市场延时问题将变得非常尖锐。

[0006] 售票系统接入联网售票平台一般有两种途径：一种是平台侧提供支持跨平台的api接口，供站方售票系统设计方调用并改造己方系统；另一种是站方售票系统设计方提供提供数据缓冲池，或称中间数据表或相关存储过程，供平台侧直接访问调阅，这样的策略急剧增加中心平台设计和管理的复杂性，市面上基本不采用。本系统仅从平台侧，即第一种途径提出解决方案。

[0007] 有代表性的售票处理流程设计，如图1所示，实际运行中，此设计往往暴露出以下问题及一些隐患：

[0008] 第一、大部分的时间运作正常，在遭遇客流高峰的时候系统运行出现问题的概率增大，集中表征是中心系统由于数据库表锁资源竞争等原因引致服务进程资源耗尽，甚至停顿；由于事务处理的强一致性造成客户端进程等待，进而波及各大站场的大部分客户端，均反映交易缓慢甚至停顿。例如黄金周长假和春运时期，广州地区2006年五一期间数据库出现较大事故时，连线交易几乎全面停顿。

[0009] 第二、以上情况在窄带地区网络质量不高的情况会体现为大部分的时间运作正常，但是间歇性遭遇系统无响应状况，期间售票停顿时间较长影响生产。特征：持续时间短，一般大部分时间小于1min，但是发生频度各站不一且时间点不确定，有的一月数次，有的一周数次。

[0010] 第三、异站交易的成功率较低，客运站反映的问题集中于目的地站点错误、在锁位收款的情况下发现异站更新不成功，中心班次座位图更新不及时等问题；由于事务链条的意外断开，导致客运站方不能监测和及时恢复被意外锁定的座位，客观上浪费了运力资源，造成经济损失。

[0011] 第四、为保证实时同步到中心数据库，班次调度信息上传时间有时候过长，消耗资源较大，全部上传时会导致系统性能下跌较厉害；即使是分时上传时间受限制，个别站由于企业生产习惯的原因或者能力不够，不能在原定时间前完成调度。

[0012] 实际上，本站自售票的比例约占跨站售票的97％以上，而引起延时故障的事务处理往往集中在跨站票交易中。

[0013] 因此，有必要设计一种窄带网路结构下的区域客运联网售票可靠交易系统，以解决上述技术问题。

发明内容

[0014] 针对背景技术中存在的问题，本发明的目的是提供一种窄带网路结构下的区域客运联网售票可靠交易系统，以分而治之的理念拆分本站售票流程以及跨站售票流程，并对个别环节加以改提良，达到更高的可用性、可扩展性、可移植性。

[0015] 本发明的技术方案是这样实现的：一种窄带网路结构下的区域客运联网售票可靠交易系统，包括客户终端、本地服务器端、中心服务器端和异地服务器端，售票分为本站售票、和跨站售票，其中，本站售票为客户终端仅与本地服务器端进行查询班次、取票价、锁票、取票号程序，不经过中心服务器端，然后本地服务器端进行数据入库，再与中心服务器端进行售票座位图更新，完成售票；跨站售票为客户终端经本地服务器端与中心服务器端进行班次查询；客户终端选择班次后经本地服务器端和中心服务器端与异地服务器端进行取票价，异地服务器端返回票价并附带座位数字符串至客户终端；客户终端经本地服务器端和中心服务器端与异地服务器端进行选座锁票；客户终端经本地服务器端与中心服务器端进行取票号；客户终端经本地服务器端和中心服务器端向异地服务器端发购买申请，异地服务器端进行售票更新后经中心服务器端和本地服务器端至本地入库，完成售票；且本地服务器端对客户终端发送的请求以对列的形式进行处理。

[0016] 在上述技术方案中，所述查询班次信息为发车站、日期和目的地。

[0017] 在上述技术方案中，所述本站售票程序中，由客户终端向本地服务器端发出更新中心申请，再由本地服务器端向中心服务器端上传数据，更新座位图，更新成功后经本地服务器端返回至客户终端，完成售票。

[0018] 在上述技术方案中，所述跨站售票程序中，客户终端向本地服务器端发查询班次请求，由本地服务器端向中心服务器端填写匹配查询班次。

[0019] 在上述技术方案中，所述异地服务器端返回票价包含检票口信息。

[0020] 在上述技术方案中，所述跨站售票锁票程序中，客户终端发选座锁位至本地服务器端，本地服务器端向中心服务器端发锁中心位请求，中心服务器端向异地服务器端发锁远程位，再由异地服务器端经过中心服务器端和本地服务器端向客户终端返回锁位。

[0021] 在上述技术方案中，所述异地服务器端设有站内监视异站锁票。

[0022] 在上述技术方案中，所述客户终端的乘客指定的锁位，因为锁冲突的原因而不能成功锁票时，服务自动选择下一系列符合条件的座位进行锁位。

[0023] 在上述技术方案中，所述异地服务器端附带返回的班次座位字符串的格式是以逗号分割的座位状态序列，长度为座位数。

[0024] 本发明窄带网路结构下的区域客运联网售票可靠交易系统，通过将本站售票流程仅在本地处理，数据不再经过中心，节约时间和避免数据延误；而跨站售票中，将锁票终点扩展到异地服务器端，实现两个流程终点一致；并且采用消息队列技术机制实现交易数据的可靠传输，完成票务交易事务的处理，保证系统的高可用性与高安全性。

附图说明

[0025] 图1为目前通用的售票处理流程的异地交易流程示意图；

[0026] 图2为本发明的本站交易流程示意图；

[0027] 图3为本发明的异地交易流程示意图；

[0028] 图4为本发明的使用可靠队列方式的对比示意图；

[0029] 图5为本站售票更新服务流程运作原理图；

[0030] 图6为前端代理服务设计流程逻辑图；

[0031] 图7为供站方使用的API接口设计流程逻辑图。

具体实施方式

[0032] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

[0033] 如图1至所示，本发明所述的一种窄带网路结构下的区域客运联网售票可靠交易系统。以分而治之的理念将联网售票拆分本站售票流程和跨站售票流程，并对个别环节加以改良，充分利用事务处理的四特性(ACID，原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability))；利用消息队列对业务进行解耦，又保持事务一致性。

[0034] 本发明窄带网路结构下的区域客运联网售票可靠交易系统包括客户终端1、本地服务器端2、中心服务器端3和异地服务器端4。售票分为本站售票、和跨站售票。

[0035] 因为一般在本站售票交易流程中，先查本站班次，然后到中心锁位。现实中发生比较多的是，班次调度与中心数据有可能发生不一致，或者站点编码对应错误，该流程就会返回“锁中心失败”的应用错误。这个现象可以从中心的日志记录中寻找到不少纪录。一方面这种等待对于售票流程而言不是必需的，事实上目前多数的售票软件在设计上会忽略这些错误；另一方面，这种等待也占用了系统的宝贵资源。

[0036] 因此，如图2所示，将本站售票流程仅在本地处理，数据不再经过中心，但是本站售票更新/退票/废票时，仍然通过中心，并且修改中心座位图——与原流程一致。

[0037] 具体的，本站售票为为客户终端1仅与本地服务器端2进行查询班次、取票价、锁票、取票号程序，不经过中心服务器端3，然后本地服务器端2进行数据入库，由客户终端1向本地服务器端2发出更新中心申请，再由本地服务器端2向中心服务器端3上传数据更新座位图，更新成功后经本地服务器端2返回至客户终端1，完成售票；其中，查询班次信息为发车站、日期和目的地。

[0038] 而在一般异站交易流程中，锁票与售票更新是两个独立发起的交易动作，但是动作的终点分别是中心和异地，这样就要求中心和异地的数据高度一致，并且异地数据库根据交易协议不设任何限制，即保证中心锁票的结果，就是售票更新中一定可销售的。现实发生的情况是，中心与异地的数据因为网络质量、同步策略、协议理解不同、开发质量参差等因素总有差异，那么中心成功锁票后，最终交易却因为数据不一致或者站内某些限制不允许售卖，导致最后的交易——售票更新失败。这也是售票员经常抱怨的“已经锁定票并且收了客人钱款，最后却卖票失败”的现实尴尬情景。

[0039] 因此，如图3所示，中心服务改进异站流程，将锁票终点扩展到异站，实现两个流程终点一致；要求站方提供针对异站票的锁票(位)/订票(位)监视机制，同时对该类票辅以合理的监视，例如超过一定的时间阀值将进行自动释放等。如此产生的场景将是：售票员在锁定座位的环节就知道站内是否可售。同时由于订票方式的提供，应用上更加灵活。

[0040] 具体的，跨站售票为客户终端1向本地服务器端2发查询班次请求，由本地服务器端2向中心服务器端3填写匹配查询班次。客户终端1选择班次后经本地服务器端2和中心服务器端3与异地服务器端4进行取票价，异地服务器端4返回票价并附带座位数字符串至客户终端1；异地服务器端4附带返回的班次座位字符串的格式是以逗号分割的座位状态序列，长度为座位数，例如“0,0,0,1,1…”。同时异地服务器端4返回票价包含检票口信息。

[0041] 客户终端1经本地服务器端2和中心服务器端3与异地服务器端4进行选座锁票；其中，客户终端1发选座锁位至本地服务器端2，本地服务器端2向中心服务器端3发锁中心位请求，中心服务器端3向异地服务器端4发锁远程位，再由异地服务器端4经过中心服务器端3和本地服务器端2向客户终端1返回锁位。异地服务器端4设有站内监视异站锁票，为提高锁票的成功率，站方提供的锁票服务建议设计成：乘客指定的锁位因为锁冲突等可预见的原因而不能成功锁票时，服务自动选择下一系列符合条件的座位进行锁位。

[0042] 然后客户终端1经本地服务器端2与中心服务器端3进行取票号；客户终端1经本地服务器端2和中心服务器端3向异地服务器端4发购买申请，异地服务器端4进行售票更新后经中心服务器端3和本地服务器端2至本地入库，完成售票。

[0043] 因常规的服务应答方式，同步情况下要求阻塞进程以等待返回，异步情况下虽然响应快，但是要求对返回信息做复杂的逻辑处理。这种情况在处理售票更新等关键的事务性质的业务时矛盾更为突出。

[0044] 现运行系统应用事务的主要方式还是采用同步方式。但是根据前述，对于占总交易量的99.7％的本站售票业务，要作重点保证。在现行系统的运行中，售票更新这一环节出现缓慢的现象时有反映，我们可以理解是因为同步方式调用的天然缺陷。同步方式的运用要求有充足的带宽，优良的网络和强劲迅速的处理能力，这里面任何一个环节出现性能问题都会引起功能性阻塞

[0045] 因此在本地本地服务器端对客户终端发送的请求以对列的形式进行处理，本站售票数据更新处理流程上，采用可靠消息队列的方式进行调优。原因是：

[0046] 第一、本站自售票数据的上传的实时要求，相对异站票要略为宽松，在以往的设计中，在网络故障下甚至可以允许在本地缓存。

[0047] 第二、前提假设，客户机器与代理机器之间的网络是良好的；万一不是良好，一方面超出了我们的控制范畴，另一方面，客户端接口由于到代理机之间调用路径非常短，有错误即刻就实现返回，没有等待。

[0048] 第三、可靠消息队列暂时存放到代理服务器上，在网络通畅时再发送；客户机与代理服务器之间调用路径可以非常短，客户机只管往代理服务器的队列存放本站交易数据。

[0049] 如图4所示，交易消息队列保证可靠，不丢失，不重传，在网络和服务正常情况下，基本保证实时。本站的退票、废票等流程均参照售票更新流程，也采取队列方式进行处理。异站票仍然必须调用同步方法进行交易，确保交易实时和事务性。

[0050] 如客户端使用tpcall()给本地或远程的服务器，其中由TUXEDO系统根据公告板信息确定，发送服务请求。左侧客户机通过tpenqueue()函数往队列里写了一条消息,然后接着做下面的工作；右侧客户机通过tpdequeue()函数接收消息,并进行处理。

[0051] 以下以本站售票更新服务流程为例，对本站票的售票结果调用中心提供的数据接口，将本次售本地票的结果传输到中心。运作原理图如图5所示：其中，数字标示先后执行顺序。

[0052] 1.客户端调用API数据接口，数据接口负责将传入的数据投入创建在前端代理服务器的本地数据队列中，投入成功后即刻返回。

[0053] 2.代理服务器对本地队列的数据进行处理，提交到中心和远程服务进行事务处理；处理完成后进行出队消除；出现错误将数据缓存到本地机器文件中，或者投入到本地的错误处理队列。

[0054] 其中，涉及前端代理服务设计和中心代理服务设计以及供站方使用的API接口设计，其中，前端代理指放置到本站的代理服务器，它是本地软件调用联网售票系统服务的第一道处理环节。流程逻辑如图6所示。

[0055] 在前端代理创建本地售票数据队列；结合接口软件，实现客户端售票数据的入队；根据配置实现队列数据的取出和处理；对队列不能取出的数据，重试若干次(根据配置)仍然失败后，将该数据转移到失效队列中，同时错误信息写入到错误队列；本地售票数据队列的处理与中心代理服务(数据库的操作)形成全局事务；队列溢出处理。

[0056] 输入项为：数据队列：每条队列消息包含一个售票数据结构，载入一条售票记录。创建队列容量基本依据：以一个工位一分钟售出5张票计算，则200个工位在两分钟内产生记录数目约为5X 200X 2＝2000条，在设计的时候，可以设计该队列的容量为2000。这种设计能解决短暂性的网络停顿(数分钟)问题。但是长时间的网络停顿将导致队列的溢出报错，转入售票本地缓存或者代理服务器缓存处理流程。

[0057] 输出项为：响应队列：存储对每条记录调用中心服务的处理结果。

[0058] 错误队列：存储中心服务处理失败的售票数据记录。

[0059] 算法或配置：队列的服务处理采用数据转发的方式，即将队列的数据通过消息中间件(以tuxedo为例)的TMQFORWORD服务转发到同名的service进行处理。错误数据存储到错误队列，返回信息存储到返回队列。需要配置多项服务，包括TMQUEUE与TMQFORWORD。

[0060] 中心代理服务指放置在票务中心的专用代理服务器，实现中心数据库事务处理，异站交易服务路由等核心业务。它位于中心数据库的前端。

[0061] 此处相应要创建与前端代理本地售票数据队列名同名的服务(service),通过事务中间件产品(以tuxedo为例)的服务TMQFORWORD，把数据转发到本服务进行处理。实际上服务基本不用改变，仅需保证服务命名与前端代理数据队列同名。

[0062] 功能:将转发过来的本地售票数据进行中心数据库入库处理。

[0063] 算法：由于多个队列的存在，导致中心的数据入库次序的一定偏差，需要调整处理逻辑，例如，在废票操作之前，应该有一条售票记录存在。但是目前可能出现，该售票记录可能还在售票队列中等待更新(排位靠后)，但是另外一个队列例如废票队列却因为比较短而先传输，造成废票记录先于售票记录到达中心数据库。这种情况在原设计在中心是作为错误进行处理的，因为中心会先查找有没有原售票记录，保证座位图状态的正确表示。

[0064] 修改后，在处理中心座位图变更时：

[0065] 当售票数据上来时，先查找中心的数据库，有没有特殊票记录(废、退、改乘、重打)在前。根据数据携带上来的当地时间与先前的特殊票时间进行比较，判别先后，如果发现售票数据在前，则不更新中心座位图；售票数据在后，则应该发生了数据逻辑错误或者丢失，应该作为错误处理。该票数据仍正常入库，座位图仍然更新，返回仍作为成功，但记录到错误日志表中去。没有发现有特殊票的，正常入库，更新座位图。

[0066] 供站方使用的API接口设计的封装形式：动态链接库。功能:根据输入判别是本站票还是异站票，自动走不同的数据处理流程。本节叙述本地票流程。流程逻辑如图7所示。

[0067] 把本地票售票数据进行入队处理，队列存放在前端代理；由于队列溢出或者服务异常，包括网络异常，导致入队失败，把数据存储到本地(终端)的数据文件中，恢复正常后继续入队处理。另外，强化异站交易涉及的废、退、重打、改乘接口的要求，加强判错。

[0068] 算法：有两种设计方式：直接在客户端使用tpenqueue()，将数据入队到前端代理服务器的售票数据队列中；客户端依然调用tpcall(),调用前端代理服务器的一个服务(service)，由该服务内部将该消息数据进行本地入队处理。本系统采用方式2。

[0069] 错误处理：

[0070] 以上两种设计方式都要对入队失败的错误进行本地缓存和处理。其中第2种方式，可以将入队失败的信息存储到本地(即代理服务器中)的数据库(例如SQL SERVER)。

[0071] 对于缓存文件中的数据，或者如上述保存在代理服务器SQL数据库中的销售数据，在恢复网络畅通或者服务正常后需要重传，考虑到代理服务器开辟的队列空间有限，在长时间断网情况下恢复上传的本地缓存数据会形成浪涌，可能会导致溢出，因此对此类数据仍然使用旧有数据接口的方式传输，即不使用队列的方式上传。

[0072] 本发明窄带网路结构下的区域客运联网售票可靠交易系统，通过将本站售票流程仅在本地处理，数据不再经过中心，节约时间和避免数据延误；而跨站售票中，将锁票终点扩展到异地服务器端，实现两个流程终点一致；并且采用消息队列技术机制实现交易数据的可靠传输，完成票务交易事务的处理，保证系统的高可用性与高安全性。

[0073] 本系统设计的任务并不局限一个汽车票销售系统，而是完成一个票务系统的技术模型，仅需简易修改即可移植到其他的相似平台。并且比传统的票务系统提供更高的可用性、可扩展性、可移植性。本系统将不同业务逻辑近乎完全隔离。已达到不同平台的扩展的目的。

[0074] 以上所述仅为本发明的较佳实施方式，本发明并不局限于上述实施方式，在实施过程中可能存在局部微小的结构改动，如果对本发明的各种改动或变型不脱离本发明的精神和范围，且属于本发明的权利要求和等同技术范围之内，则本发明也意图包含这些改动和变型。