CN114519440A - 一种客票的数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供的一种客票的数据处理方法、装置、设备及存储介质，所述方法包括第一电子设备接收用户端发送的客票提交指令；根据客票提交指令的类型，确定客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息；接收第二电子设备发送的客票校验信息；根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。这样一来，第一电子设备只需执行业务逻辑，数据库也只需存储数据，通过第二电子设备可以完成第一电子设备与数据库之间的交互，从而可以实现业务逻辑与数据存储的解耦，提高数据处理的效率。

Description

一种客票的数据处理方法、装置、设备及存储介质

技术领域

本申请涉及电子信息技术领域，具体地涉及一种客票的数据处理方法、装置、设备及存储介质。

背景技术

随着移动设备、智能终端等网络和通信技术在客票系统中的广泛应用，客票系统中开发的功能越来越多，旅客数据的种类和规模也正在以前所未有的速度增长，客票系统进入大数据时代。

现有技术中，客票系统的核心业务逻辑，即客票系统中各核心业务功能的实现过程，与数据存储过程都在一个数据库中完成，例如，客票系统根据旅客提供的订票信息校验客票信息、出票的业务逻辑的实现与存储该用户的订单信息的数据都在一个数据库中完成。基于此，客票系统已形成了完备的技术架构和业务组织模式。由于现有客票系统中的业务逻辑数据与数据存储都在同一个数据库中，两者之间存在耦合关系，当进行新业务开发时，除了考虑新业务逻辑的实现方法，还需要考虑与之相关联的数据在数据库中存储的位置，因此会使得新业务开发周期较长，也不利于开发代码的调试。并且业务逻辑数据与数据存储的数据量庞大，都存储在同一个数据库中可能会导致数据库负载过高，数据处理的耗时也比较长，降低了工作效率。

发明内容

有鉴于此，本申请提供一种客票的数据处理方法、装置、设备及存储介质，以利于解决现有技术中数据库负载高，工作效率低的问题。

第一方面，本申请实施例提供了一种客票的数据处理方法，所述方法包括：

第一电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息及用户的客票相关信息；

根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型，以使得所述第二电子设备根据所述用户标识信息及所述客票提交指令对应的数据库类型确定出所述用户端对应的目标数据库，将所述客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息；

接收所述第二电子设备发送的客票校验信息；

根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

优选地，所述方法还包括：

所述客票提交指令的类型包括客票购买类型、客票退改签类型；

所述根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型包括：

在所述客票提交指令的类型包括客票购买类型时，确定所述客票提交指令对应的数据库类型为购票类型；

在所述客票提交指令的类型包括客票退改签类型时，确定所述客票提交指令对应的数据库类型为退改签类型。

第二方面，本申请实施例提供了另一种客票的数据处理方法，所述方法包括：

第二电子设备接收第一电子设备发送的客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型；

根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库；

将所述客票校验信息获取请求消息发送至目标数据库；

接收所述目标数据发送的客票校验信息；

将所述客票校验信息发送至所述第一电子设备。

优选地，所述将所述客票校验信息获取请求消息发送至目标数据库包括：

根据所述目标数据的数据格式，将所述客票校验信息获取请求消息的数据格式转换为所述目标数据库的数据格式，并发送至所述目标数据库。

优选地，所述将所述客票校验信息发送至所述第一电子设备包括：

将所述客票校验信息的数据格式转换为所述第一电子设备的数据格式，并发送至所述第一电子设备。

优选地，所述方法还包括：

检测已建立连接的数据库中是否有故障数据库；

所述根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库包括：

根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的，且没有故障的数据库中确定目标数据库。

优选地，所述方法还包括：

接收新增数据库的连接建立请求消息，所述连接建立请求消息中携带有所述新增数据库的数据格式；

与所述新增数据库建立连接，并保存所述新增数据库的数据格式。

第三方面，本申请实施例提供了另一种客票的数据处理方法，所述方法包括：

第三电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息；

根据所述客票提交指令的类型及所述用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库；

向所述目标数据库发送客票校验信息获取请求消息；

接收所述目标数据库发送的客票校验信息；

根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

第四方面，本申请实施例提供了一种客票的数据处理装置，包括：

接收单元，用于第一电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息及用户的客票相关信息；还用于接收所述第二电子设备发送的客票校验信息；

获取单元，用于根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型，以使得所述第二电子设备根据所述用户标识信息及所述客票提交指令对应的数据库类型确定出所述用户端对应的目标数据库，将所述客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息；

处理单元，用于根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

第五方面，本申请实施例提供了一种客票的数据处理装置，包括：

接收单元，用于第二电子设备接收第一电子设备发送的客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型；

处理单元，用于根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库；还用于将所述客票校验信息获取请求消息发送至目标数据库；

接收单元还用于接收所述目标数据发送的客票校验信息；

处理单元还用于将所述客票校验信息发送至所述第一电子设备。

第六方面，本申请实施例提供了一种客票的数据处理装置，包括：

