A data processing method, device, equipment and storage medium for passenger tickets

Abstract

The embodiments of the present application provide a method, apparatus, device, and storage medium for processing passenger ticket data. The method includes a first electronic device receiving a passenger ticket submission instruction sent by a user terminal; determining the database type corresponding to the passenger ticket submission instruction based on the type of the passenger ticket submission instruction, and sending a passenger ticket verification information acquisition request message to a second electronic device; receiving the passenger ticket verification information sent by the second electronic device; verifying whether the passenger ticket submission instruction is passed based on the passenger ticket verification information, and generating order information when the verification is passed, and returning the order information to the user terminal. In this way, the first electronic device only needs to execute business logic, and the database only needs to store data. The interaction between the first electronic device and the database can be completed through the second electronic device, thereby achieving decoupling of business logic and data storage, and improving data processing efficiency.

Description

Technical Field

[0001] The present application relates to the field of electronic information technology, and specifically to a data processing method, device, equipment and storage medium for passenger tickets. Background Art

[0002] With the widespread application of network and communication technologies such as mobile devices and smart terminals in the ticketing system, more and more functions are being developed in the ticketing system, and the types and scale of passenger data are growing at an unprecedented rate. The ticketing system has entered the big data era.

[0003] In the prior art, the core business logic of a ticketing system—that is, the implementation of each core business function in the system—and its data storage are all performed within a single database. For example, the business logic for verifying ticket information based on the booking information provided by the passenger and issuing the ticket, as well as the data storage for the user's order information, are all performed within the same database. This has resulted in a comprehensive technical architecture and business organization model for the ticketing system. However, since business logic data and data storage in existing ticketing systems are stored in the same database, a coupled relationship exists between the two. When developing new services, in addition to considering the implementation method for the new business logic, the database storage location of the associated data must also be considered. This can lengthen the development cycle and hinder debugging of development code. Furthermore, the volume of both business logic and data storage is substantial. Storing both in the same database can lead to excessive database load, prolonged data processing, and reduced work efficiency. Summary of the Invention

[0004] In view of this, the present application provides a ticket data processing method, device, equipment and storage medium to help solve the problems of high database load and low work efficiency in the prior art.

[0005] In a first aspect, an embodiment of the present application provides a method for processing ticket data, the method comprising:

[0006] The first electronic device receives a ticket submission instruction sent by the user terminal; the ticket submission instruction includes user identification information and user ticket-related information;

[0007] Determine, based on the type of the ticket submission instruction, the type of database corresponding to the ticket submission instruction, and send a ticket verification information acquisition request message to the second electronic device; the ticket verification information acquisition request message includes user identification information and the type of database corresponding to the ticket submission instruction, so that the second electronic device determines the target database corresponding to the user terminal based on the user identification information and the type of database corresponding to the ticket submission instruction, sends the ticket verification information acquisition request message to the target database, and acquires the ticket verification information from the target database;

[0008] receiving ticket verification information sent by the second electronic device;

[0009] Verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

[0010] Preferably, the method further comprises:

[0011] The types of the ticket submission instructions include ticket purchase type and ticket refund and change type;

[0012] The determining, based on the type of the ticket submission instruction, the database type corresponding to the ticket submission instruction includes:

[0013] When the type of the ticket submission instruction includes a ticket purchase type, determining that the database type corresponding to the ticket submission instruction is a ticket purchase type;

[0014] When the type of the ticket submission instruction includes a ticket refund, change or rebooking type, it is determined that the database type corresponding to the ticket submission instruction is a ticket refund, change or rebooking type.

[0015] In a second aspect, an embodiment of the present application provides another method for processing ticket data, the method comprising:

[0016] The second electronic device receives a ticket verification information acquisition request message sent by the first electronic device; the ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction;

[0017] Determine a target database from among the established databases based on the user identification information and the database type corresponding to the ticket submission instruction;

[0018] Sending the ticket verification information acquisition request message to the target database;

[0019] Receiving ticket verification information sent by the target data;

[0020] The ticket verification information is sent to the first electronic device.

[0021] Preferably, the step of sending the ticket verification information acquisition request message to the target database includes:

[0022] According to the data format of the target data, the data format of the ticket verification information acquisition request message is converted into the data format of the target database and sent to the target database.

[0023] Preferably, sending the ticket verification information to the first electronic device includes:

[0024] The data format of the ticket verification information is converted into the data format of the first electronic device and sent to the first electronic device.

[0025] Preferably, the method further comprises:

[0026] Check whether there is a faulty database among the connected databases;

[0027] The determining of the target database from the established connected databases according to the user identification information and the database type corresponding to the ticket submission instruction includes:

[0028] According to the user identification information and the database type corresponding to the ticket submission instruction, the target database is determined from the databases that have established connections and have no faults.

[0029] Preferably, the method further comprises:

[0030] Receive a connection establishment request message for a newly added database, wherein the connection establishment request message carries a data format of the newly added database;

[0031] Establish a connection with the newly added database and save the data format of the newly added database.

[0032] In a third aspect, an embodiment of the present application provides another method for processing ticket data, the method comprising:

[0033] The third electronic device receives a ticket submission instruction sent by the user terminal; the ticket submission instruction includes user identification information;

[0034] Determining a target database corresponding to the user terminal in the established databases according to the type of the ticket submission instruction and the user identification information;

[0035] Sending a ticket verification information acquisition request message to the target database;

[0036] Receiving ticket verification information sent by the target database;

[0037] Verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

[0038] In a fourth aspect, an embodiment of the present application provides a ticket data processing device, comprising:

[0039] A receiving unit, configured to receive, by the first electronic device, a ticket submission instruction sent by a user terminal; the ticket submission instruction includes user identification information and user ticket-related information; and to receive ticket verification information sent by the second electronic device;

