Railway group ticket buying service method and system

Abstract

The invention discloses a railway group ticket buying service system and method. The system comprises a front-end service module, an internet background service module, a passenger ticket network background service module and a storage module. The front-end service module receives and uploads a group user list, executes basic information verification, and initiates a request for querying a binding result of group users and group tickets; the Internet background service module receives and forwards a binding result request; the passenger ticket network background service module receives a binding result request, initiates a group user qualification verification command, creates a group ticket binding group user order, and records a group ticket binding group user order result; and the storage module receives a group ticket binding group user order result and records the group ticket binding group user order result in the database. According to the system disclosed by the invention, the problem of high coupling of each component is solved by a unified processing mode of a background software system, and the problems of service timeout and uncontrollable waiting time are solved.

Description

Technical Field

[0001] This application relates to the field of railway ticketing services, and particularly to a method and system for railway group ticket purchasing services. Background Art

[0002] Currently, a new social group ticket business has been added to railway ticket purchasing, with a purchase limit of several hundred tickets. This means that when handling group business, it is necessary to upload the real-name information of group members one by one for qualification verification. If the mode of individual ticket purchase in railway ticket purchasing is followed, uploading hundreds of people at the same time and conducting verification operations will face timeouts. Therefore, it is necessary to choose an asynchronous approach to implement the batch binding of users, and at the same time use limited service resources to support it to ensure the stability of the business.

[0003] In terms of the business process, the existing group ticket purchasing system mainly includes: binding user upload, adding verified users, asynchronously grouping and binding users through a timed task, judging whether users are expired through a timed task, and synchronizing the status of the log table through a timed task.

[0004] As Figure 1 shown, in terms of the structural composition, the existing railway group ticket purchasing system, the current batch user addition process mainly relies on the cooperation of terminal devices, background software systems, databases, and transmission services. The terminal devices include the group ticket system website of the passenger ticket network, and the background software systems include the group ticket management system, the Internet qualification verification system, the timed task execution system, etc. The databases are mainly SyBase databases and PostgreSQL databases. Figure 1 is the system functional block diagram of the existing railway group ticket batch user addition.

[0005] As Figure 2 shown, in terms of the implementation method, the main process of the existing batch user addition is: the bound users are uploaded to the Internet, verified by Internet personnel, and after verification, the process of user binding is carried out on the passenger ticket network. Figure 2 is the flowchart of the existing batch user addition:

[0006] However, the current batch user addition mechanism has several problems and deficiencies in terms of structure, principle, and method. First of all, the process of batch user addition involves calling the system background program for calculation and storing the results in the database, and this process is serial. This leads to too high a coupling degree between the system background and the database, and subsequent operations must wait for the program calculation to be completed. At the same time, the calculation of a large amount of user data will cause an excessive memory operation burden on a single interface, thus affecting the operation efficiency of the system.

[0007] Secondly, the front-end interface must wait for the background to complete the batch user binding and return a prompt message before it can proceed to the next step, which also results in a too high coupling degree between the background system and the front-end interface. In addition, the timeout period of the existing interface is set to a fixed 5 seconds, which is too tight in terms of time and likely to cause the business process to fail to complete smoothly; due to serial transmission, every time a large number of user binding tasks are encountered, the system may need to wait for up to 5 seconds, resulting in a total waiting time that may become very long and unpredictable. If the front-end does not receive a return result within 5 seconds after sending a download command, it will directly prompt an interface timeout, which makes it impossible for users to know whether the binding is successful.

[0008] In view of the problems and deficiencies in the current process of batch adding users, it is urgent to propose a new group ticket purchasing system and its method to achieve this function with the least resource consumption. To this end, the following technical problems must be solved:

[0009] Firstly, it is necessary to reduce the coupling degree between the front-end, the Internet, the ticket network, and the database, and enhance the independence of the background system, so as to reduce the operating burden of other parts. Secondly, it is also necessary to solve the problem of the uncertainty of the user waiting time and improve the operating efficiency of the system.

[0010] In summary, the current user adding function exposes several problems and deficiencies in terms of structure, working principle, and implementation method, such as too high coupling degree between components, lack of flexibility in timeout settings, and difficulty in controlling the waiting time. Therefore, the parameter download technology of the present invention urgently needs to solve these defects to enhance the stability, controllability, and operating efficiency of the entire system. Summary of the Invention

[0011] To solve the problems of too high coupling degree between components of the above-mentioned group ticket purchasing system, lack of flexibility in timeout settings, and difficulty in controlling the waiting time, a railway group ticket purchasing service method and its system are proposed.

[0012] In a first aspect, an embodiment of the present application provides a railway group ticket purchasing service system, which includes:

[0013] A front-end service module, configured to receive and upload a list of group users, perform basic information verification, and initiate a request to query the binding result of group users and group tickets;

[0014] An Internet background service module, configured to receive and forward the request for the binding result sent by the front-end service module;

[0015] A ticket network background service module, configured to receive the request for the binding result sent by the Internet background module, initiate a group user qualification verification command, create a group ticket binding group user order, and record the result of the group ticket binding group user order;

[0016] A storage module, configured to receive the result of binding group user orders for group tickets sent by the background module of the ticket network and record it in the database.

[0017] In a specific embodiment of the present invention, the above front-end service module is configured to perform steps including:

[0018] Using a scheduled task to poll whether there is input group user data to be bound;

[0019] Receiving the group user data to be bound, performing data compliance upload checks, and uploading the group user data to be bound;

[0020] Processing the binding result request through the background service module of the ticket network, decrypting and then performing data verification. If the verification fails, directly return the result to the front-end service module for display.

[0021] In a specific embodiment of the present invention, the above background service module of the ticket network is configured to perform steps including:

[0022] A user save service, uploading and storing the received batch of bound user data into the log table of the database;

[0023] Periodically querying the batch user service, triggering a background scheduled task at regular intervals, generating a unique random code to identify the background scheduled task, and at the same time updating the relevant data status to in operation and storing the random code in the log table of the database. Only one thread processes the data of the same batch; retrieving the user log table according to the random code to find the user information of the same batch;

[0024] An overtime task service, terminating the task if there is no batch user data to be processed or the task times out;

[0025] A periodic comparison task service, periodically synchronously comparing whether the update status of the log table and the order table is consistent and synchronizing the status of the data in the two tables;

[0026] An asynchronous binding user service, asynchronously grouping and binding users. If it is found that there is batch user data to be bound, the batch user data is grouped and an asynchronous task is called to perform the user binding operation and create order data; the order data is inserted into the order table in batches, the order is activated, and the user log table is updated.

[0027] In a second aspect, an embodiment of the present application provides a method for railway group ticket purchasing service, using the above railway group ticket purchasing service system, and the method includes:

[0028] A front-end service step: receiving and uploading a list of group users through the front-end service module, performing basic information verification, and initiating a request to query the binding result of group users and group tickets;

[0029] Internet background service steps: Receive and forward requests for binding results sent by the front-end service module through the Internet background service module;

[0030] Ticket network background service steps: Receive requests for binding results sent by the Internet background module through the ticket network background service module, initiate a group user qualification verification command, create a group ticket binding group user order, and record the result of the group ticket binding group user order;

[0031] Storage steps: Receive the result of the group ticket binding group user order sent by the ticket network background module through the storage module and record it in the database.

[0032] In a specific embodiment of the present invention, the above front-end service steps include:

[0033] Use a timed task to poll whether there is input group user data to be bound;

[0034] Receive group user data to be bound, perform data compliance upload checks, and upload the user data to be bound;

[0035] Process the binding result request through the ticket network background service module, decrypt it and perform data verification. If the verification fails, directly return the result to the front-end service module for display.

[0036] In a specific embodiment of the present invention, the above ticket network background service steps include:

[0037] User save service steps: Upload the received batch of bound user data to the log table of the database for storage;

[0038] Timed query batch user service steps: Timed trigger a background timed task, generate a unique random code to identify the background timed task, update the relevant data status to in operation at the same time, and store the random code in the log table of the database. Only one thread processes the data of the same batch; Retrieve the user log table according to the random code to find the user information of the same batch;

[0039] Timeout task service steps: If there is no batch user data to be processed or the task times out, terminate the task;

[0040] Timed comparison task service steps: Timed synchronously compare whether the update status of the log table and the order table is consistent, and synchronize the status of the data in the two tables;

[0041] Asynchronous binding user service steps: Asynchronously group and bind users. If it is found that there is batch user data to be bound, group the batch user data and call an asynchronous task to perform user binding operations and create order data; Batch insert the order data into the order table, activate the order, and update the user log table.

[0042] In a specific embodiment of the present invention, the above step of periodically querying batch user services further includes:

[0043] Step of updating log binding time: The background service module of the ticket network finds the data in the personnel log table that exceeds the set time interval from the current time and has not been processed, and updates the unbound data of batch users in the time log table;

[0044] Step of periodically synchronizing status: Perform a synchronization operation between the log table and the order table, query the un-verified order data in the order table for a certain period of time from the current time, query the data in the corresponding log table according to the order data, and compare whether the status of the retrieved data is consistent. If not, modify the status of the log table data and modify the status of the corresponding log table data to the compared status.

[0045] In a specific embodiment of the present invention, the above step of asynchronously binding user services further includes:

[0046] Perform a legality judgment on the input parameters. If legal, obtain ticket data from the ticket backend; otherwise, batch modify the log data and end the processing flow;

[0047] If the ticket data is successfully obtained, then execute the query for the main order data; otherwise, batch modify the log data and end the processing flow;

[0048] If the query for the main order data is successfully executed, then judge whether the main order is operable. If it is operable, then query the remaining times of the main order; if it is not operable, batch modify the log data and end the processing flow;

[0049] If the pre-allocated times of the main order are less than the remaining times, continue to judge whether the same user is bound multiple times under the same main order, and judge whether the user has been bound under the main order. If not bound, then assemble the user sub-order data, including personnel information, sub-order details information, and the validity period of the sub-order;

[0050] Judge whether the assembled data conforms to the blacklist, and continue to judge whether the binding time is within the valid time interval of the main order. If it is within the time interval, then execute the batch assembly and binding of users and group ticket orders;

[0051] Traverse all batch group users, loop through the above steps, create group ticket order data and record the data.

[0052] In a third aspect, an embodiment of the present application provides an electronic device, which includes: a memory storing executable program code; a processor coupled to the memory; the processor calls the executable program code stored in the memory to execute the above-mentioned railway group ticket purchasing service system.

[0053] Fourthly, an embodiment of the present application provides a computer storage medium. The computer storage medium stores computer instructions, which are used to execute the railway group ticket purchasing service system as described above when called.

[0054] Compared with the related prior art, it has the following prominent beneficial effects:

[0055] 1. The method of the present invention proposes a technology for dynamically monitoring batch binding results at the front end. The front-end web page monitors the binding result marks stored in the database by dynamically querying the unique task number, and generates the success or failure results of the bound users to be fed back to the front end for display in the shortest time.

[0056] 2. The method of the present invention proposes a technology for uniquely querying batch user tasks in a timed task. The background timed task executes a query for the operations of the same batch of users every 30s (configurable). The background randomly generates a string of character codes to identify this background service, which is used to ensure that only one thread executes the data of the same batch.

[0057] 3. The method of the present invention proposes an asynchronous grouped user binding technology. For a large number of users, the users are grouped, and the user binding operation judgment is executed asynchronously. After the judgment, the binding results of the users in the database are modified in batches. This increases the utilization rate of the CPU, reduces the operation time of the background tasks, and reduces the waiting time of the users.

[0058] 4. The method of the present invention proposes a technology for synchronously comparing log and order status. The background regularly (configurable) compares the data log table of the bound users and the status of the order table to see if the statuses in the two tables are consistent. If they are not consistent, the statuses of the data in the two tables are synchronized, and it is marked that this piece of data in the two tables has been compared; if they are consistent, the statuses of the data in the two tables are synchronized, indicating that this piece of data has been compared. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation to the present application. In the drawings:

[0060] Figure 1 It is a schematic diagram of the architecture of the prior art railway group ticket purchasing service system;

[0061] Figure 2 It is a schematic diagram of the prior art railway group ticket purchasing service process;

[0062] Figure 3 It is a schematic diagram of the architecture of the railway group ticket purchasing service system of the present invention;

[0063] Figure 4 It is a schematic diagram of the architecture of the railway group ticket purchasing service system in a specific embodiment of the present invention;

[0064] Figure 5 This is a schematic diagram of the method flow for the railway group ticket purchasing service of the present invention;

[0065] Figure 6 This is a schematic diagram of the method flow for the railway group ticket purchasing service in a specific embodiment of the present invention;

[0066] Figure 7 This is a schematic diagram of the background service process for batch binding users in a specific embodiment of the present invention;

[0067] Figure 8 This is a flow chart of the timing task for updating the personnel log table in a specific embodiment of the present invention;

[0068] Figure 9 This is a flow chart of the timing task synchronization status in a specific embodiment of the present invention;

[0069] Figure 10 This is a schematic diagram of the computer hardware of the present invention. Detailed implementation manners

[0070] In order to enable users in the technical field to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0071] In the present invention, terms such as "first" and "second" in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "and / or" in this article is only a relational expression describing associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. Among them, A and B may be singular or plural. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after, but it may also represent an "and / or" relationship. Specifically, it can be understood by referring to the context before and after.

[0072] In the present invention, "at least one" means one or more, and "a plurality" means two or more. "At least one of the following" or its similar expressions refer to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c may represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, and c may be single or multiple.

[0073] It should also be understood that in various embodiments of the present invention, the magnitudes of the sequence numbers of the above processes do not imply the order of execution, and the order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0074] In several embodiments provided by the present invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0075] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0076] In addition, in each embodiment of the present invention, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0077] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs, etc., which can store program codes.