接收单元，用于第三电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息；

处理单元，用于根据所述客票提交指令的类型及所述用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库；

获取单元，用于向所述目标数据库发送客票校验信息获取请求消息；

接收单元还用于，接收所述目标数据库发送的客票校验信息；

处理单元还用于，根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

第七方面，本申请实施例提供了一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序，当所述计算机程序被执行时，使得所述电子设备执行权利要求上述第一方面中任意一项或第二方面中任意一项或第三方面中任意一项所述的方法。

第八方面，本申请实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述第一方面中任意一项或第二方面中任意一项或第三方面中任意一项所述的方法。

采用本申请实施例所提供的方案，第一电子设备接收用户端发送的客票提交指令，并由第一电子设备执行业务逻辑，例如校验客票提交指令中包含的客票相关信息，即，客票的车次信息，乘客信息，时刻表信息等数据信息。当第一电子设备校验用户端提交的客票信息时需要获取数据库中存储的客票校验信息，此时第一电子设备无需获知客票校验信息在数据库中的具体存储位置，只需向第二电子设备发送客票校验信息获取请求消息，从而使得第二电子设备根据客票校验信息获取请求消息确定与用户端对应的目标数据库，从而获取在目标数据库中存储的客票校验信息。第一电子设备接收第二电子设备发送的客票校验信息，以完成对用户端提交的客票信息的校验，并在校验通过时，生成订单信息，向用户端返回订单信息。也就是说，当第一电子设备执行业务逻辑的过程中需要与用户端对应的目标数据库进行交互时，第一电子设备无需确定用户端对应的目标数据库的具体位置，也无需确定执行业务逻辑所需的目标数据在用户端对应的目标数据库中的具体位置，而是通过向第二电子设备发送具体的业务请求消息，可以使得第二电子设备根据具体的业务请求消息确定出用户端对应的目标数据库，进而根据具体的业务请求消息从目标数据库中获取对应的目标数据。根据上述客票的数据处理方法，第一电子设备只需执行业务逻辑，数据库也只需存储数据，同时第一电子设备通过第二电子设备可以完成与数据库之间的交互，从而可以实现业务逻辑与数据存储的解耦，提高数据处理的效率。并且，当进行新业务开发时，也只需考虑新业务逻辑的实现方法，无需考虑与之相关联的数据在数据库中存储的位置，降低了新业务开发的难度。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种客票的数据处理方法的流程示意图；

图2为本申请实施例提供的另一种客票的数据处理方法的流程示意图；

图3为本申请实施例提供的另一种客票的数据处理方法的流程示意图；

图4为本申请实施例提供的另一种客票的数据处理方法的流程示意图；

图5为本申请实施例提供的一种客票的数据处理装置的结构示意图；

图6为本申请实施例提供的另一种客票的数据处理装置的结构示意图；

图7为本申请实施例提供的另一种客票的数据处理装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。

应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

在对本申请实施例进行具体介绍之前，首先对本申请实施例应用或可能应用的术语进行解释。

SQL语句：SQL(Structured Query Language)是一门字符代码(AmericanNational Standards Institute，ANSI)的标准计算机语言，用来访问和操作数据库系统。SQL语句用于取回和更新数据库中的数据，SQL可与数据库程序协同工作。

JSON数据格式：JSON(Java Script Object Notation)是一种轻量级的数据交换格式。它采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得JSON成为理想的数据交换语言。易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

数据库：数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。

Sybase数据库：美国Sybase公司研制的一种关系型数据库系统，是一种典型的UNIX操作系统或WindowsNT操作系统平台上客户机/服务器环境下的大型数据库系统。Sybase提供了一套应用程序编程接口和库，可以与非Sybase数据源及服务器集成，允许在多个数据库之间复制数据，适于创建多层应用。系统具有完备的触发器、存储过程、规则以及完整性定义，支持优化查询，具有较好的数据安全性。

PostgreSQL数据库：PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统，是一种对象关系型数据库管理系统。PostgreSQL支持大部分的SQL标准并且提供了很多其他现代特性，如复杂查询、外键、触发器、视图、事务完整性、多版本并发控制等。同样，PostgreSQL也可以用许多方法扩展，例如通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言等。

相关技术中，客票系统的核心业务逻辑，即客票系统中各核心业务功能的实现过程，与数据存储过程都在一个数据库中完成，例如，客票系统根据旅客提供的订票信息校验客票信息、出票的业务逻辑的实现与存储该用户的订单信息的数据都在一个数据库中完成。基于此，客票系统已形成了完备的技术架构和业务组织模式。由于现有客票系统中的业务逻辑数据与数据存储都在同一个数据库中，两者之间存在耦合关系，当进行新业务开发时，除了考虑新业务逻辑的实现方法，还需要考虑与之相关联的数据在数据库中存储的位置，因此会使得新业务开发周期较长，也不利于开发代码的调试。并且业务逻辑数据与数据存储的数据量庞大，都存储在同一个数据库中可能会导致数据库负载过高，数据处理的耗时也比较长，降低了工作效率。