[0040] an acquiring unit, configured to determine, based on the type of the ticket submission instruction, a database type corresponding to the ticket submission instruction, and send a ticket verification information acquisition request message to the second electronic device; the ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction, so that the second electronic device determines, based on the user identification information and the database type corresponding to the ticket submission instruction, a target database corresponding to the user terminal, sends the ticket verification information acquisition request message to the target database, and acquires the ticket verification information from the target database;

[0041] The processing unit is used to verify whether the ticket submission instruction is passed according to the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

[0042] In a fifth aspect, an embodiment of the present application provides a ticket data processing device, comprising:

[0043] A receiving unit, configured for the second electronic device to receive a ticket verification information acquisition request message sent by the first electronic device; the ticket verification information acquisition request message includes user identification information and a database type corresponding to the ticket submission instruction;

[0044] a processing unit, configured to determine a target database from among the established databases based on the user identification information and the database type corresponding to the ticket submission instruction; and further configured to send the ticket verification information acquisition request message to the target database;

[0045] The receiving unit is further used to receive the ticket verification information sent by the target data;

[0046] The processing unit is also used to send the ticket verification information to the first electronic device.

[0047] In a sixth aspect, an embodiment of the present application provides a ticket data processing device, comprising:

[0048] A receiving unit, configured for the third electronic device to receive a ticket submission instruction sent by a user terminal; the ticket submission instruction includes user identification information;

[0049] A processing unit, configured to determine a target database corresponding to the user terminal from among the databases with established connections, based on the type of the ticket submission instruction and the user identification information;

[0050] An acquiring unit, configured to send a ticket verification information acquiring request message to the target database;

[0051] The receiving unit is further used to receive the ticket verification information sent by the target database;

[0052] The processing unit is also used to verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

[0053] In the seventh aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed, the electronic device executes the method described in any one of the first aspect, any one of the second aspect, or any one of the third aspect.

[0054] In an eighth aspect, an embodiment of the present application provides a storage medium, which includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the method described in any one of the first aspect, any one of the second aspect, or any one of the third aspect.

[0055] Using the solution provided by the embodiment of the present application, the first electronic device receives the ticket submission instruction sent by the user terminal, and the first electronic device executes business logic, such as verifying the ticket-related information contained in the ticket submission instruction, that is, the ticket's train number information, passenger information, timetable information and other data information. When the first electronic device verifies the ticket information submitted by the user terminal, it needs to obtain the ticket verification information stored in the database. At this time, the first electronic device does not need to know the specific storage location of the ticket verification information in the database. It only needs to send a ticket verification information acquisition request message to the second electronic device, so that the second electronic device determines the target database corresponding to the user terminal based on the ticket verification information acquisition request message, and thus obtains the ticket verification information stored in the target database. The first electronic device receives the ticket verification information sent by the second electronic device to complete the verification of the ticket information submitted by the user terminal, and when the verification passes, generates order information and returns the order information to the user terminal. That is to say, when the first electronic device needs to interact with the target database corresponding to the user end during the execution of the business logic, the first electronic device does not need to determine the specific location of the target database corresponding to the user end, nor does it need to determine the specific location of the target data required to execute the business logic in the target database corresponding to the user end. Instead, by sending a specific business request message to the second electronic device, the second electronic device can determine the target database corresponding to the user end based on the specific business request message, and then obtain the corresponding target data from the target database based on the specific business request message. According to the above-mentioned ticket data processing method, the first electronic device only needs to execute the business logic, and the database only needs to store data. At the same time, the first electronic device can complete the interaction with the database through the second electronic device, thereby realizing the decoupling of business logic and data storage and improving the efficiency of data processing. Moreover, when developing new business, only the implementation method of the new business logic needs to be considered, and there is no need to consider the location of the data associated with it in the database, which reduces the difficulty of developing new business. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0057] Figure 1 A flowchart of a method for processing ticket data provided in an embodiment of the present application;

[0058] Figure 2 A flowchart of another method for processing passenger ticket data provided in an embodiment of the present application;

[0059] Figure 3 A flowchart of another method for processing passenger ticket data provided in an embodiment of the present application;

[0060] Figure 4 A flowchart of another method for processing passenger ticket data provided in an embodiment of the present application;

[0061] Figure 5 A schematic diagram of the structure of a ticket data processing device provided in an embodiment of the present application;

[0062] Figure 6 A schematic diagram of the structure of another ticket data processing device provided in an embodiment of the present application;

[0063] Figure 7 A schematic diagram of the structure of another ticket data processing device provided in an embodiment of the present application;

[0064] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to better understand the technical solution of the present application, the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0066] It should be clear that the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0067] The terms used in the embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit the present application. The singular forms "a", "an", "the" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise.

[0068] It should be understood that the term "and / or" as used herein simply describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the associated objects.

[0069] Before providing a detailed introduction to the embodiments of the present application, the terms that are applied or may be applied to the embodiments of the present application are first explained.

[0070] SQL Statements: SQL (Structured Query Language) is a standard computer language, coded in the American National Standards Institute (ANSI), for accessing and manipulating database systems. SQL statements are used to retrieve and update data in a database, and SQL works in conjunction with database programs.

[0071] JSON data format: JSON (Java Script Object Notation) is a lightweight data exchange format. It uses a text format that is completely independent of programming languages ​​to store and represent data. Its simplicity and clear hierarchical structure make JSON an ideal data exchange language. It is easy for humans to read and write, as well as for machines to parse and generate, and it significantly improves network transmission efficiency.

[0072] Database: A database is a warehouse that organizes, stores, and manages data according to data structures. It is a collection of large amounts of data that is stored in a computer for a long time, organized, shareable, and uniformly managed.