[0078] To make the above features and effects of the present invention more clearly and understandably described, specific embodiments are hereinafter given and will be described in detail in conjunction with the accompanying drawings of the specification. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are only for illustrative purposes. The scope of protection of the present invention is not limited to the disclosed embodiments, and the present invention is defined by the appended claims.

[0079] The following is a system embodiment corresponding to the above method embodiment. This embodiment can be implemented in cooperation with the above embodiment. The relevant technical details mentioned in the above embodiment are still valid in this embodiment. To avoid repetition, they will not be elaborated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiment.

[0080] The present invention aims to provide a railway group ticket purchasing service system and its method. The technology of the present invention abandons the traditional mode of calling each component one by one and waiting for its return result, and instead adopts an architecture with the background software system as the core. Under this architecture, each component independently completes tasks and records results, which are then uniformly processed by the background software system. This change effectively reduces the coupling degree between components and, on this basis, solves the problems of business processing timeout and uncontrollable waiting time, significantly improving the stability, controllability, and operating efficiency of the entire system.

[0081] Embodiment 1

[0082] Please refer to Figure 3 and Figure 4 , Figure 3 which is a railway group ticket purchasing service system according to an embodiment of the present invention. As shown in Figure 3 , the present invention proposes a method for binding a batch of users by a railway group service system, allowing ticket purchasing users to use an uploaded template to batch bind one or more user users to the group ticket order they purchased. The system function box is as shown in Figure 3 . The implementation process of the system functions of the present invention involves the collaborative work of the front-end service module 101, the Internet background service module 102, the passenger ticket network background service module 103, and the storage module 104. The front-end mainly undertakes the responsibility of receiving and uploading the list of personnel, performing basic information verification, and is responsible for initiating a request to query the binding result and displaying these results. The Internet background software system acts as an intermediary for transmitting the bound personnel information, while the passenger ticket network background software system is responsible for initiating a personnel qualification verification command, creating a group ticket bound personnel order, and recording the result in the database. The role of the database is to store data tables.

[0083] Specifically, as shown in Figure 4 , the front-end service module 101 is used to receive and upload the list of group users, perform basic information verification, and initiate a request to query the binding result of group users and group tickets;

[0084] The Internet background service module 102 is used to receive and forward the request for the binding result sent by the front-end service module;

[0085] The ticket network background service module 103 is used to receive the request for the binding result sent by the Internet background module, initiate a group user qualification verification command, create a group ticket binding group user order, and record the result of the group ticket binding group user order;

[0086] The storage module 104 is used to receive the result of the group ticket binding group user order sent by the ticket network background module and record it in the database.

[0087] In a specific embodiment of the present invention, the above front-end service module 101 is configured to perform steps including:

[0088] Use a timing task to poll whether there is input group user data to be bound;

[0089] Receive the group user data to be bound, perform data compliance upload inspection, and upload the user data to be bound;

[0090] Process the binding result request through the ticket network background service module, decrypt it and perform data verification. If the verification fails, directly return the result to the front-end service module for display.

[0091] In a specific embodiment of the present invention, the above ticket network background service module 103 is configured to perform steps including:

[0092] User save service, upload the received batch of bound user data to the log table of the database for storage;

[0093] Timing query batch user service, timing trigger a background timing task, generate a unique random code to identify the background timing task, at the same time update the relevant data status to in operation, and store the random code in the log table of the database. Only one thread processes the data of the same batch; retrieve the user log table according to the random code to find the user information of the same batch;

[0094] Timeout task service, if there is no batch user data to be processed or the task times out, terminate the task;

[0095] Timing comparison task service, timing synchronously compare whether the update status of the log table and the order table is consistent, and synchronize the status of the data in the two tables;

[0096] Asynchronous binding user service, asynchronously group-bind users. If it is found that there is batch user data to be bound, group the batch user data and call an asynchronous task to perform the user binding operation and create order data; batch insert the order data into the order table, activate the order, and update the user log table.

[0097] Example 2

[0098] As Figure 5 shown, an embodiment of the present application provides a method for railway group ticket purchasing service, using the railway group ticket purchasing service system as described above. Figure 5 The process of bulk uploading users of the present invention is presented, and the uploading steps are described in detail: First, upload the entire EXCEL file of bulk-bound users on the front-end page, and the page will immediately display the list of users to be uploaded; then, forward the request to the ticket network back-end service for processing through the Internet back-end service. After the request is decrypted, data verification is performed. If the verification fails, the result is directly returned to the front-end for display. After the verification passes, the system will query the personnel qualification form to confirm whether the personnel have passed the qualification verification, record the personnel verification mark, and store it in the personnel log form. After the record is completed, the result is sent to the front-end and displayed to the user by the front-end.