针对上述问题，本申请实施例提供了一种客票的数据处理方法，所述方法包括，第一电子设备接收用户端发送的客票提交指令，并由第一电子设备执行业务逻辑，例如校验客票提交指令中包含的客票相关信息，即，客票的车次信息，乘客信息，时刻表信息等数据信息。当第一电子设备校验用户端提交的客票信息时需要获取数据库中存储的客票校验信息，此时第一电子设备无需获知客票校验信息在数据库中的具体存储位置，只需向第二电子设备发送客票校验信息获取请求消息，从而使得第二电子设备根据客票校验信息获取请求消息确定与用户端对应的目标数据库，从而获取在目标数据库中存储的客票校验信息。第一电子设备接收第二电子设备发送的客票校验信息，以完成对用户端提交的客票信息的校验，并在校验通过时，生成订单信息，向用户端返回订单信息。也就是说，当第一电子设备执行业务逻辑的过程中需要与用户端对应的目标数据库进行交互时，第一电子设备无需确定用户端对应的目标数据库的具体位置，也无需确定执行业务逻辑所需的目标数据在用户端对应的目标数据库中的具体位置，而是通过向第二电子设备发送具体的业务请求消息，可以使得第二电子设备根据具体的业务请求消息确定出用户端对应的目标数据库，进而根据具体的业务请求消息从目标数据库中获取相应的目标数据。根据上述客票的数据处理方法，第一电子设备只需执行业务逻辑，数据库也只需存储数据，通过第二电子设备可以完成第一电子设备与数据库之间的交互，从而可以实现业务逻辑与数据存储的解耦，提高数据处理的效率，同时也有利于后续新业务开发。以下进行详细说明。

图1为本申请实施例提供的一种客票的数据处理方法的流程示意图。参见图1，所述客票的数据处理方法主要包括以下几个步骤：

步骤S101、第一电子设备接收用户端发送的客票提交指令。

其中，客票提交指令中包含有用户标识信息及用户的客票相关信息。

具体的，用户端在需要进行购买客票或者退改签客票时，可以向第一电子设备发送客票提交指令。第一电子设备接收用户端发送的客票提交指令。客票提交指令包含有用户标识信息及用户的客票相关信息，其中，用户标识信息可以包括用户的用户名信息，用户身份标识信息等。用户的客票相关信息至少包括客票的车次信息、乘客信息、时刻表信息。

步骤S102、根据客票提交指令的类型，确定客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息。

其中，客票校验信息获取请求消息中包含有用户标识信息及客票提交指令对应的数据库类型，以使得第二电子设备根据用户标识信息及客票提交指令对应的数据库类型确定出用户端对应的目标数据库，将客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息。也就是说，第一电子设备只需向第二电子设备发送客票校验信息获取请求消息，由第二电子设备确定出用户端对应的目标数据库，并从用户端对应的目标数据库中获取客票校验信息，再发送至第一电子设备。

在本申请实施例中，在第一电子设备接收到用户发送的客票提交指令之后，需要校验客票信息是否符合要求，例如，需校验客票车次的始发站和到达站的车站是否开放、乘客是否已订购其它与当前车次时间冲突的客票等信息，只有在校验通过时，才能生成相应的客票订单。因此，第一电子设备需要从与该客票提交指令相对应的数据库中获取客票校验信息以完成校验。其中，客票校验信息至少包括客票的车次信息，乘客信息，时刻表信息。

这样一来，第一电子设备可以先根据客票提交指令的类型，确定客票提交指令对应的数据库类型，并向第二电子设备发送客票校验信息获取请求消息，以获取客票校验信息。其中，客票提交指令的类型包括客票购买类型、客票退改签类型。

根据客票提交指令的类型，确定客票提交指令对应的数据库类型包括：

在客票提交指令的类型包括客票购买类型时，确定客票提交指令对应的数据库类型为购票类型；

在客票提交指令的类型包括客票退改签类型时，确定客票提交指令对应的数据库类型为退改签类型。

具体的，用户提交客票信息时，提交的可能是新的客票购买信息，也可能是对已购买的客票订单进行退改签操作产生的客票退改签信息。通常情况下，由于客票系统中需存储的数据量庞大，为减轻数据库的负载压力，存储客票购买信息的数据库与存储客票退改签信息的数据库不同。因此客票提交指令的类型可以是客票购买类型或客票退改签类型，那么根据客票提交指令的类型可以确定其对应的数据库类型为购票类型或退改签类型。

步骤S103、接收第二电子设备发送的客票校验信息。

其中，在第一电子设备向第二电子设备发送客票校验信息获取请求消息后，使得第二电子设备可以根据接收的客票校验信息确定出用户端对应的目标数据库，将客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息。因此，第一电子设备接收第二电子设备发送的客票校验信息。

步骤S104、根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。