[0073] Sybase Database: A relational database system developed by Sybase Corporation in the United States. It is a typical large-scale database system in a client / server environment running on UNIX or Windows NT operating systems. Sybase provides a suite of application programming interfaces and libraries that enable integration with non-Sybase data sources and servers, allowing data replication between multiple databases and suitable for building multi-tier applications. The system features a comprehensive set of triggers, stored procedures, rules, and integrity definitions, supports optimized queries, and offers strong data security.

[0074] PostgreSQL Database: PostgreSQL is a fully featured free software object-relational database management system. It supports most of the SQL standard and provides many other modern features, such as complex queries, foreign keys, triggers, views, transactional integrity, and multi-version concurrency control. PostgreSQL is also extensible in many ways, such as by adding new data types, functions, operators, aggregate functions, indexing methods, and a procedural language.

[0075] In related technologies, the core business logic of a ticketing system—that is, the implementation of each core business function in the system—and its data storage are all performed within a single database. For example, the business logic for verifying ticket information based on the booking information provided by the passenger and issuing tickets, as well as the data for storing the user's order information, are all performed within the same database. This has resulted in a comprehensive technical architecture and business organization model for ticketing systems. However, since business logic data and data storage in existing ticketing systems are stored in the same database, a coupled relationship exists between the two. When developing new services, in addition to considering the implementation method for the new business logic, the database storage location of the associated data must also be considered. This can lengthen the development cycle and hinder debugging of development code. Furthermore, the volume of both business logic and data storage is substantial. Storing both in the same database can lead to excessive database load, lengthy data processing times, and reduced work efficiency.

[0076] To address the above-mentioned issues, an embodiment of the present application provides a method for processing ticket data. The method includes: a first electronic device receiving a ticket submission instruction sent by a user terminal, and the first electronic device executing business logic, such as verifying the ticket-related information contained in the ticket submission instruction, namely, the train number information, passenger information, timetable information, and other data information of the ticket. When the first electronic device verifies the ticket information submitted by the user terminal, it needs to obtain ticket verification information stored in a database. In this case, the first electronic device does not need to know the specific storage location of the ticket verification information in the database. It only needs to send a ticket verification information acquisition request message to a second electronic device, so that the second electronic device determines the target database corresponding to the user terminal based on the ticket verification information acquisition request message, and thereby obtains the ticket verification information stored in the target database. The first electronic device receives the ticket verification information sent by the second electronic device to complete the verification of the ticket information submitted by the user terminal. If the verification passes, it generates order information and returns the order information to the user terminal. That is to say, when the first electronic device needs to interact with the target database corresponding to the user end during the execution of business logic, the first electronic device does not need to determine the specific location of the target database corresponding to the user end, nor does it need to determine the specific location of the target data required to execute the business logic in the target database corresponding to the user end. Instead, by sending a specific business request message to the second electronic device, the second electronic device can determine the target database corresponding to the user end according to the specific business request message, and then obtain the corresponding target data from the target database according to the specific business request message. According to the above-mentioned data processing method for passenger tickets, the first electronic device only needs to execute business logic, and the database only needs to store data. The interaction between the first electronic device and the database can be completed through the second electronic device, thereby realizing the decoupling of business logic and data storage, improving the efficiency of data processing, and also facilitating the subsequent development of new businesses. The following is a detailed description.

[0077] Figure 1 This is a flow chart of a method for processing ticket data provided by an embodiment of the present application. Figure 1 The ticket data processing method mainly includes the following steps:

[0078] Step S101: The first electronic device receives a ticket submission instruction sent by a user terminal.

[0079] The ticket submission instruction includes user identification information and the user's ticket-related information.

[0080] Specifically, when a user needs to purchase a ticket or refund or change a ticket, the user can send a ticket submission instruction to the first electronic device. The first electronic device receives the ticket submission instruction sent by the user. The ticket submission instruction includes user identification information and the user's ticket-related information, where the user identification information may include the user's username and user identity information. The user's ticket-related information includes at least the ticket's train number, passenger information, and timetable information.

[0081] Step S102: Determine the database type corresponding to the ticket submission instruction according to the type of the ticket submission instruction, and send a ticket verification information acquisition request message to the second electronic device.

[0082] The ticket verification information acquisition request message includes the user identification information and the database type corresponding to the ticket submission instruction. This allows the second electronic device to determine the target database corresponding to the user terminal based on the user identification information and the database type corresponding to the ticket submission instruction, send the ticket verification information acquisition request message to the target database, and obtain the ticket verification information from the target database. In other words, the first electronic device only needs to send the ticket verification information acquisition request message to the second electronic device, and the second electronic device will determine the target database corresponding to the user terminal, obtain the ticket verification information from the target database corresponding to the user terminal, and then send it to the first electronic device.

[0083] In an embodiment of the present application, after a first electronic device receives a ticket submission instruction from a user, it needs to verify whether the ticket information meets the requirements. For example, it needs to verify whether the departure and arrival stations of the ticketed train are open, whether the passenger has already booked other tickets that conflict with the current train, and other information. Only when the verification is successful can the corresponding ticket order be generated. Therefore, the first electronic device needs to obtain ticket verification information from the database corresponding to the ticket submission instruction to complete the verification. The ticket verification information includes at least the ticket's train information, passenger information, and timetable information.

[0084] In this way, the first electronic device can first determine the database type corresponding to the ticket submission instruction based on the type of the ticket submission instruction, and then send a ticket verification information acquisition request message to the second electronic device to obtain the ticket verification information. The ticket submission instruction type includes a ticket purchase type and a ticket refund or change type.

[0085] Based on the type of ticket submission instruction, the database type corresponding to the ticket submission instruction is determined as follows:

[0086] When the type of the ticket submission instruction includes a ticket purchase type, determining that the database type corresponding to the ticket submission instruction is a ticket purchase type;