[0099] During the process of bulk uploading users, all the data required by the back-end uploading service can be obtained by querying the database. This service focuses on processing user uploads, ensuring that the number of users uploaded by the back-end service is controllable, and can return the response result to the front-end for display within the specified time. In addition, the number of uploaded users and the waiting time can also be flexibly set according to needs.

[0100] Specifically, as Figure 6 shown, the method of the present invention includes:

[0101] Front-end service step 201: Receive and upload the list of group users through the front-end service module, perform basic information verification, and initiate a request to query the binding result of group users and group tickets;

[0102] Internet back-end service step 202: Receive and forward the request for the binding result sent by the front-end service module through the Internet back-end service module;

[0103] Ticket network back-end service step 203: Receive the request for the binding result sent by the Internet back-end module through the ticket network back-end service module, initiate a group user qualification verification command, create a group ticket binding group user order, and record the result of the group ticket binding group user order;

[0104] Storage step 204: Receive the result of the group ticket binding group user order sent by the ticket network back-end module through the storage module and record it in the database.

[0105] In a specific embodiment of the present invention, the above front-end service step 201 includes:

[0106] Use a timed task to poll whether there is input data of group users to be bound;

[0107] Receive the data of group users to be bound, perform data compliance upload checks, and upload the data of users to be bound;

[0108] Process the binding result request through the background service module of the ticket network, decrypt it and perform data verification. If the verification fails, directly return the result to the front-end service module for display.

[0109] As Figure 7 shown, Figure 7 The figure shows the background service process for batch binding users of the present invention. In a specific embodiment of the present invention, the above-mentioned background service step 203 of the ticket network includes the following steps: The background task is triggered regularly, a unique random code is generated to identify this service, and at the same time, the relevant data status is updated to in operation, and the random code is stored in the database to ensure that only one thread processes the data of the same batch. Subsequently, the personnel log table is retrieved according to the random code to find the user information of the same batch. If there is no user data to be processed, the task is terminated; if user data to be bound is found, these data are grouped, and an asynchronous task is called to perform the user binding operation and create order data. Then, the order data is inserted into the order table in batches, the order is activated, and the personnel log table is updated. Thus, this regular task is successfully completed.

[0110] In the process of the background service for batch binding users, this service only responsible for batch binding users, decoupled from the front-end and the Internet background. The front-end does not need to wait for the background to return the binding result of users. The method of modifying first and then querying ensures that only one thread executes the data of the same batch. Grouping the queried users and executing them asynchronously reduces the execution time of binding users and improves the code efficiency. The execution time of the regular task can also be set flexibly.

[0111] Specifically, the above-mentioned background service step 203 of the ticket network includes:

[0112] User saving service step: Upload and store the received batch binding user data into the log table of the database;

[0113] Regular query of batch user service step: Regularly trigger the background regular task, generate a unique random code to identify the background regular task, and at the same time, update the relevant data status to in operation, and store the random code in the log table of the database. Only one thread processes the data of the same batch; Retrieve the user log table according to the random code to find the user information of the same batch;

[0114] Timeout task service step: If there is no batch user data to be processed or the task times out, the task is terminated;

[0115] Regular comparison task service step: Regularly synchronously compare whether the update status of the log table and the order table is consistent, and synchronize the status of the data in the two tables;

[0116] Steps of Asynchronous Binding User Service: Asynchronously group and bind users. If there is batch user data to be bound, group the batch user data and call an asynchronous task to perform the user binding operation and create order data; batch insert the order data into the order table, activate the order, and update the user log table.

[0117] In a specific embodiment of the present invention, the above-mentioned step of periodically querying batch user service further includes:

[0118] Step of Updating Log Binding Time: The back-end service module of the ticket network finds the data in the personnel log table that exceeds the set time interval from the current time and has not been processed, and updates the data of unbound batch users in the time log table;

[0119] Step of Periodically Synchronizing Status: Perform the synchronization operation between the log table and the order table, query the un-verified order data in the order table for a certain period of time from the current time, query the data in the corresponding log table according to the order data, and compare whether the status of the retrieved data is consistent. If not, modify the status of the log table data and modify the status of the corresponding log table data to the status of having been compared.

[0120] As Figure 8 shown, the process of the present invention for updating the personnel log table timing task clearly presents its execution steps: The background timing task is executed once according to the set period (customizable), responsible for checking whether the data in the personnel log table is expired. Subsequently, the background task will update the data in the personnel log table that exceeds 8 minutes from the current time and has not been processed, and adjust its status accordingly.

[0121] When executing the process of updating the personnel log table timing task, the service is specifically responsible for the timing task of updating the personnel log table, achieving decoupling from the front end and the Internet background. This means that the front end does not need to wait for the background to return the user binding result. This task ensures the accuracy and relevance of the data, effectively preventing the phenomenon of data accumulation. At the same time, the execution time and timeout time of the timing task can be flexibly configured according to needs.