具体的，第一电子设备接收的用户端发送的客票提交指令中包含用户的客票相关信息，即，客票的车次信息、乘客信息、时间表信息等信息。并且第一电子设备接收的第二电子设备发送的客票校验信息也至少包括客票的车次信息，乘客信息，时刻表信息，因此第一电子设备可以根据接收到第二电子设备发送的客票校验信息可以验证客票提交指令是否通过。例如，根据客票的车次信息、时刻表信息校验当前车次及时间是否正确、校验客票车次的始发站和到达站的车站是否开放、校验乘客信息是否正确、乘客是否已订购其它与当前车次时间冲突的客票等。并在验证通过时，生成订单信息。

作为一种可能的实现方式，订单信息根据用户端提交的客票提交指令的种类不同而不同。即为，订单信息可以分为购票订单信息、改签订单信息及退票订单信息。当用户提交的客票提交指令的类型为客票购买类型时，则此时生成的订单信息为购票订单信息。当用户提交的客票提交指令的类型为客票退票类型时，则此时生成的订单信息为退票订单信息。当用户提交的客票提交指令的类型为客票改签类型时，则此时生成的订单信息为改签订单信息。

购票订单信息包括已购买的车次信息、座次信息、乘客信息、发车时间、到站时间，以及购票成功等信息。改签订单信息包括改签之后的车次信息、座次信息、乘客信息、发车时间、到站时间，以及改签成功等信息。退票订单信息包括已退票的车次信息、座次信息、乘客信息、发车时间、到站时间，以及退票成功等信息。在生成订单信息后向用户端返回订单信息。

以上所述为一种可能的实施例，当用户提交客票信息时，第一电子设备接收用户端发送的客票提交指令，向第二电子设备发送客票校验信息获取请求消息，从而通过第二电子设备获取到客票校验信息，以完成对用户端发送的客票提交指令中包含的用户的客票相关信息的校验。在校验通过后，生成订单信息，并返回至用户端。这样一来，第一电子设备在执行业务逻辑时，可以通过第二电子设备实现与相关数据库之间的交互，而无需考虑所需数据信息在相关数据库中的位置，提高数据处理的效率。

图2为本申请实施例提供的另一种客票的数据处理的方法。参见图2，具体包括以下步骤：

步骤S201、第二电子设备接收第一电子设备发送的客票校验信息获取请求消息。

其中，客票校验信息获取请求消息中包含有用户标识信息及客票提交指令对应的数据库类型。

具体的，由于当第一电子设备需要校验用户端发送的客票提交指令时，会向第二电子设备发送客票校验信息获取请求消息，此时，第二电子设备接收第一电子设备发送的客票校验信息获取请求消息。

步骤S202、根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库。

在本申请实施例中，客票校验信息获取请求消息中包含有用户标识信息及客票提交指令对应的数据库类型。即，客票校验信息获取请求消息中包含用户名信息，客票提交指令对应的数据库类型是购票类型或者退改签类型。

具体的，由于在访问数据库时，需要与数据库建立连接，并且在每一次访问结束后，数据库的连接都会断开，再次访问该数据库时需要重新建立连接，这会增加数据处理的耗时。因此，在用户启动客票服务时，为提高数据处理的效率，第二电子设备与多路存储客票数据信息的数据库建立连接并保持各连接，那么在访问相关数据库时，无需进行多次连接，可直接进行访问，从而节省与数据库建立连接的时间。

在本申请实施例中，由于有多个存储客票信息的数据库，第二电子设备根据用户标识信息可以为所有用户分配数据库，以使得多路数据库负载均衡。为进一步减轻数据库负载，每一路数据库都包含购票类型数据库与退改签类型数据库，并且，购票类型数据库中的数据信息会同步至同一路数据库中的退改签类型数据库，以便在对已购客票订单进行退改签时，对应的退改签类型数据库中存储有该已购客票订单的客票信息，可以直接在对应的退改签类型数据库中进行相应的操作。那么，当第二电子设备接收第一电子设备发送的客票校验信息获取请求消息后，可以根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库。

示例性的，假设总共有20路数据库用来存储客票数据信息，每一路数据库中都分为购票类型数据库与退改签类型数据库，并且第二电子设备可以设置所有用户的用户名根据特定算法计算的结果都在1-400的范围内，其中计算结果为1-20的用户对应的数据库为第1路数据库，计算结果为21-40的用户对应的数据库为第2路数据库，以此类推，计算结果为381-400的用户对应的数据库为第20路数据库，这样一来，可以使得每一路数据库负载均衡。假设第二电子设备与20路数据库都建立了连接，第二电子设备接收第一电子设备发送的客票校验信息获取请求消息，该客票校验信息获取请求消息中包含某用户的用户名A，客票提交指令对应的数据库类型为购票类型。此时，第二电子设备根据用户名A利用特定算法计算出的结果为10，那么可以确定该用户对应的数据库为第1路数据库，并且由于客票提交指令对应的数据库类型为购票类型，那么第二电子设备将第一路数据库中的购票类型数据库确定为目标数据库。