[0087] When the type of the ticket submission instruction includes the ticket refund, change or rebooking type, it is determined that the database type corresponding to the ticket submission instruction is the ticket refund, change or rebooking type.

[0088] Specifically, when a user submits ticket information, they might be submitting new ticket purchase information or refund / change information for an already purchased ticket. Typically, due to the massive amount of data required to store in ticketing systems, the database storing ticket purchase information is separate from the database storing ticket refund / change information to reduce database load. Therefore, a ticket submission instruction can be of either the purchase or refund / change type. Based on the type of ticket submission instruction, the corresponding database type can be determined as either the purchase or refund / change type.

[0089] Step S103: Receive ticket verification information sent by the second electronic device.

[0090] After the first electronic device sends a ticket verification information acquisition request message to the second electronic device, the second electronic device can determine the target database corresponding to the user terminal based on the received ticket verification information, send the ticket verification information acquisition request message to the target database, and acquire the ticket verification information from the target database. Thus, the first electronic device receives the ticket verification information sent by the second electronic device.

[0091] Step S104: Verify whether the ticket submission instruction is passed based on the ticket verification information, and if the verification is passed, generate order information and return the order information to the user end.

[0092] Specifically, the ticket submission instruction sent by the user terminal and received by the first electronic device contains the user's ticket-related information, namely, the ticket's train number, passenger information, timetable information, and other information. Furthermore, the ticket verification information sent by the second electronic device and received by the first electronic device also includes at least the ticket's train number, passenger information, and timetable information. Therefore, based on the ticket verification information received from the second electronic device, the first electronic device can verify whether the ticket submission instruction has been approved. For example, based on the ticket's train number and timetable information, the first electronic device can verify whether the current train number and time are correct, whether the departure and arrival stations of the ticketed train are open, whether the passenger information is correct, and whether the passenger has already booked other tickets that conflict with the current train's time. Upon successful verification, order information is generated.

[0093] As a possible implementation, order information varies depending on the type of ticket submission instruction submitted by the user. Specifically, order information can be divided into ticket purchase order information, ticket change order information, and ticket refund order information. When the ticket submission instruction submitted by the user is of the ticket purchase type, the order information generated is ticket purchase order information. When the ticket submission instruction submitted by the user is of the ticket refund type, the order information generated is ticket refund order information. When the ticket submission instruction submitted by the user is of the ticket change type, the order information generated is ticket change order information.

[0094] Ticket purchase order information includes the purchased train number, seat number, passenger information, departure time, arrival time, and successful purchase. Rebooking order information includes the changed train number, seat number, passenger information, departure time, arrival time, and successful refund. Refund order information includes the refunded train number, seat number, passenger information, departure time, arrival time, and successful refund. After generating the order information, the information is returned to the user.

[0095] The above is a possible embodiment. When the user submits the ticket information, the first electronic device receives the ticket submission instruction sent by the user terminal and sends a ticket verification information acquisition request message to the second electronic device, thereby obtaining the ticket verification information through the second electronic device to complete the verification of the user's ticket-related information contained in the ticket submission instruction sent by the user terminal. After the verification is passed, the order information is generated and returned to the user terminal. In this way, when the first electronic device executes the business logic, it can interact with the relevant database through the second electronic device without considering the location of the required data information in the relevant database, thereby improving the efficiency of data processing.

[0096] Figure 2 Another method for processing ticket data provided in the embodiment of the present application. Figure 2 , specifically including the following steps:

[0097] Step S201: The second electronic device receives a ticket verification information acquisition request message sent by the first electronic device.

[0098] The ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction.

[0099] Specifically, when the first electronic device needs to verify the ticket submission instruction sent by the user terminal, it will send a ticket verification information acquisition request message to the second electronic device. At this time, the second electronic device receives the ticket verification information acquisition request message sent by the first electronic device.

[0100] Step S202: Determine the target database from the databases with established connections based on the user identification information and the database type corresponding to the ticket submission instruction.

[0101] In this embodiment of the present application, the ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction. That is, the ticket verification information acquisition request message includes user name information, and the database type corresponding to the ticket submission instruction is a ticket purchase type or a refund and change type.

[0102] Specifically, when accessing a database, a connection must be established with the database, and after each access, the database connection is disconnected. The next time the database is accessed, a new connection must be established, which increases data processing time. Therefore, when a user activates the ticket service, to improve data processing efficiency, the second electronic device establishes and maintains connections with multiple databases storing ticket data information. This allows direct access to the relevant database without requiring multiple connections, thus saving time in establishing database connections.

[0103] In an embodiment of the present application, since there are multiple databases storing ticket information, the second electronic device can allocate databases to all users based on user identification information, so that the load of multiple databases is balanced. In order to further reduce the database load, each database contains a ticket purchase type database and a refund and change type database, and the data information in the ticket purchase type database will be synchronized to the refund and change type database in the same database, so that when a refund or change is made to a purchased ticket order, the corresponding refund and change type database stores the ticket information of the purchased ticket order, and the corresponding operation can be performed directly in the corresponding refund and change type database. Then, when the second electronic device receives the ticket verification information acquisition request message sent by the first electronic device, it can determine the target database in the database with which the connection has been established based on the user identification information and the database type corresponding to the ticket submission instruction.

[0104] For example, assume there are 20 databases storing ticket data, each of which is divided into a purchase-type database and a refund / change-type database. A second electronic device can set the usernames of all users to be calculated using a specific algorithm, with the result being in the range of 1-400. The database corresponding to users with a calculated result of 1-20 is database 1, the database corresponding to users with a calculated result of 21-40 is database 2, and so on. The database corresponding to users with a calculated result of 381-400 is database 20. This ensures load balancing across all databases. Assume the second electronic device has established connections with all 20 databases. The second electronic device receives a ticket verification information acquisition request message from the first electronic device. The ticket verification information acquisition request message includes a user's username A, and the database type corresponding to the ticket submission instruction is ticket purchase. If the second electronic device calculates a result of 10 based on username A using the specific algorithm, it determines that the database corresponding to this user is database 1. Since the database type corresponding to the ticket submission instruction is ticket purchase, the second electronic device determines the ticket purchase-type database in the first database as the target database.