[0122] As Figure 9 shown, the flowchart of the present invention for synchronizing status of timing tasks shows the steps of the timing task for synchronizing the personnel log table and the order table: The background timing task is executed periodically once (configurable) to perform the operation of synchronizing the personnel log table and the order table, query the un-verified order data in the order table for a certain period of time from the current time, query the user data in the corresponding log table according to the order data, compare whether the status of the user data retrieved from the order table and the log table is consistent. If not, based on the order table, modify the status of the user data in the log table to be consistent with the data status in the order table. Finally, modify the data status of the user flag in the order table from the un-compared status to the compared status.

[0123] In the process of synchronizing the status of scheduled tasks, this service is only responsible for synchronizing the status of database data. This task ensures data consistency and relevance, and improves data reliability. The execution time and comparison time interval of scheduled tasks can also be flexibly set.

[0124] In a specific embodiment of the present invention, the above asynchronous binding user service step further includes:

[0125] Perform a legality judgment on the input parameters. If legal, obtain ticket data from the ticket backend; otherwise, batch modify the log data and end the processing flow.

[0126] If the ticket data is successfully obtained, execute the query for the main order data; otherwise, batch modify the log data and end the processing flow.

[0127] If the query for the main order data is successfully executed, determine whether the main order is operable. If it is operable, query the remaining times of the main order; if it is not operable, batch modify the log data and end the processing flow.

[0128] If the pre-allocated times of the main order are less than the remaining times, continue to determine whether the same user is bound multiple times under the same main order, and determine whether the user has been bound under the main order. If not bound, assemble the user sub-order data, including personnel information (such as name, ID number, etc.), sub-order details information, and sub-order validity period, etc.

[0129] For the assembled data, determine whether it conforms to the blacklist, and continue to determine whether the binding time is within the valid time range of the main order. If it is within the time range, execute the batch assembly and binding of users and group ticket orders.

[0130] Traverse all batches of group users, loop through the above steps, create group ticket order data and record the data.

[0131] In summary, the key technologies included in the present invention compared with the existing batch user addition technologies are:

[0132] Front-end dynamic monitoring of batch binding results technology. The front-end web page monitors the binding result flag stored in the database by dynamically querying the unique task number, and generates the success or failure result of binding the user to the front-end display in the shortest time.

[0133] Unique query for batch user tasks in scheduled tasks technology. The background scheduled task executes a query for the same batch of user operations every 30s (configurable). The background randomly generates a string of character codes to identify this background service, which is used to ensure that only one thread executes the same batch of data.

[0134] Asynchronous grouped user binding technology. For a large number of users, the users are grouped, and the user binding operation judgment is performed asynchronously. After the judgment, the user binding results in the database are modified in batches. This increases the utilization rate of the CPU, reduces the operation time of background tasks, and reduces the waiting time of users.

[0135] Synchronous comparison of log and order status technology. The background regularly (configurable) compares the data log table of bound users and the status of the order table to see if the statuses in the two tables are consistent. If they are not consistent, the statuses of the data in the two tables are synchronized, and it is marked that this piece of data in the two tables has been compared; if they are consistent, the statuses of the data in the two tables are synchronized, indicating that this piece of data has been compared.

[0136] The main innovation of the batch user addition technology of the present invention compared with the existing batch user addition is as follows:

[0137] The batch user addition technology of the present invention can meet the user information addition of up to 500 people at the same time, meeting the group ticket business requirements of the present invention.

[0138] Decouple the front end, Internet background service, and ticket network background service, improve the autonomy of the background service, and the front end no longer depends on the real-time return results of the background service.

[0139] First mark the unique batch of users in the background, and then query the batch of users. This ensures the binding requirements of a single user in the business. At the same time, multiple tasks can process the user binding operation, improving the utilization rate of IO and the task processing efficiency.

[0140] Asynchronously group and process a large number of users, improving the utilization rate of the CPU, reducing the waiting time for user binding operations, and improving the task processing efficiency.

[0141] Synchronous operations reduce the task error rate and improve the fault tolerance and reliability of the system.

[0142] The execution times and execution intervals of the scheduled tasks can be set, which makes the waiting time for the batch user addition result the shortest and the total timeout waiting time for batch user addition failure controllable.

[0143] At the same time, the advantages of the present invention compared with the prior art include:

[0144] Lower database load pressure: By using batch query to modify database data, the pressure on the database is reduced, the IO overhead is reduced, and space is reserved for future higher access requirements. For example, stronger load capacity can be achieved through redis.