需要说明的是，上述特定算法可以是哈希算法，也可以是其他算法，本申请对此不作限制。

步骤S203、将客票校验信息获取请求消息发送至目标数据库。

具体的，第二电子设备确定目标数据库之后，可以将客票校验信息获取请求消息发送至目标数据库。

进一步地，将客票校验信息获取请求消息发送至目标数据库包括：

根据目标数据的数据格式，将客票校验信息获取请求消息的数据格式转换为目标数据库的数据格式，并发送至目标数据库。

具体的，由于目标数据库可以为不同类型的数据库，例如Sybase数据库、PostgreSQL数据库，每个数据库都有与其对应的数据格式，当访问数据库时，需要将客票校验信息获取请求消息的数据格式转换为目标数据库的数据格式，并发送至目标数据库。

作为一种可能的实现方式，在第二电子设备中，预先设置了访问不同数据库对应的SQL语句，第二电子设备可以根据目标数据库对应的数据格式采用目标数据库对应的SQL语句，将客票校验信息获取请求消息发送至目标数据库。

其中，SQL语句是一种字符代码的标准计算机语言，用来访问和操作数据库系统。

步骤S204、接收目标数据库发送的客票校验信息。

在本申请实施例中，目标数据库接收到客票校验信息获取请求消息后，可以根据该客票校验信息获取请求消息确定需要获取的客票校验信息，并在目标数据库中获取相应的客票校验信息，将客票校验信息发送至第二电子设备。第二电子设备接收目标数据库发送的客票校验信息。

步骤S205、将客票校验信息发送至第一电子设备。

具体的，由于在第一电子设备进行客票信息的校验，也就是说，在第一电子设备执行客票的业务逻辑操作，因此，第二电子设备在接收到客票校验信息之后，可以将客票校验信息发送至第一电子设备。

进一步地，将客票校验信息发送至第一电子设备包括：将客票校验信息的数据格式转换为第一电子设备的数据格式，并发送至第一电子设备。

具体的，为了方便数据的解析与传输，第一电子设备的数据格式为一种计算机通用的数据格式，例如，JSON数据格式。因此，为了方便第一电子设备对客票校验信息的数据进行解析，第二电子设备可以先将客票校验信息的数据格式转换为第一电子设备的数据格式，并发送至第一电子设备。

作为一种可能的实施例，图3为本申请实施例提供的另一种客票的数据处理方法的流程示意图。参见图3，具体步骤如下：

步骤S301、第一电子设备接收用户端发送的客票提交指令。

具体的可参考上述步骤S101，在此不再赘述。

步骤S302、第一电子设备根据客票提交指令的类型，确定客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息。第二电子设备接收第一电子设备发送的客票校验信息获取请求消息。

具体的可参考上述步骤S102及步骤S201，在此不再赘述。

步骤S303、第二电子设备根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库。

具体的可参考上述步骤S202，在此不再赘述。

步骤S304、第二电子设备将客票校验信息获取请求消息发送至目标数据库；目标数据库接收客票校验信息获取请求消息。

目标数据库接收到客票校验信息获取请求消息后，可以根据该客票校验信息获取请求消息确定需要获取的客票校验信息，并在目标数据库中获取相应的客票校验信息。

具体的可参考上述步骤S203，在此不再赘述。

步骤S305、目标数据库向第二电子设备发送客票校验信息，第二电子设备接收目标数据库发送的客票校验信息。

具体的可参考上述步骤S204，在此不再赘述。

步骤S306、第二电子设备将客票校验信息发送至第一电子设备。第一电子设备接收第二电子设备发送的客票校验信息。

具体的可参考上述步骤S205及步骤S103，在此不再赘述。

步骤S307、第一电子设备根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。

具体的可参考上述步骤S104，在此不再赘述。

步骤S308、第二电子设备可以检测已建立连接的数据库中是否有故障数据库，若检测到故障数据库，将该数据库标记为故障状态。

在本申请实施例中，由于第二电子设备在其已建立连接的数据库中确定出用户端对应的目标数据库，从而在该目标数据库中获取相应用户的客票校验信息。当数据库发生故障时，则无法及时的为第二电子设备反馈客票校验信息等，此时，第二电子设备需要在确定目标数据库时，在没有发生故障的数据库中确定。因此，为了保证第一电子设备快速的获取客票校验信息，第二电子设备可以实时检测其已建立连接的数据库是否发生故障，以防止将已经发生故障的数据库作为目标数据。

作为一种可能的实现方式，第二电子设备检测已建立连接的数据库是否发生故障可以通过统计在预设时间内访问数据库失败的次数。即为，若某个数据库在预设时间内访问失败的次数超过第一预设次数阈值，则可以确定该数据库发生故障，可以将该数据库标记为故障状态。例如，第二电子设备检测到在5min中内，访问某数据库失败的次数超过50次，则可以确定该数据库发生故障，此时第二电子设备将该数据库标记为故障状态。