[0105] It should be noted that the above-mentioned specific algorithm can be a hash algorithm or other algorithms, and this application does not impose any restrictions on this.

[0106] Step S203: Send the ticket verification information acquisition request message to the target database.

[0107] Specifically, after the second electronic device determines the target database, it can send a ticket verification information acquisition request message to the target database.

[0108] Furthermore, sending the ticket verification information acquisition request message to the target database includes:

[0109] According to the data format of the target data, the data format of the ticket verification information acquisition request message is converted into the data format of the target database and sent to the target database.

[0110] Specifically, since the target database can be different types of databases, such as Sybase database and PostgreSQL database, each database has a corresponding data format. When accessing the database, the data format of the ticket verification information acquisition request message needs to be converted into the data format of the target database and sent to the target database.

[0111] As a possible implementation method, SQL statements corresponding to accessing different databases are pre-set in the second electronic device. The second electronic device can use the SQL statement corresponding to the target database according to the data format corresponding to the target database to send the ticket verification information acquisition request message to the target database.

[0112] Among them, SQL statements are a standard computer language of character codes used to access and operate database systems.

[0113] Step S204: Receive ticket verification information sent by the target database.

[0114] In an embodiment of the present application, after receiving a ticket verification information acquisition request message, the target database can determine the ticket verification information to be acquired based on the ticket verification information acquisition request message, acquire the corresponding ticket verification information from the target database, and send the ticket verification information to the second electronic device. The second electronic device receives the ticket verification information sent by the target database.

[0115] Step S205: Send the ticket verification information to the first electronic device.

[0116] Specifically, since the ticket information is verified on the first electronic device, that is, the business logic operation of the ticket is executed on the first electronic device, the second electronic device can send the ticket verification information to the first electronic device after receiving the ticket verification information.

[0117] Furthermore, sending the ticket verification information to the first electronic device includes: converting the data format of the ticket verification information into the data format of the first electronic device, and sending it to the first electronic device.

[0118] Specifically, to facilitate data parsing and transmission, the first electronic device uses a data format commonly used by computers, such as the JSON data format. Therefore, to facilitate the first electronic device's parsing of the ticket verification information, the second electronic device can first convert the ticket verification information into the first electronic device's data format and send it to the first electronic device.

[0119] As a possible embodiment, Figure 3 This is a flow chart of another method for processing ticket data provided by an embodiment of the present application. Figure 3 , the specific steps are as follows:

[0120] Step S301: The first electronic device receives a ticket submission instruction sent by the user terminal.

[0121] For details, please refer to the above step S101, which will not be described again here.

[0122] Step S302: The first electronic device determines the database type corresponding to the ticket submission instruction based on the type of the ticket submission instruction, and sends a ticket verification information acquisition request message to the second electronic device. The second electronic device receives the ticket verification information acquisition request message sent by the first electronic device.

[0123] For details, please refer to the above steps S102 and S201, which will not be described again here.

[0124] Step S303: The second electronic device determines the target database from the databases with which the connection has been established based on the user identification information and the database type corresponding to the ticket submission instruction.

[0125] For details, please refer to the above step S202, which will not be repeated here.

[0126] Step S304: The second electronic device sends a ticket verification information acquisition request message to the target database; the target database receives the ticket verification information acquisition request message.

[0127] After receiving the ticket verification information acquisition request message, the target database can determine the ticket verification information that needs to be acquired based on the ticket verification information acquisition request message, and acquire the corresponding ticket verification information in the target database.

[0128] For details, please refer to the above step S203, which will not be repeated here.

[0129] Step S305: The target database sends the ticket verification information to the second electronic device, and the second electronic device receives the ticket verification information sent by the target database.

[0130] For details, please refer to the above step S204, which will not be repeated here.

[0131] Step S306: The second electronic device sends the ticket verification information to the first electronic device. The first electronic device receives the ticket verification information sent by the second electronic device.

[0132] For details, please refer to the above steps S205 and S103, which will not be described again here.

[0133] Step S307: The first electronic device verifies whether the ticket submission instruction is passed based on the ticket verification information, and generates order information when the verification is passed, and returns the order information to the user terminal.

[0134] For details, please refer to the above step S104, which will not be described again here.

[0135] Step S308: The second electronic device may detect whether there is a faulty database in the database to which the connection is established. If a faulty database is detected, the database is marked as being in a faulty state.

[0136] In the embodiment of the present application, the second electronic device determines the target database corresponding to the user terminal in the database to which it has established a connection, thereby obtaining the ticket verification information of the corresponding user in the target database. When a database failure occurs, it is impossible to promptly feedback the ticket verification information to the second electronic device. In this case, the second electronic device needs to determine the target database in a database that has not failed. Therefore, in order to ensure that the first electronic device quickly obtains the ticket verification information, the second electronic device can detect in real time whether the database to which it has established a connection has failed, so as to prevent the database that has failed from being used as the target data.

[0137] As one possible implementation, the second electronic device can detect whether a database connection has failed by counting the number of failed database access attempts within a preset time period. Specifically, if the number of failed database access attempts within a preset time period exceeds a first preset threshold, the database can be determined to be faulty and marked as faulty. For example, if the second electronic device detects that the number of failed database access attempts exceeds 50 times within 5 minutes, the database can be determined to be faulty and marked as faulty.

[0138] It should be noted that the second electronic device may also detect whether a database to which it has established a connection has failed by other means, for example, by counting the number of consecutive access failures when accessing the database, and determining that the database has failed if the number of consecutive access failures exceeds a second preset threshold. Of course, other means are also possible, and this application does not limit this.

