票价搜索系统设计

-精选财经经济类资料- -最新财经经济资料-感谢阅读- 1 票价搜索系统设计 摘要：随着互联网的普及，以及 航空机票电子化的全面推行，人们更倾 向于在网上预订机票和选择旅游产品。 目前，能够提供强大票价搜索引擎的公 司基本上是外国的航空公司票价搜索提 供商，他们不为航空公司提供本地票价 搜索引擎，而是要求各航空公司，通过 互联网或专线，先把所有的票价发布到 票价提供商的主机上，然后才能进行票 价搜索，并且按查询次数向航空公司收 取费用，这种做法非常不利于各航空公 司建立自己的本地票价库，从而无法进 行相应的数据分析。因此，国内各航空 公司想要发展，提高销售额，必须拥有 自己的票价搜索系统。现阶段，开发一 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 2 个适合国内航空公司的本地票价搜索引 擎势在必行，这样才能帮助航空公司打 造一流的网上销售平台，保障网上销售 渠道的畅通，提升竞争力。 中国论文网 /8/view-12911302.htm 关键词：票价搜索；引擎； ATPCO 规则 中图分类号：TP311 文献标识码： A 文章编号： 1009-3044（2016）29- 0260-03 1 项目背景 随着互联网的普及、航空机票电 子化的全面推行，人们出行不再需要亲 自到机票销售点去预订机票，而是选择 使用计算机或者手机通过互联网，进入 航空公司或者其他销售机票的网站上预 订机票。 近年来，各航空公司除了提供网 上订票、出票及网上值机的服务外，还 提供了诸如酒店住宿、租车等旅行产品 服务，且这些产品的销售量逐年增高。 随着航空公司网络销售业务的高速发展， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 3 其票价搜索的速度严重制约了机票及其 相关旅游产品的销售业绩。因此，对于 航空公司来讲，拥有强大的票价搜索引 擎，提供丰富多样的旅行产品已经成为 航空公司迫在眉睫的问题所在。 目前，能够提供强大票价搜索引 擎的公司有：ATPCO（Air-line Tariff Publishing Company） 、SITA（Societe International DeTelecommun-ications） 、 TRAVELPORT 等公司，国内除南航引 进 SITA 第一代搜索引擎以外尚无其他 航空公司拥有自己的搜索引擎，只有少 数公司通过合作方式接入 SITA AIRFARE 进行运价计算和查询。因此， 拥有自己强大的票价搜索引擎是提高销 售业务，进而提高其核心竞争力的关键 所在。 纵观全球，许多国外航空公司票 价搜索提供商并不为航空公司提供本地 票价搜索引擎，所有的查询都必须经过 互联网或专线，首先将所有票价发布到 票价提供商的主机上，然后才能进行票 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 4 价搜索，查询按次数来收费，这样不仅 增加了航空公司销售的成本，且非常不 利于各航空公司建立自己的本地票价库， 从而无法对竞争对手和市场进行票价数 据分析。 国内有航空公司引进的第一代票 价搜索引擎，能够进行单程、往返、缺 口程以及中转联程和 ADDON 的基本票 价搜索，但由于技术上的限制，该搜索 引擎不是按照 ATPCO（Airline Tariff Publishing Company）国际运价规则标 准开发的，因此不能完全支持 ATPC01- 50 项的规则，即不能进行完全意义上的 票价搜索，同时也不能M 足各航空公 司日益增长的网上销售量和查询量。 鉴于以上原因，开发一个适合国 内航空公司的本地票价搜索引擎势在必 行。只有拥有自主知识产权的票价搜索 引擎，建立航空公司自身完整的本地票 价数据库，才能帮助航空公司打造一流 的网上销售平台，保障网上销售渠道的 畅通，提升竞争力，使之能跻身于世界 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 5 一流的航空公司之列。 2 系统总体结构 为了提供一个能支持 ATPCO 行 业标准的搜索引擎算法，系统采用负荷 平衡策略支持多个用户同时在线搜索， 并根据用户所提供的搜索字段对数据库 中保存的所有票价信息进行搜索，并尽 可能在短时间内将搜索结果返回给用户。 此外，为了能够适应 ATPCO 每 年修订的新标准，本系统还应具有良好 的可扩展性。 本系统的结构如图： 系统原理：终端用户提交的搜索 请求经由负载均衡调度机到达各个从数 据库服务器进行处理。在这些从数据库 服务器上部署搜索引擎的业务逻辑，通 过 Oracle TimesTen In-memoryDatabase 所提供的备份、热交换及数据恢复等功 能，实现从数据服务器之间的相互冗余 备份。另外，Oracle TimesTen In- memory Database 还能提供数据复制功 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 6 能，主数据库可以实时地对各个从数据 库进行数据的更新，以保持数据的同步 和一致性。 3 系统主要功能及函数设置 本系统的功能包括：舱位信息的 输入和修改，客机信息的输入、修改和 查询，航线信息的输入、修改和查询， 订票信息的输入、查询和修改等。 用户登录该系统后，可以通过查 询，选择机票或其他旅游产品，下单并 完成支付，系统根据支付记录给用户指 定的手机号码发送电子凭证，用户可根 据电子凭证到相应的服务点领取所定制 的产品服务。 本系统设置的票价搜索引擎函数 及函数的功能包括： 1）getMatching 函数 功能：返回符合搜索条件的一系 列票价。 输入：起飞地、目的地、起飞日 期、航程类型（S 、R） 、 CUG、成人数、 儿童数、婴儿数 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 7 在这个 getMatching 函数中还需 注意设置以下参数： a.如果儿童数大于 0，则票价必 须含有儿童票价才会返回。婴儿数同理。 其它函数同样适用。 b.如果成人数是 0，返回的票价 不按成人票价从小到大排序。如果成人 数是 0，儿童数是 1，返回的票价按儿 童票价从小到大排序。 c.如果标签是 T，此票价不能使 用于订票。系统默认是不返回标签是 T 的票价，如果在请求时加上 A 时，则会 返回这种票价。 d.要使用某一票价，必须从返回 结果匹配其使用条件。 2）getSelectedFare 函数 功能：返回符合条件的唯一票价，适合 用于做票价确认。 输入：fare reference（一般由前 一次查询产生） ，与 getinfo 相同。 3）fares For Availability 函数 功能：返回符合搜索条件的所有 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 8 票价。 输入：起飞地、目的地、起飞日 期、航程类型（S 、R） 、 CUG、成人数、 儿童数、婴儿数、舱位、航班号、缺口 程需加上返程起飞地、返程目的地。 fares For Availability 函数中需要 特别留意的地方有以下三点： a.查询往返程、缺口程票价时， 舱位必须前后一致。 b.当查询往返程票价时，返回的 是往返程的合计票价，而 getFaresForItinerary 函数分别返回每个 航段的票价（单程、半往返程） 。 c.请求时 F 返回适合条件的最后 录入（fare number 最大）的票价，T 或 缺省此标签时，返回所有票价。如果要 查询多个舱位的最低票价，请用 T，取 其最前面的匹配票价。 4）getInfo 函数 功能：返回额外的票价信息，如 使用条件、提供的特殊服务等。 输入：fare reference（一般由前 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 9 一次查询产生） ，与 getSelect-edFare 所 得的结果相同。 5）getFaresForItinerary 函数 功能：返回复杂航线的各个航段 单程和（或）半往返程票价（同时存在 out 和 in 航段请求时才返回半往返程票 价） 。 输入：与 faresForAvailability 类 似。 使用 getFaresForItinerary 函数时， 须特别留意以下几点： a.各航段可以是不同舱位的组合。 b.可组合一个 Addon、Main fare、一个 Onwards 航段（加上返程） 。 c.同一方向的 Main fare 可以是一 个航段、有多个经停点的航段，但不允 许是二个或以上独立航段，否则会显示 没有票价返回。 d.如果第一个请求航段不是 Addon，且与第二个同向的航段没有经 停票价，将没有票价返回。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 10 e.经停点可以像 faresForAvailability 一样用格式，也可 以作为二同向的航段输入。 4 本系统采用的关键技术 衡量一个票价搜索引擎系统性能 的标准是：能否提供丰富多彩的产品服 务，能否在查询订单之后快速响应。为 了达到这两个目标，本系统采用了以下 关键技术来保证系统性能。 1）Oracle TimesTen In-memory Database 通过采用高性能的内存数据库， 使系统在查询票价时可以达到最快捷的 响应速度，由于这些票价数据都是存放 于数据库服务器的内存中，而且业务逻 辑也部署于同一台服务器（引擎服务器） 上，因此能够最大限度地减少网络带宽 所带来的性能影响以及提供系统的稳定 性。另外，系统可同时部署若干引擎服 务器，为保证数据的一致性，采用主从 结构的形式，由主数据库实时地将所有 的数据变化同步到从内存数据库中，这 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 11 样，即使其中某些节点出现问题，也不 会影响整个系统的正常工作。 2）基于 IP 和基于内容请求分发 的负载平衡调度 系统前端配置一个前置调度机， 从网络传送过来的搜索请求数据会经由 此前置机被分发到各个引擎服务器上。 系统将来自不同 IP 的请求采用 如哈希算法计算出一组目标引擎服务器， 然后将来自这些 IP 地址的请求转发到 该组服务器上。确定服务器的范围以后， 请求的内容也经过一定的算法分析，然 后计算出某特定的目标服务器，最后将 该请求发送到相应的服务器上。这样做 的目的是使某特定的引擎服务器可以专 门负责某类型的搜索请求，从而可以极 大地提高搜索速度。数据库系统的特点 决定了近似的搜索能得到更快的响应速 度。 由于这些引擎服务器上都部署有 相同的业务逻辑，所以理论上这些服务 器能实现的搜索功能都是一致的。于是， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 12 如果某一时间某类型的请求过多，而处 理该类请求的服务器负荷较重，则可以 将其他较为空闲的服务器配置为可处理 该类请求。 3）其他提高搜索速度的方法 一般情况下，从数据库中搜索得 到的票价信息并不是用户所要求的信息， 还需要对其作进一步的过滤。这部分的 过滤功能可以通过自行实现相应的算法 去查找和计算这些中间结果集，得到最 终的结果并返回给用户，或者根据这些 计算结果再次对数据库进行查找，从而 得到更准确的结果集。这部分算法的实 现应与业务需求紧密联系。 4）使用 Search Oriented Architecture 面向搜索的架构 面向搜索引擎的架构设计主要在 业务层和数据层之间添加一个搜索层， 该层的作用在于将业务系统和数据库系 统的关联性减到最小，从而大大提高系 统的可扩展性。从工作流程的角度上看， 业务层首先向搜索层提出搜索的请求， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 13 数据搜索的任务是在搜索层里完成。由 于将搜索功能单独提取出来作为一层， 搜索的数据对象将不仅限于数据库系统 中存放的数据，还可以是网页，文件系 统中存放的文件等等。在本系统里面， 可以先实现对数据库的搜索功能。 5）使用 Service Oriented Architecture 面向服务的架构 面向服务的架构主要是对现有的 代码重用想法的改进。现有的代码重用 通常基于针对某特定功能实现的函数或 基于面向对象技术的类的重用。这些方 法的缺点是功能过于分散和微小，即使 重用代码也需要花非常多时间实现新的 业务应用和进行测试。面向服务的架构 设计方法的原则是尽量低持械母鞲 龉 埽话阄 系统提供的各种服务） 最大限度地分割开来，从而减少针对这 部分功能所需设计的功能接口。每个服 务或功能点间需要确定一组通信的协议， 并且相互关联程度尽量减到最低。最理 想的情况下各服务之间只需要知道其他 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 14 服务是否存在并正常运行。这种架构可 以降低各个服务或功能点之间的耦合程 度，提高代码重用效率，也大大加快了 扩展业务功能的速度，因为在许多情况 下系统工程师只需要将系统现有的服务 重新组合就可以实现新的业务功能。 对本系统来说，票价搜索是系统 的核心功能，在将来可能的应用中，票 价的搜索可能会被用于网上购票系统， 机场信息部门查询系统，业务分析系统， 客户关系管理系统等等，于是在设计的 初步阶段将票价搜索实现成一个面向服 务的