需要说明的是，第二电子设备还可以通过其他方式检测其已建立连接的数据库是否发生故障，例如可以统计访问数据库时，连续访问失败的次数，若连续访问失败的次数超过第二预设次数阈值，则确定该数据库发生故障。当然，还可以是其他方式，本申请对此不作限制。

需要说明的是，第一预设次数阈值及第二预设次数阈值均是根据实际需求预先设置的。

此时上述步骤S303中根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库包括：

根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的，且没有故障的数据库中确定目标数据库。

具体的，当检测到故障数据库时，可以将该数据库标记为故障状态。由于故障的数据库无法及时的响应第一电子设备的请求消息，为了保证第一电子设备及时的获取到所需的客票校验信息，第二电子设备在根据用户标识信息及客票提交指令对应的数据库类型确定目标数据库时，可以在已建立连接的，且没有故障的数据库中确定目标数据库。也就是说，若某用户对应的原目标数据库发生故障，当该用户购买新的客票时，其用户端发送购票类型的客票提交指令，在第二电子设备接收第一电子设备发送的客票校验信息获取请求消息时，第二电子设备可以重新为该用户在已建立连接且没有发生故障的数据库中确定对应的目标数据库。

需要说明的是，第二电子设备可以在上述步骤S301-S307执行的过程中，同时检测已建立连接的数据库中是否有故障数据库，以便及时标记故障数据库。也就是说，步骤S308在上述步骤S301-S307执行的过程中，可以同时执行。

步骤S309、第二电子设备接收新增数据库的连接建立请求消息。

其中，连接建立请求消息中携带有新增数据库的数据格式。

在本申请实施例中，当客票业务请求激增时，为避免现有存储数据的数据库负载过高，客票系统可以根据业务请求的数量新增一定数量的数据库以应对高并发业务请求。当存在新增数据库时，第二电子设备需要与新增数据库建立连接。此时，第二电子设备接收新增数据库的连接建立请求消息。

步骤S310、第二电子设备与新增数据库建立连接，并保存新增数据库的数据格式。

具体的，第二电子设备接收新增数据库的连接建立请求消息之后，可以与新增数据库建立连接，并保存新增数据库的数据格式。由于新增数据库已与第二电子设备建立连接，此时第二电子设备已建立连接的数据库的数量增多。那么客票业务请求激增时，第二电子设备根据用户标识信息及客票提交指令对应的数据库类型确定目标数据库时就可以将新增数据库确定为目标数据库，以减轻原来已有的与第二电子设备建立连接的数据库的负载压力，使得各数据库负载均衡。

需要说明的是，步骤S309-S310为存在新增数据库时，第二电子设备与新增数据库建立连接的过程。也就是说，只有在出现新增数据库时，才会执行步骤S309-S310。

作为一种可能的实现方式，图4为本申请实施例提供的另一种客票的数据处理方法的流程示意图。具体步骤如下：

步骤S401、第三电子设备接收用户端发送的客票提交指令。

其中，客票提交指令中包含有用户标识信息。

具体的可参考上述步骤S101，在此不再赘述。

步骤S402、第三电子设备根据客票提交指令的类型及用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库。

在本申请实施例中，第三电子设备中集成了上述第二电子设备可实现的功能，因此第三电子设备可以根据客票提交指令的类型及用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库。

具体的可参考步骤S202，在此不再赘述。

步骤S403、第三电子设备向目标数据库发送客票校验信息获取请求消息，目标数据库接收客票校验信息获取请求消息。

具体的可参考步骤S203，在此不再赘述。

步骤S404、目标数据库根据客票校验信息获取请求消息获取客票校验信息，并发送至第三电子设备，第三电子设备接收目标数据库发送的客票校验信息。

在本申请实施例中，第三电子设备接收目标数据库发送的客票校验信息，并将客票校验信息的数据格式转换为通用的数据格式，即JSON数据格式。

具体的可参考步骤S204、步骤S205，在此不再赘述。

步骤S405、第三电子设备根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。

具体的可参考步骤S104，在此不再赘述。

示例性的，假设总共有20路数据库用来存储客票数据信息，每一路数据库中都分为购票类型数据库与退改签类型数据库，并且第二电子设备可以设置所有用户的用户名根据特定算法计算的结果都在1-400的范围内，其中计算结果为1-20的用户对应的数据库为第1路数据库，计算结果为21-40的用户对应的数据库为第2路数据库，以此类推，计算结果为381-400的用户对应的数据库为第20路数据库。假设第三电子设备接收用户端发送的客票提交指令，其中客票提交指令中包含该用户的用户名信息B，客票提交指令的类型为退改签类型，第三电子设备根据该用户的用户名信息B利用特定算法计算的结果为30，那么第三电子设备可以在已建立连接的数据库中确定用户端对应的目标数据库为第2路数据库。然后由于客票提交指令的类型为退改签类型，第三电子设备可以确定用户端对应的目标数据库为第2路数据库中的退改签类型数据库。第三电子设备向第2路数据库中的退改签类型数据库发送客票校验信息获取请求消息，以使得第2路数据库中的退改签类型数据库根据客票校验信息获取请求消息将对应的客票校验信息发送至第三电子设备。第三电子设备接收第2路数据库中的退改签类型数据库发送的客票校验信息。第三电子设备根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。