[0139] It should be noted that the first preset number threshold and the second preset number threshold are both preset according to actual needs.

[0140] At this time, in the above step S303, the target database is determined in the established databases according to the user identification information and the database type corresponding to the ticket submission instruction, including:

[0141] According to the user identification information and the database type corresponding to the ticket submission instruction, the target database is determined from the databases that have established connections and are not faulty.

[0142] Specifically, when a faulty database is detected, the database can be marked as a faulty state. Since the faulty database cannot respond to the request message of the first electronic device in a timely manner, in order to ensure that the first electronic device obtains the required ticket verification information in a timely manner, the second electronic device can determine the target database in a database that has been connected and has no faults when determining the target database based on the user identification information and the database type corresponding to the ticket submission instruction. In other words, if the original target database corresponding to a user fails, when the user purchases a new ticket, the user terminal sends a ticket submission instruction of the purchase type. When the second electronic device receives the ticket verification information acquisition request message sent by the first electronic device, the second electronic device can re-determine the corresponding target database for the user in a database that has been connected and has no faults.

[0143] It should be noted that the second electronic device can simultaneously detect whether there is a fault database in the established database during the execution of the above steps S301-S307, so as to mark the fault database in time. In other words, step S308 can be executed simultaneously during the execution of the above steps S301-S307.

[0144] Step S309: The second electronic device receives a connection establishment request message for the newly added database.

[0145] The connection establishment request message carries the data format of the newly added database.

[0146] In this embodiment of the present application, when ticketing service requests surge, to avoid overloading the existing database storing data, the ticketing system can add a certain number of databases based on the number of service requests to accommodate the high concurrency of service requests. When a new database is added, the second electronic device needs to establish a connection with the new database. At this point, the second electronic device receives a connection establishment request message for the new database.

[0147] Step S310: The second electronic device establishes a connection with the newly added database and saves the data format of the newly added database.

[0148] Specifically, after the second electronic device receives the connection establishment request message for the newly added database, it can establish a connection with the newly added database and save the data format of the newly added database. Since the newly added database has established a connection with the second electronic device, the number of databases to which the second electronic device has established a connection has increased. Then, when the number of ticket service requests surges, the second electronic device can determine the newly added database as the target database when determining the target database based on the user identification information and the database type corresponding to the ticket submission instruction, so as to reduce the load pressure on the existing databases connected to the second electronic device and balance the load of each database.

[0149] It should be noted that steps S309-S310 are the process of establishing a connection between the second electronic device and the newly added database when a newly added database exists. In other words, steps S309-S310 are only executed when a newly added database exists.

[0150] As a possible implementation, Figure 4 This is a flow chart of another method for processing ticket data provided in an embodiment of the present application. The specific steps are as follows:

[0151] Step S401: The third electronic device receives the ticket submission instruction sent by the user terminal.

[0152] Among them, the ticket submission instruction contains user identification information.

[0153] For details, please refer to the above step S101, which will not be described again here.

[0154] Step S402: The third electronic device determines the target database corresponding to the user terminal in the database with which the connection has been established based on the type of the ticket submission instruction and the user identification information.

[0155] In an embodiment of the present application, the third electronic device integrates the functions that can be realized by the above-mentioned second electronic device, so the third electronic device can determine the target database corresponding to the user terminal in the database with which the connection has been established based on the type of ticket submission instruction and user identification information.

[0156] For details, please refer to step S202, which will not be described again here.

[0157] Step S403: The third electronic device sends a ticket verification information acquisition request message to the target database, and the target database receives the ticket verification information acquisition request message.

[0158] For details, please refer to step S203, which will not be described again here.

[0159] Step S404: The target database obtains the ticket verification information according to the ticket verification information acquisition request message and sends it to the third electronic device. The third electronic device receives the ticket verification information sent by the target database.

[0160] In an embodiment of the present application, the third electronic device receives the ticket verification information sent by the target database, and converts the data format of the ticket verification information into a universal data format, namely, the JSON data format.

[0161] For details, please refer to step S204 and step S205, which will not be repeated here.

[0162] Step S405: The third electronic device verifies whether the ticket submission instruction is passed based on the ticket verification information, and generates order information when the verification is passed, and returns the order information to the user terminal.

[0163] For details, please refer to step S104, which will not be described in detail here.

[0164] For example, assume there are 20 databases storing ticket data, each of which is divided into a ticket purchase database and a refund / change database. A second electronic device can set the usernames of all users to be calculated using a specific algorithm within the range of 1-400. The database corresponding to users with a calculated value of 1-20 is database 1, the database corresponding to users with a calculated value of 21-40 is database 2, and so on. Users with a calculated value of 381-400 are database 20. Assume a third electronic device receives a ticket submission instruction from a user, which includes the user's username B and is a refund / change instruction. The third electronic device calculates the value of 30 based on the user's username B using a specific algorithm. The third electronic device can then determine that the target database corresponding to the user is database 2 among the connected databases. Since the ticket submission instruction is a refund / change instruction, the third electronic device can determine that the target database corresponding to the user is the refund / change database in database 2. The third electronic device sends a ticket verification information acquisition request message to the refund, change, or ticket change database in the second database, causing the refund, change, or ticket change database in the second database to transmit the corresponding ticket verification information to the third electronic device based on the ticket verification information acquisition request message. The third electronic device receives the ticket verification information sent by the refund, change, or ticket change database in the second database. The third electronic device verifies whether the ticket submission instruction is approved based on the ticket verification information. If the verification is successful, the third electronic device generates order information and returns the order information to the user terminal.

[0165] The above is a possible embodiment. The functions of the first electronic device and the second electronic device can be integrated into the third electronic device, that is, the third electronic device can execute business logic and interact with the database. At the same time, the business logic and database storage are decoupled.