[0145] The background service has stronger autonomy: Asynchronous addition and binding of a large number of users are used to decouple the dependence between the background service and the front end, enabling the front end to not rely on the real-time return results of the background service, thus improving the flexibility and controllability of the system.

[0146] The shortest user waiting time and high controllability: The front-end page service dynamically queries the binding result markers, and both the query times and the query interval can be flexibly set, resulting in the shortest user waiting time and greatly improving the controllability of the timeout waiting time in case of binding failure.

[0147] Higher execution efficiency: The operation of batch-binding users transmits user data to the background task through asynchronous grouped operations, which not only speeds up the data binding process but also reduces the total timeout waiting time in case of unsuccessful transmission, greatly enhancing the overall operation efficiency and speed.

[0148] Synchronous comparison mechanism: Compare the data status of order data and log data and make marks, which improves the reliability of the user-binding operation, as well as the reliability and fault tolerance of the system.

[0149] Embodiment III

[0150] The embodiment of the present application provides an electronic device, as Figure 10 shown, the device includes: a memory storing executable program code; a processor coupled to the memory; the processor calls the executable program code stored in the memory to execute the method of the railway group ticket-purchasing service as described above.

[0151] Embodiment IV

[0152] The embodiment of the present application provides a computer storage medium, the computer storage medium stores computer instructions, and when the computer instructions are called, they are used to execute the railway group ticket-purchasing service method as described above.

[0153] In addition, the railway group ticket-purchasing service system described in combination with Figure 1 the embodiments of the present application can be implemented by a computer device. Figure 10 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present application.

[0154] In some of these embodiments, the computer device may further include a communication interface 83 and a bus 80. Among them, as Figure 10 shown, the processor 81, the memory 82, and the communication interface 83 are connected through the bus 80 to complete mutual communication.

[0155] Specifically, the above-mentioned processor 81 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured as one or more integrated circuits for implementing the embodiments of the present application.

[0156] The memory 82 can be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 81.

[0157] The processor 81 reads and executes the computer program instructions stored in the memory 82 to implement any one of the railway group ticket purchasing service systems in the above embodiments.

[0158] In summary, the batch binding user technology proposed by the present invention improves the performance, controllability, stability and efficiency of the system by using database intermediate tables, uniquely querying batch users, asynchronously grouping and binding user technology, improving the autonomy and flexibility of background services, and synchronizing logs, order status, etc.

[0159] In short, the outstanding effect of the batch binding user technology of the present invention is that after the user initiates the operation of binding users on the front-end page, regardless of whether there is individual user data binding timeout or whether all user data is successfully bound, the user can receive the feedback of the binding result within the shortest time and clearly know which user data is successfully bound; thus, even if individual user data binding fails and causes a long timeout, there will no longer be a situation where the front-end prompts binding timeout as before, but the binding result will be seen within a certain time, greatly improving the user experience.

[0160] In summary, the batch binding user technology improves the performance, controllability, stability and efficiency of the system significantly by adopting database intermediate tables, uniquely querying batch users, asynchronously grouping and binding user technology, enhancing the autonomy and flexibility of background services, and synchronizing logs, order status, etc.

[0161] In short, the significant advantage of the new batch binding user technology is that when the user initiates the operation of binding users on the front-end page, regardless of whether there is individual user data binding timeout or whether all user data is successfully bound, the user can obtain the feedback of the binding result within the shortest time and clearly know which user data has been successfully bound. Therefore, even if some user data binding fails and causes a timeout, there will no longer be a front-end prompt of binding timeout as before, but the binding result will be displayed within a certain time, greatly improving the user experience.

[0162] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0163] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A railway group ticket purchasing service system, characterized in that, The system includes: A front-end service module, which is used to receive and upload the list of group users, perform basic information verification, and initiate a request to query the binding result between the group users and group tickets; An Internet background service module, which is used to receive and forward the request for the binding result sent by the front-end service module; A ticket network background service module, which is used to receive the request for the binding result sent by the Internet background module, initiate the qualification verification command for the group users, create a group ticket binding group user order, and record the result of the group ticket binding group user order; A storage module, which is used to receive the result of the group ticket binding group user order sent by the ticket network background module and record it in the database.

2. The railway group ticket purchasing service system according to claim 1, wherein The front-end service module is configured to perform steps including: Using a scheduled task to poll whether there is input data of group users to be bound; Receiving the data of the group users to be bound, performing data compliance upload inspection, and uploading the data of the group users to be bound; Processing the binding result request through the ticket network background service module, decrypting and then performing data verification, and directly returning the result to the front-end service module for display if the verification fails.