以上所述为一种可能的实施例，第三电子设备中可以集成上述第一电子设备与第二电子设备的功能，也就是说第三电子设备可以执行业务逻辑，也可以实现与数据库之间的交互，同时业务逻辑与数据库存储之间是解耦的。

这样一来，根据本申请实施例提供的客票的数据处理方法，可以实现客票系统中业务逻辑的执行与数据库存储之间的解耦，从而减轻数据库的负载压力，提高数据处理的效率。并且当进行新业务开发时，只需考虑业务逻辑代码的实现，无需考虑数据存储的位置，降低了新业务开发的难度。

与上述实施例相对应，如图5所示，本申请还提供了一种客票的数据处理装置，包括：

接收单元501，用于第一电子设备接收用户端发送的客票提交指令。其中，客票提交指令中包含有用户标识信息及用户的客票相关信息。

获取单元502，用于根据客票提交指令的类型，确定客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息。其中，客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型，以使得第二电子设备根据用户标识信息及所述客票提交指令对应的数据库类型确定出用户端对应的目标数据库，将客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息。

接收单元501，还用于接收第二电子设备发送的客票校验信息。

处理单元503，用于根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回所述订单信息。

在一种可能的实施例中，处理单元503，具体用于，根据客票提交指令的类型，确定客票提交指令对应的数据库类型包括：

在客票提交指令的类型包括客票购买类型时，确定客票提交指令对应的数据库类型为购票类型；在客票提交指令的类型包括客票退改签类型时，确定客票提交指令对应的数据库类型为退改签类型。

与上述实施例相对应，如图6所示，本申请还提供了另一种客票的数据处理装置，包括：

接收单元601，用于第二电子设备接收第一电子设备发送的客票校验信息获取请求消息；其中，客票校验信息获取请求消息中包含有用户标识信息及客票提交指令对应的数据库类型。

处理单元602，用于根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库；还用于将客票校验信息获取请求消息发送至目标数据库。

接收单元601，还用于接收目标数据发送的客票校验信息。

处理单元602，还用于将客票校验信息发送至第一电子设备。

在一种可能的实现方式中，处理单元602，具体用于，将客票校验信息获取请求消息发送至目标数据库包括：

根据目标数据的数据格式，将客票校验信息获取请求消息的数据格式转换为目标数据库的数据格式，并发送至目标数据库。

在一种可能的实现方式中，处理单元602，具体用于，将客票校验信息发送至第一电子设备包括：

将客票校验信息的数据格式转换为第一电子设备的数据格式，并发送至第一电子设备。

在一种可能的实现方式中，处理单元602还用于，检测已建立连接的数据库中是否有故障数据库；根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库包括：

根据用户标识信息及客票提交指令对应的数据库类型，在已建立连接的，且没有故障的数据库中确定目标数据库。

在一种可能的实现方式中，接收单元601具体用于，接收新增数据库的连接建立请求消息。其中，连接建立请求消息中携带有新增数据库的数据格式。

处理单元602，还用于与新增数据库建立连接，并保存新增数据库的数据格式。

与上述实施例相对应，如图7所示，本申请还提供了另一种客票的数据处理装置，包括：

接收单元701，用于第三电子设备接收用户端发送的客票提交指令。其中，客票提交指令中包含有用户标识信息。

处理单元703，用于根据客票提交指令的类型及所述用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库；

获取单元702，用于向目标数据库发送客票校验信息获取请求消息。

接收单元701还用于，接收目标数据库发送的客票校验信息。

处理单元703还用于，根据客票校验信息验证客票提交指令是否通过，并在验证通过时，生成订单信息，向用户端返回订单信息。

与上述实施例相对应，本申请还提供了一种电子设备，图8为本发明实施例提供的一种电子设备的结构示意图，所述电子设备800可以包括：处理器801、存储器802及通信单元803。这些组件通过一条或多条总线进行通信，本领域技术人员可以理解，图中示出的服务器的结构并不构成对本发明实施例的限定，它既可以是总线形结构，也可以是星型结构，还可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

其中，所述通信单元803，用于建立通信信道，从而使所述客票的数据处理设备可以与其它设备进行通信。接收其他设备发是的用户数据或者向其他设备发送用户数据。

所述处理器801，为客票的数据处理设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器802内的软件程序和/或模块，以及调用存储在存储器内的数据，以执行电子设备的各种功能和/或处理数据。所述处理器可以由集成电路(integrated circuit，IC)组成，例如可以由单颗封装的IC所组成，也可以由连接多颗相同功能或不同功能的封装IC而组成。举例来说，处理器801可以仅包括中央处理器(central processing unit，CPU)。在本发明实施方式中，CPU可以是单运算核心，也可以包括多运算核心。