[0166] In this way, the ticket data processing method provided by the embodiments of this application can decouple the execution of business logic in the ticket system from database storage, thereby reducing database load and improving data processing efficiency. Furthermore, when developing new services, only the implementation of the business logic code needs to be considered, without having to worry about the location of data storage, thus reducing the difficulty of new service development.

[0167] Corresponding to the above embodiment, Figure 5 As shown, the present application also provides a ticket data processing device, comprising:

[0168] The receiving unit 501 is configured to receive a ticket submission instruction sent by a user terminal at a first electronic device, wherein the ticket submission instruction includes user identification information and user ticket-related information.

[0169] Acquisition unit 502 is configured to determine the database type corresponding to the ticket submission instruction based on the type of the ticket submission instruction, and to send a ticket verification information acquisition request message to the second electronic device. The ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction, so that the second electronic device determines the target database corresponding to the user terminal based on the user identification information and the database type corresponding to the ticket submission instruction, sends the ticket verification information acquisition request message to the target database, and acquires the ticket verification information from the target database.

[0170] The receiving unit 501 is also used to receive ticket verification information sent by the second electronic device.

[0171] The processing unit 503 is used to verify whether the ticket submission instruction is passed according to the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

[0172] In a possible embodiment, the processing unit 503 is specifically configured to determine, based on the type of the ticket submission instruction, the database type corresponding to the ticket submission instruction, including:

[0173] When the type of the ticket submission instruction includes the ticket purchase type, the database type corresponding to the ticket submission instruction is determined to be the ticket purchase type; when the type of the ticket submission instruction includes the ticket refund and change type, the database type corresponding to the ticket submission instruction is determined to be the refund and change type.

[0174] Corresponding to the above embodiment, Figure 6 As shown, the present application also provides another ticket data processing device, comprising:

[0175] Receiving unit 601 is used for the second electronic device to receive the ticket verification information acquisition request message sent by the first electronic device; wherein the ticket verification information acquisition request message contains user identification information and the database type corresponding to the ticket submission instruction.

[0176] Processing unit 602 is used to determine the target database from the databases with established connections based on the user identification information and the database type corresponding to the ticket submission instruction; and is also used to send a ticket verification information acquisition request message to the target database.

[0177] The receiving unit 601 is also used to receive the ticket verification information sent by the target data.

[0178] The processing unit 602 is also used to send the ticket verification information to the first electronic device.

[0179] In one possible implementation, the processing unit 602 is specifically configured to send the ticket verification information acquisition request message to the target database, including:

[0180] According to the data format of the target data, the data format of the ticket verification information acquisition request message is converted into the data format of the target database and sent to the target database.

[0181] In one possible implementation, the processing unit 602 is specifically configured to send the ticket verification information to the first electronic device, including:

[0182] The data format of the ticket verification information is converted into the data format of the first electronic device and sent to the first electronic device.

[0183] In one possible implementation, the processing unit 602 is further configured to detect whether there is a faulty database in the established databases; and determining the target database in the established databases based on the user identification information and the database type corresponding to the ticket submission instruction includes:

[0184] According to the user identification information and the database type corresponding to the ticket submission instruction, the target database is determined from the databases that have established connections and are not faulty.

[0185] In a possible implementation, the receiving unit 601 is specifically configured to receive a connection establishment request message for a newly added database, wherein the connection establishment request message carries the data format of the newly added database.

[0186] The processing unit 602 is further configured to establish a connection with a newly added database and save the data format of the newly added database.

[0187] Corresponding to the above embodiment, Figure 7 As shown, the present application also provides another ticket data processing device, comprising:

[0188] The receiving unit 701 is configured to receive, via a third electronic device, a ticket submission instruction sent by a user terminal, wherein the ticket submission instruction includes user identification information.

[0189] Processing unit 703 is used to determine the target database corresponding to the user terminal in the established database according to the type of the ticket submission instruction and the user identification information;

[0190] The acquisition unit 702 is used to send a ticket verification information acquisition request message to the target database.

[0191] The receiving unit 701 is also used to receive ticket verification information sent by the target database.

[0192] The processing unit 703 is also used to verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user end.

[0193] Corresponding to the above embodiment, the present application also provides an electronic device, Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 800 may include: a processor 801, a memory 802, and a communication unit 803. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation on the embodiments of the present invention. It can be a bus structure or a star structure, and can also include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0194] The communication unit 803 is used to establish a communication channel so that the ticket data processing device can communicate with other devices, receive user data from other devices or send user data to other devices.

[0195] The processor 801 is the control center of the data processing equipment for passenger tickets. It uses various interfaces and lines to connect the various parts of the entire electronic device. It runs or executes software programs and / or modules stored in the memory 802, and calls the data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor 801 can only include a central processing unit (CPU). In the embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0196] The memory 802 is used to store the execution instructions of the processor 801. The memory 802 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0197] When the execution instructions in the memory 802 are executed by the processor 801, the electronic device 800 can execute Figure 3 or Figure 4 Some or all of the steps in the illustrated embodiments.

[0198] In a specific implementation, the present invention further provides a computer storage medium, wherein the computer storage medium may store a program that, when executed, may include some or all of the steps of each embodiment of the ticket data processing method provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0199] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus a necessary general-purpose hardware platform. Based on this understanding, the technical solutions in the embodiments of the present invention, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments of the present invention or certain portions of the embodiments.

[0200] In this specification, reference can be made to the same or similar parts between the various embodiments. In particular, for the device embodiment and the terminal embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiment.

Claims