3. The railway group ticket purchasing service system according to claim 1, wherein The ticket network background service module is configured to perform steps including: A user save service, which uploads and stores the received batch of bound user data in the log table of the database; A scheduled query batch user service, which triggers a background scheduled task at regular intervals, generates a unique random code to identify the background scheduled task, updates the relevant data status to in operation at the same time, and stores the random code in the log table of the database. Only one thread processes the data of the same batch; retrieving the user log table according to the random code to find the user information of the same batch; An overtime task service, which terminates the task if there is no batch user data to be processed or the task times out; A scheduled comparison task service, which synchronously compares at regular intervals whether the update status of the log table and the order table is consistent and synchronizes the status of the data in the two tables; An asynchronous binding user service, which asynchronously groups and binds users. If it is found that there is batch user data to be bound, the batch user data is grouped, and an asynchronous task is called to perform the user binding operation and create order data; the order data is batch inserted into the order table, the order is activated, and the user log table is updated.

4. A method for railway group ticket purchasing service, which adopts the railway group ticket purchasing service system described in any one of claims 1-3, characterized in that, The method includes: A front-end service step: receiving and uploading the list of group users through the front-end service module, performing basic information verification, and initiating a request to query the binding result between the group users and group tickets; An Internet background service step: receiving and forwarding the request for the binding result sent by the front-end service module through the Internet background service module; A ticket network background service step: receiving the request for the binding result sent by the Internet background module through the ticket network background service module, initiating the qualification verification command for the group users, creating a group ticket binding group user order, and recording the result of the group ticket binding group user order; A storage step: receiving the result of the group ticket binding group user order sent by the ticket network background module through the storage module and recording it in the database.

5. The method for railway group ticket purchasing service according to claim 4, wherein The front-end service step includes: Use a timed task to poll whether there is input data of group users to be bound; Receive the data of group users to be bound, conduct a data compliance upload check, and upload the data of users to be bound; Process the binding result request through the background service module of the ticket network, decrypt it and perform data verification. If the verification fails, directly return the result to the front-end service module for display.

6. The railway group ticket purchasing service method according to claim 4, wherein The background service steps of the ticket network include: User save service step: Upload and store the received batch of bound user data into the log table of the database; Timed query batch user service step: Timely trigger a background timed task, generate a unique random code to identify the background timed task, and at the same time update the relevant data status to in operation, and store the random code in the log table of the database. Only one thread processes the data of the same batch; Retrieve the user log table according to the random code to find the user information of the same batch; Timeout task service step: If there is no batch user data to be processed or the task times out, terminate the task; Timed comparison task service step: Timely synchronize and compare whether the update status of the log table and the order table is consistent, and synchronize the status of the data in the two tables; Asynchronous user binding service step: Asynchronously group and bind users. If it is found that there is batch user data to be bound, group the batch user data and call an asynchronous task to perform user binding operations and create order data; Batch insert the order data into the order table, activate the order, and update the user log table.

7. The method for railway group ticket purchasing service according to claim 4, wherein The timed query batch user service step also includes: Update log binding time step: The background service module of the ticket network finds the data in the personnel log table that has not been processed and exceeds the set time interval from the current time, and updates the data of the batch users not bound in the time log table; Timed synchronization status step: Execute the synchronization operation of the log table and the order table, query the un-verified order data in the order table for a certain period of time from the current time, query the data in the corresponding log table according to the order data, and compare whether the status of the retrieved data is consistent. If not, modify the status of the log table data and modify the status of the corresponding log table data to the compared status.

8. The method for railway group ticket purchasing service according to claim 4, wherein The asynchronous user binding service step also includes: Perform a legality judgment on the input parameters. If legal, obtain ticket data from the ticket background, otherwise batch modify the log data and end the processing flow; If the ticket data is successfully obtained, execute the query for the main order data, otherwise batch modify the log data and end the processing flow; If the query for the main order data is successfully executed, judge whether the main order is operable. If it is operable, query the remaining times of the main order; If it is not operable, batch modify the log data and end the processing flow; If the pre-allocated times of the main order are less than the remaining times, continue to judge whether the same user is bound multiple times under the same main order, and judge whether the user has been bound under the main order. If not, assemble the user sub-order data, including personnel information, sub-order details information, and the validity period of the sub-order; For the assembled data, determine whether it conforms to the blacklist, and continue to determine whether the binding time is within the valid time range of the main order. If it is within the time range, execute the assembly and binding of batch users and group ticket orders; Traverse all batches of group users, loop through the above steps, create group ticket order data, and record the data.

9. An electronic device, characterized in that, The device includes: a memory storing executable program code; a processor coupled to the memory; the processor calls the executable program code stored in the memory to execute the railway group ticket purchasing service method according to any one of claims 4-8.

10. A computer storage medium, characterized in that, The computer storage medium stores computer instructions, which are used to execute the railway group ticket purchasing service method according to any one of claims 4-8 when the computer instructions are called.

Images