所述存储器802，用于存储处理器801的执行指令，存储器802可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

当存储器802中的执行指令由处理器801执行时，使得电子设备800能够执行图3或图4所示实施例中的部分或全部步骤。

具体实现中，本发明还提供一种计算机存储介质，其中，该计算机存储介质可存储有程序，该程序执行时可包括本发明提供的客票的数据处理方法的各实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，ROM)或随机存储记忆体(random access memory，RAM)等。

本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于装置实施例和终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

Claims (13)

1.一种客票的数据处理方法，其特征在于，包括：

第一电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息及用户的客票相关信息；

根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型，以使得所述第二电子设备根据所述用户标识信息及所述客票提交指令对应的数据库类型确定出所述用户端对应的目标数据库，将所述客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息；

接收所述第二电子设备发送的客票校验信息；

根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

2.根据权利要求1所述的方法，其特征在于，

所述客票提交指令的类型包括客票购买类型、客票退改签类型；

所述根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型包括：

在所述客票提交指令的类型包括客票购买类型时，确定所述客票提交指令对应的数据库类型为购票类型；

在所述客票提交指令的类型包括客票退改签类型时，确定所述客票提交指令对应的数据库类型为退改签类型。

3.一种客票的数据处理方法，其特征在于，包括：

第二电子设备接收第一电子设备发送的客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型；

根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库；

将所述客票校验信息获取请求消息发送至目标数据库；

接收所述目标数据库发送的客票校验信息；

将所述客票校验信息发送至所述第一电子设备。

4.根据权利要求3所述的方法，其特征在于，所述将所述客票校验信息获取请求消息发送至目标数据库包括：

根据所述目标数据的数据格式，将所述客票校验信息获取请求消息的数据格式转换为所述目标数据库的数据格式，并发送至所述目标数据库。

5.根据权利要求3所述的方法，其特征在于，所述将所述客票校验信息发送至所述第一电子设备包括：

将所述客票校验信息的数据格式转换为所述第一电子设备的数据格式，并发送至所述第一电子设备。

6.根据权利要求3所述的方法，其特征在于，还包括：

检测已建立连接的数据库中是否有故障数据库；

所述根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库包括：

根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的，且没有故障的数据库中确定目标数据库。

7.根据权利要求3所述的方法，其特征在于，还包括：

接收新增数据库的连接建立请求消息，所述连接建立请求消息中携带有所述新增数据库的数据格式；

与所述新增数据库建立连接，并保存所述新增数据库的数据格式。

8.一种客票的数据处理方法，其特征在于，包括：

第三电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息；

根据所述客票提交指令的类型及所述用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库；

向所述目标数据库发送客票校验信息获取请求消息；

接收所述目标数据库发送的客票校验信息；

根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

9.一种客票的数据处理装置，其特征在于，包括：

接收单元，用于第一电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息及用户的客票相关信息；还用于接收所述第二电子设备发送的客票校验信息；

获取单元，用于根据所述客票提交指令的类型，确定所述客票提交指令对应的数据库类型，向第二电子设备发送客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型，以使得所述第二电子设备根据所述用户标识信息及所述客票提交指令对应的数据库类型确定出所述用户端对应的目标数据库，将所述客票校验信息获取请求消息发送至目标数据库，并从目标数据库中获取客票校验信息；

处理单元，用于根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

10.一种客票的数据处理装置，其特征在于，包括：

接收单元，用于第二电子设备接收第一电子设备发送的客票校验信息获取请求消息；所述客票校验信息获取请求消息中包含有用户标识信息及所述客票提交指令对应的数据库类型；

处理单元，用于根据所述用户标识信息及所述客票提交指令对应的数据库类型，在已建立连接的数据库中确定目标数据库；还用于将所述客票校验信息获取请求消息发送至目标数据库；

接收单元还用于接收所述目标数据发送的客票校验信息；

处理单元还用于将所述客票校验信息发送至所述第一电子设备。

11.一种客票的数据处理装置，其特征在于，包括：

接收单元，用于第三电子设备接收用户端发送的客票提交指令；所述客票提交指令中包含有用户标识信息；

处理单元，用于根据所述客票提交指令的类型及所述用户标识信息，在已建立连接的数据库中确定用户端对应的目标数据库；

获取单元，用于向所述目标数据库发送客票校验信息获取请求消息；

接收单元还用于，接收所述目标数据库发送的客票校验信息；

处理单元还用于，根据所述客票校验信息验证所述客票提交指令是否通过，并在验证通过时，生成订单信息，向所述用户端返回所述订单信息。

12.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储有计算机程序，当所述计算机程序被执行时，使得所述电子设备执行权利要求1-2任一项或3-7任一项或8所述的方法。

13.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1-2任一项或3-7任一项或8所述的方法。

Images