1. A method for processing passenger ticket data, characterized in that: include: The first electronic device receives a ticket submission instruction sent by the user terminal; The ticket submission instruction includes user identification information and user's ticket related information; The first electronic device determines the database type corresponding to the ticket submission instruction based on the type of the ticket submission instruction, and sends a ticket verification information acquisition request message to the second electronic device; the ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction, so that the second electronic device determines the target database corresponding to the user terminal based on the user identification information and the database type corresponding to the ticket submission instruction, sends the ticket verification information acquisition request message to the target database, and acquires the ticket verification information from the target database; The first electronic device receives the ticket verification information sent by the second electronic device; The first electronic device verifies whether the ticket submission instruction is passed based on the ticket verification information, and generates order information when the verification is passed, and returns the order information to the user terminal.

2. The method according to claim 1, characterized in that The types of the ticket submission instructions include ticket purchase type and ticket refund and change type; The determining, based on the type of the ticket submission instruction, the database type corresponding to the ticket submission instruction includes: When the type of the ticket submission instruction includes a ticket purchase type, determining that the database type corresponding to the ticket submission instruction is a ticket purchase type; When the type of the ticket submission instruction includes a ticket refund, change or rebooking type, it is determined that the database type corresponding to the ticket submission instruction is a ticket refund, change or rebooking type.

3. A method for processing passenger ticket data, characterized in that: include: The second electronic device receives the ticket verification information acquisition request message sent by the first electronic device; The ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction; Determining a target database from among the established connected databases based on the user identification information and the database type corresponding to the ticket submission instruction; wherein the database type corresponding to the ticket submission instruction is determined by the first electronic device based on the type of the ticket submission instruction; Sending the ticket verification information acquisition request message to the target database; Receiving ticket verification information sent by the target database; The ticket verification information is sent to the first electronic device so that the first electronic device can verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user end.

4. The method according to claim 3, characterized in that The sending of the ticket verification information acquisition request message to the target database includes: According to the data format of the target database, the data format of the ticket verification information acquisition request message is converted into the data format of the target database and sent to the target database.

5. The method according to claim 3, characterized in that The sending of the ticket verification information to the first electronic device includes: The data format of the ticket verification information is converted into the data format of the first electronic device and sent to the first electronic device.

6. The method according to claim 3, characterized in that Also includes: Check whether there is a faulty database among the connected databases; The determining of the target database from the established connected databases according to the user identification information and the database type corresponding to the ticket submission instruction includes: According to the user identification information and the database type corresponding to the ticket submission instruction, the target database is determined from the databases that have established connections and have no faults.

7. The method according to claim 3, characterized in that Also includes: Receive a connection establishment request message for a newly added database, wherein the connection establishment request message carries a data format of the newly added database; Establish a connection with the newly added database and save the data format of the newly added database.

8. A method for processing passenger ticket data, characterized in that: include: The third electronic device receives the ticket submission instruction sent by the user terminal; The ticket submission instruction includes user identification information; The third electronic device determines the target database corresponding to the user terminal from the databases with established connections according to the type of the ticket submission instruction and the user identification information; The third electronic device sends a ticket verification information acquisition request message to the target database; The third electronic device receives the ticket verification information sent by the target database; The third electronic device verifies whether the ticket submission instruction is passed based on the ticket verification information, and generates order information when the verification is passed, and returns the order information to the user terminal.

9. A data processing device for passenger tickets, characterized in that: The method for executing any one of claims 1 to 2 comprises: A receiving unit, configured to receive, by the first electronic device, a ticket submission instruction sent by a user terminal; the ticket submission instruction includes user identification information and user ticket-related information; and to receive ticket verification information sent by the second electronic device; an acquiring unit, configured to determine, based on the type of the ticket submission instruction, a database type corresponding to the ticket submission instruction, and send a ticket verification information acquisition request message to the second electronic device; the ticket verification information acquisition request message includes user identification information and the database type corresponding to the ticket submission instruction, so that the second electronic device determines, based on the user identification information and the database type corresponding to the ticket submission instruction, a target database corresponding to the user terminal, sends the ticket verification information acquisition request message to the target database, and acquires the ticket verification information from the target database; The processing unit is used to verify whether the ticket submission instruction is passed according to the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

10. A data processing device for passenger tickets, characterized in that: The method for executing any one of claims 3 to 7 comprises: A receiving unit, configured for the second electronic device to receive a ticket verification information acquisition request message sent by the first electronic device; the ticket verification information acquisition request message includes user identification information and a database type corresponding to the ticket submission instruction; a processing unit, configured to determine a target database from among the established databases based on the user identification information and the database type corresponding to the ticket submission instruction; and further configured to send the ticket verification information acquisition request message to the target database; wherein the database type corresponding to the ticket submission instruction is determined by the first electronic device based on the type of the ticket submission instruction; The receiving unit is further used to receive the ticket verification information sent by the target data; The processing unit is also used to send the ticket verification information to the first electronic device, so that the first electronic device can verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

11. A data processing device for passenger tickets, characterized in that: The method for executing claim 8 comprises: A receiving unit, configured for the third electronic device to receive a ticket submission instruction sent by a user terminal; the ticket submission instruction includes user identification information; A processing unit, configured to determine a target database corresponding to the user terminal from among the databases with established connections, based on the type of the ticket submission instruction and the user identification information; An acquiring unit, configured to send a ticket verification information acquiring request message to the target database; The receiving unit is further used to receive the ticket verification information sent by the target database; The processing unit is also used to verify whether the ticket submission instruction is passed based on the ticket verification information, and when the verification is passed, generate order information and return the order information to the user terminal.

12. An electronic device, characterized in that: The electronic device comprises a processor and a memory, wherein the memory stores a computer program. When the computer program is executed, the electronic device executes the method according to any one of claims 1 to 2 or any one of claims 3 to 7 or 8.

13. A storage medium, characterized in that: The storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the method according to any one of claims 1-2 or any one of claims 3-7 or 8.

Images