A passenger flow adaptive overbooking control system and control method

Abstract

This invention belongs to the field of ticket overbooking control technology, and proposes a route overbooking control system and method based on passenger flow adaptation. The main scheme is as follows: The source type of ticket query and purchase instructions is obtained through a virtual query and ticketing terminal, and automated query and purchase instructions are generated; the automated query instructions and user query instructions are received through a ticket query server, and it is determined whether the user query instructions match. If they match, the query result information is sent to the client in response to the user query instructions; the first ticketing server is checked in real time to see if it has reached a load-balanced state. If it has, the second ticketing server is notified; the second ticketing server activates the route ticket overbooking control rules and receives user purchase instructions in real time, and based on the route ticket overbooking control rules, responds to the user purchase instructions by sending available vehicle information and available seat information to the client.

Description

Technical Field

[0001] This invention relates to the field of ticket overbooking control technology, and in particular to a route overbooking control system and control method based on passenger flow adaptive control. Background Technology

[0002] Currently, in the road passenger transport business, there is a common problem of unstable passenger flow on certain routes. That is, the passenger flow on some routes changes irregularly and cannot meet passenger demand through regular scheduling (pre-setting available ticket information for each route).

[0003] Furthermore, the current bus route operation system has the following mechanisms:

[0004] Pre-scheduling system: All trips need to be scheduled in advance to determine the total number of tickets available for sale. If there are few passengers, there may be one person per vehicle (fulfilling the contract will result in losses, and non-fulfillment will lead to complaints and compensation). If there are many passengers, there may be a situation where the tickets are sold out, but the operation cannot determine whether there is enough demand to meet the additional capacity (after adding additional capacity, there may be very few people continuing to buy tickets, similar to one person per vehicle).

[0005] The fixed mechanism of passenger transport service contract model: select a schedule -> place an order -> pay -> issue an order -> fulfill the contract. Once the order is issued, the service contract is completed. At this time, the passenger's expectation is that there will definitely be a vehicle service. When transportation losses occur and it is necessary to cancel the dispatch of transportation capacity, it is difficult to reach an agreement with the passenger to cancel the contract, which requires a considerable amount of communication costs with the passenger.

[0006] No waitlist mechanism: During holidays / Spring Festival travel rush / summer travel peaks, when the pre-scheduled train tickets are sold out, the system will only show that the train is sold out. Passengers who still need to travel cannot register their needs, nor can they predict whether the operator will increase the capacity, which will cause the operator to miss out on customers.

[0007] In the current bus route operation system, especially for those without a waiting list mechanism, there may be periods of high passenger flow, leading to frequent ticket inquiries and purchases. This can cause the server to receive a large number of concurrent requests in a short period, resulting in delays, lag, or data loss on the query, order, or payment interfaces. This can impact operations and user travel. Furthermore, when a large number of concurrent requests occur, the variety of client types associated with the server—for example, ticketing servers often rely on a single authentication method such as phone number verification, real-name authentication, or biometric authentication to ensure rapid ticket issuance—significantly reduces the difficulty of malicious intrusion, increasing the burden on the ticketing server and potentially causing it to crash. Summary of the Invention

[0008] The purpose of this invention is to provide a passenger flow adaptive overbooking control system and method for bus routes, which can adaptively control the overbooking of bus routes based on passenger flow conditions, and can ensure the security of the ticket query server and the ticket server.

[0009] The technical solution adopted by this invention to solve its technical problem is as follows:

[0010] On the one hand, the present invention provides a route overbooking control system based on passenger flow adaptation, including:

[0011] The virtual query and ticket purchase terminal is used to obtain the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server, generate automated query instructions and automated ticket purchase instructions corresponding to the source type, and send the automated query instructions to the ticket query server and the automated ticket purchase instructions to the first ticket server.

[0012] The ticket query server stores the source types of ticket query instructions. It is used to receive automated query instructions and user query instructions, and to determine whether the user query instruction matches the automated query instruction. If it matches, it responds to the user query instruction and sends the query result information to the client.

[0013] The first ticketing server stores the source type of ticket purchase instructions and is used to determine in real time whether the first ticketing server has reached a load balancing state. When it has not reached a load balancing state, it receives automated ticket purchase instructions and user ticket purchase instructions, and determines whether the user ticket purchase instructions match based on the automated ticket purchase instructions. When they match, it responds to the user ticket purchase instructions and sends the remaining seat information of the pre-arranged train to the client. When the load balancing is achieved, it notifies the second ticketing server.

[0014] The second ticketing server stores the overbooking control rules for scheduled bus routes. When it receives a notification from the first ticketing server, it activates the overbooking control rules for scheduled bus routes and receives user ticket purchase instructions in real time. Based on the overbooking control rules for scheduled bus routes, it responds to user ticket purchase instructions by sending available vehicle information and available seat information to the client.

[0015] As a further optimization, in the virtual query and ticket purchase terminal, the automated query instruction is an instruction used to simulate a user's ticket query behavior, and the automated ticket purchase instruction is an instruction used to simulate a user's ticket purchase behavior.

[0016] As a further optimization, before obtaining the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server, the virtual query and ticket purchase terminal further includes:

[0017] Establish a first receiving thread between the virtual query and ticket purchase terminal and the ticket query server, and establish a second receiving thread between the virtual query and ticket purchase terminal and the first ticket server;

[0018] The virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread and the source type of the ticket purchase instruction through the second receiving thread.

[0019] As a further optimization, after the virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread, it also includes:

[0020] A first sending thread and a third receiving thread are established between the virtual query and ticket purchase terminal and the ticket query server. The first sending thread sends the automated query instruction corresponding to the source type to the ticket query server. When the ticket query server responds to the user's query instruction, the third receiving thread receives the query result information.

[0021] After the virtual query and ticket purchase terminal receives the source type of the ticket purchase instruction through the second receiving thread, it also includes:

[0022] A second sending thread and a fourth receiving thread are established between the virtual query and ticket purchase terminal and the first ticketing server. The second sending thread sends the automated ticket purchase instruction corresponding to the source type to the first ticketing server. When the first ticketing server responds to the user's ticket purchase instruction, the fourth receiving thread receives the remaining seat information of the pre-scheduled train.

[0023] As a further optimization, the query results and remaining seat information for pre-scheduled trains received in the virtual query and ticketing terminal are set to be read only via hardware access.

[0024] As a further optimization, when the source type of the ticket query instructions stored in the ticket query server is updated, it includes:

[0025] The source type of the ticket query command to be updated is cached, and it is determined whether the ticket query server has reached a load balance state. If it has not reached a load balance state, the source type of the cached ticket query command is sent to the virtual query and ticket purchase terminal.

[0026] When the virtual query and ticket purchase terminal generates an automated query instruction corresponding to the source type and sends it to the ticket query server, it will again determine whether the ticket query server has reached a load balance state. If it has not, the source type of the ticket query instruction to be updated will be updated.

[0027] As a further optimization, the ticket query server determines whether a user's query command matches the automated query command, which means:

[0028] Obtain the source of the user's query instruction and determine whether it belongs to the source type of the ticket query instruction corresponding to the current automated query instruction. If it does, then the user's query instruction is considered to match.

[0029] As a further optimization, when the first ticketing server reaches a load-balanced state, the following also applies:

[0030] The first ticketing server notifies the virtual query and ticketing terminal to stop generating automated ticketing instructions.

[0031] As a further optimization, the overbooking control rules for scheduled bus routes stored in the second ticketing server refer to:

[0032] Before the second ticketing server receives the notification from the first ticketing server:

[0033] Set up an initial oversold pool, and set the number, type, and number of seats of oversold vehicles based on the initial oversold pool;

[0034] Obtain the remaining seat information for the pre-scheduled train from the first ticketing server, and determine whether the corresponding order has been placed and paid for.

[0035] If completed, the remaining seats for the corresponding pre-scheduled train will be locked, and when the second ticketing server receives a user's ticket purchase instruction, the order will be directly allocated to the initial overbooking pool and marked as an overbooking order.

[0036] Otherwise, the remaining seats of the pre-scheduled trains corresponding to orders that have not completed the order placement and payment process will be released. When the second ticketing server receives a user's ticket purchase instruction, it will allocate the order to the remaining seats of the pre-scheduled trains according to the order time from earliest to latest and mark the order as a normal order. When the tickets corresponding to the remaining seats of the pre-scheduled trains are sold out, the order will be allocated to the initial oversold pool and marked as an oversold order.

[0037] Set all oversold orders to waitlist status, obtain the payment time of oversold orders in waitlist status, and adjust the initial oversold pool based on the payment time.

[0038] On the other hand, the present invention also provides a route overbooking control method based on passenger flow adaptation, which is applied to a route overbooking control system based on passenger flow adaptation, and includes the following steps:

[0039] Configure a virtual query and ticket purchase terminal, a ticket query server, a first ticket server, and a second ticket server. Store the source type of ticket query instructions on the ticket query server, the source type of ticket purchase instructions on the first ticket server, and the overbooking control rules for bus routes on the second ticket server.

[0040] The system obtains the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server through the virtual query and ticket purchase terminal, generates automated query instructions and automated ticket purchase instructions corresponding to the source types, and sends the automated query instructions to the ticket query server and the automated ticket purchase instructions to the first ticket server.

[0041] The system receives automated query commands and user query commands through the ticket query server, and determines whether the user query command matches the automated query command. If they match, the system responds to the user query command by sending the query result information to the client.

[0042] The system continuously checks whether the first ticketing server has reached a load-balanced state. If it has not, it receives automated ticketing instructions and user ticketing instructions, and determines whether the user ticketing instructions match based on the automated ticketing instructions. If they match, it responds to the user ticketing instructions and sends the remaining seat information of the pre-arranged train to the client. If the system reaches a load balanced state, it notifies the second ticketing server.

[0043] Upon receiving a notification from the first ticketing server via the second ticketing server, the overbooking control rules for scheduled bus routes are activated, and user purchase instructions are received in real time. Based on the overbooking control rules for scheduled bus routes, in response to user purchase instructions, available vehicle information and available seat information are sent to the client.

[0044] The beneficial effects of this invention are as follows: Compared with traditional ticket inquiry and sales systems, this invention adds a virtual inquiry and purchase terminal, and generates automated inquiry and purchase instructions corresponding to the source type through the virtual inquiry and purchase terminal. Throughout the ticket inquiry process, not only is the ticket inquiry function unaffected by passenger volume, but it also ensures the security of the ticket inquiry server when passenger volume is high and inquiry requests are frequent in a short period of time, through the combined effect of automated inquiry instructions and the source type of the ticket inquiry instructions. Furthermore, because this invention includes a first ticket server and a second ticket server, it can respond to user purchase requests faster and more securely when passenger volume is low and purchase requests are few. It can also respond with more timely and accurate vehicle and seat information when passenger volume is high and purchase requests are frequent in a short period of time, while still being able to control overbooking. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the system composition of the passenger flow adaptive overbooking control system in Embodiment 1 of the present invention;

[0046] Figure 2 This is a flowchart of the route overbooking control method based on passenger flow adaptation in Embodiment 2 of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0048] Example 1

[0049] See Figure 1 This embodiment provides a passenger flow adaptive overbooking control system for scheduled bus routes, which mainly includes:

[0050] The virtual query and ticket purchase terminal is used to obtain the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server, generate automated query instructions and automated ticket purchase instructions corresponding to the source type, and send the automated query instructions to the ticket query server and the automated ticket purchase instructions to the first ticket server.

[0051] The ticket query server stores the source types of ticket query instructions. It is used to receive automated query instructions and user query instructions, and to determine whether the user query instruction matches the automated query instruction. If it matches, it responds to the user query instruction and sends the query result information to the client.

[0052] The first ticketing server stores the source type of ticket purchase instructions and is used to determine in real time whether the first ticketing server has reached a load balancing state. When it has not reached a load balancing state, it receives automated ticket purchase instructions and user ticket purchase instructions, and determines whether the user ticket purchase instructions match based on the automated ticket purchase instructions. When they match, it responds to the user ticket purchase instructions and sends the remaining seat information of the pre-arranged train to the client. When the load balancing is achieved, it notifies the second ticketing server.

[0053] The second ticketing server stores the overbooking control rules for scheduled bus routes. When it receives a notification from the first ticketing server, it activates the overbooking control rules for scheduled bus routes and receives user ticket purchase instructions in real time. Based on the overbooking control rules for scheduled bus routes, it responds to user ticket purchase instructions by sending available vehicle information and available seat information to the client.

[0054] In this embodiment, the client can be a smartphone, computer, or other smart device. As long as it can be adapted to the ticket query, purchase, and payment operations, and can be adapted to the ticket query server, the first ticket server, and the second ticket server in this embodiment, the corresponding client can be regarded as a legitimate client.

[0055] In practical applications, based on current user habits for checking and purchasing tickets, smartphones and computers are the most common clients. However, for established clients like computers, users can download the corresponding application (APP) and log in within the APP to complete ticket checking and purchasing operations. Some users may also choose to use a browser to directly check and purchase tickets through a webpage. For users who choose to use a browser to directly check and purchase tickets through a webpage, in order to respond to user requests more quickly, many query operations do not even require account login, which greatly reduces the security of the ticket request server. In this case, to improve security, if users are required to register or log in for each query, the registration or login page may not be able to respond in time under high traffic and high concurrency requests, thus affecting the user's query experience.

[0056] Therefore, to facilitate user ticket inquiries and protect the ticket inquiry server from malicious intrusion, this embodiment adds a virtual inquiry and ticket purchase terminal. Furthermore, the ticket inquiry server does not require users to log in to complete the inquiry. As long as the source type of the ticket inquiry command is legitimate, an automated inquiry command can be generated through the virtual inquiry and ticket purchase terminal. This automated inquiry command then assists in the security verification of the user's inquiry command. Here, the automated inquiry command is used to simulate user ticket inquiry behavior, and the generated automated inquiry command must correspond to the source type of the ticket inquiry command.

[0057] For situations with low passenger volume and no high-concurrency ticket purchase requests in a short period of time, this embodiment can complete the user's ticket purchase operation through only the first ticketing server. In this case, referring to the security verification and query operation of the ticketing query server using the added virtual query and ticketing terminal, in order to ensure the timeliness of ticket purchase by legitimate users and the security of the first server, the virtual query and ticketing terminal also needs to generate automated ticket purchase instructions, and ensure that the user completes the ticket purchase operation by judging the legality of the source type of the ticket purchase instruction.

[0058] It should be noted that the source type of the ticket query instruction and the source type of the ticket purchase instruction mentioned in this embodiment are consistent. Even for the same client (such as a computer), the source of the web page instruction and the source of the APP instruction are two different types. Based on the setting of the source type of the instruction, it can be ensured that the target information can be screened out more quickly in the event of malicious intrusion.

[0059] In practical applications, virtual query and ticket purchase terminals need to transmit information and send / receive instructions with the ticket query server and the first ticket server. Traditional single-threaded data interaction not only affects the timeliness of data transmission but also slows down processing speed due to the multi-source nature of the data. Therefore, in this embodiment, even under low passenger flow conditions, when there are few query and / or ticket purchase requests, to maximize data transmission and processing speed, a corresponding independent thread is set up for each type of data. Furthermore, the independent thread setup ensures that subsequent high-concurrency requests do not affect the control of overbooking of bus routes. Therefore, in this embodiment, before obtaining the source type of ticket query instructions from the ticket query server and the source type of ticket purchase instructions from the first ticket server, the virtual query and ticket purchase terminal may also include:

[0060] Establish a first receiving thread between the virtual query and ticket purchase terminal and the ticket query server, and establish a second receiving thread between the virtual query and ticket purchase terminal and the first ticket server;

[0061] The virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread and the source type of the ticket purchase instruction through the second receiving thread.

[0062] Specifically, after the virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread, it also includes:

[0063] A first sending thread and a third receiving thread are established between the virtual query and ticket purchase terminal and the ticket query server. The first sending thread sends the automated query instruction corresponding to the source type to the ticket query server. When the ticket query server responds to the user's query instruction, the third receiving thread receives the query result information.

[0064] After the virtual query and ticket purchase terminal receives the source type of the ticket purchase instruction through the second receiving thread, it also includes:

[0065] A second sending thread and a fourth receiving thread are established between the virtual query and ticket purchase terminal and the first ticketing server. The second sending thread sends the automated ticket purchase instruction corresponding to the source type to the first ticketing server. When the first ticketing server responds to the user's ticket purchase instruction, the fourth receiving thread receives the remaining seat information of the pre-scheduled train.

[0066] It should be noted that for the ticket query server and the first ticket server used for communication and data transmission with the client, since this embodiment has already prevented the imitation of the client to cause illegal intrusion into the ticket query server and the first ticket server through a comprehensive judgment method based on the source type of the instruction and the automated query instruction and the automated ticket purchase instruction, if malicious intrusion still exists, it is very likely to imitate the virtual query and ticket purchase terminal to complete the malicious intrusion. Therefore, in order to ensure the security of the entire system, for the virtual query and ticket purchase terminal, this embodiment does not allow the information received therein to be read through remote information authentication. Therefore, in this embodiment, the query result information and the pre-arranged remaining seat information received in the virtual query and ticket purchase terminal are set to only allow reading through hardware access.

[0067] In actual operation, as more and more types of smart devices are allowed to connect to the network, such as smartwatches from many manufacturers that can perform ticket inquiries and purchases after being set up, it is inevitable that the source types of stored ticket inquiry instructions and ticket purchase instructions need to be updated. In this embodiment, taking the update of the source type of ticket inquiry instructions as an example, if the ticket inquiry server experiences high concurrency requests in a short period, even with a high configuration, it may not be able to respond to instructions in a timely manner. Therefore, in order not to affect the update of the source type of instructions or the subsequent generation of automated inquiry instructions, in this embodiment, when the source type of ticket inquiry instructions stored in the ticket inquiry server is updated, it may include:

[0068] The source type of the ticket query command to be updated is cached, and it is determined whether the ticket query server has reached a load balance state. If it has not reached a load balance state, the source type of the cached ticket query command is sent to the virtual query and ticket purchase terminal.

[0069] When the virtual query and ticket purchase terminal generates an automated query instruction corresponding to the source type and sends it to the ticket query server, it will again determine whether the ticket query server has reached a load balance state. If it has not, the source type of the ticket query instruction to be updated will be updated.

[0070] Here, although the ticket query server receives the update information first, it does not directly update the source type of the instruction. Instead, it caches the information and then updates it after the virtual query and ticket purchase terminal generates the automated query instruction. Although the update method is slightly slower than the traditional method, it ensures that the ticket query server can send and receive instructions with the virtual query and ticket purchase terminal in the best possible state, and it can also further improve the security of the ticket query server.

[0071] It should be noted that, due to the massive number and diverse types of clients involved in ticket inquiries, it is necessary to match user query commands to minimize malicious intrusion. Specifically, in this embodiment, the ticket query server determines whether a user query command matches based on automated query commands, which means:

[0072] Obtain the source of the user's query instruction and determine whether it belongs to the source type of the ticket query instruction corresponding to the current automated query instruction. If it does, then the user's query instruction is considered to match.

[0073] Understandably, when a user's query command does not match, the current user's query command can be marked directly, and subsequent queries can be received directly.

[0074] In this embodiment, the first ticketing server mainly undertakes the ticketing function before high-concurrency requests. When high-concurrency requests occur, the second ticketing server handles the high-concurrency request situation and completes the ticketing function. At this time, in order to ensure faster response during ticketing and reduce the security risk of the entire system, it is not necessary for the virtual query and ticketing terminal to generate automated ticketing instructions. Therefore, when the first ticketing server reaches the load balancing state, it may also include: notifying the virtual query and ticketing terminal to stop generating automated ticketing instructions through the first ticketing server.

[0075] It should be noted that when there is a high volume of passengers in a short period of time, i.e., a high number of concurrent requests, the second ticketing server needs to handle ticket sales. However, for vehicles and seats in the normal pre-scheduled schedules, there may be cases of ticket refunds or orders not being paid for for a long time. In this case, in order to improve the efficiency of the route operation, the traditional ticketing system will lock the corresponding seats, which may result in some seats in the pre-scheduled vehicles being idle. At the same time, even if the pre-scheduled vehicles are full, the scheduled capacity may not be able to meet the travel needs of users. Therefore, in this case, setting up overbooking for the route is necessary. In the traditional way, operators mostly set up overbooking based on historical data. Although setting the number of overbooked tickets and vehicles based on historical data can meet the travel needs of most users, there may still be some users who cannot travel due to the lag of historical data. Therefore, in this embodiment, it is necessary to control the overbooking of route tickets in the second ticketing server, that is, to store the overbooking control rules for route tickets in the second ticketing server.

[0076] Here, the overbooking control rules for scheduled bus routes stored in the second ticketing server refer to:

[0077] Before the second ticketing server receives the notification from the first ticketing server:

[0078] Set up an initial oversold pool, and set the number, type, and number of seats of oversold vehicles based on the initial oversold pool;

[0079] Obtain the remaining seat information for the pre-scheduled train from the first ticketing server, and determine whether the corresponding order has been placed and paid for.

[0080] If completed, the remaining seats for the corresponding pre-scheduled train will be locked, and when the second ticketing server receives a user's ticket purchase instruction, the order will be directly allocated to the initial overbooking pool and marked as an overbooking order.

[0081] Otherwise, the remaining seats of the pre-scheduled trains corresponding to orders that have not completed the order placement and payment process will be released. When the second ticketing server receives a user's ticket purchase instruction, it will allocate the order to the remaining seats of the pre-scheduled trains according to the order time from earliest to latest and mark the order as a normal order. When the tickets corresponding to the remaining seats of the pre-scheduled trains are sold out, the order will be allocated to the initial oversold pool and marked as an oversold order.

[0082] Set all oversold orders to waitlist status, obtain the payment time of oversold orders in waitlist status, and adjust the initial oversold pool based on the payment time.

[0083] Example 2

[0084] Based on Example 1, this example provides a route overbooking control method based on passenger flow adaptation, the flowchart of which can be found here. Figure 2 The method includes the following steps:

[0085] S1. Configure a virtual query and ticket purchase terminal, a ticket query server, a first ticket server, and a second ticket server. Store the source type of the ticket query instruction on the ticket query server, the source type of the ticket purchase instruction on the first ticket server, and the overbooking control rules for bus routes on the second ticket server.

[0086] S2. Obtain the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server through the virtual query and ticket purchase terminal, generate the automated query instruction and automated ticket purchase instruction corresponding to the source type, and send the automated query instruction to the ticket query server and the automated ticket purchase instruction to the first ticket server.

[0087] S3. Receive automated query instructions and user query instructions through the ticket query server, and determine whether the user query instructions match based on the automated query instructions. If they match, respond to the user query instructions and send query result information to the client.

[0088] S4. Real-time determination of whether the first ticketing server has reached a load balancing state. If not, receive automated ticket purchase instructions and user ticket purchase instructions, and determine whether the user ticket purchase instruction matches based on the automated ticket purchase instruction. If they match, respond to the user ticket purchase instruction and send the remaining seat information of the pre-arranged train to the client. If they match, notify the second ticketing server.

[0089] S5. Upon receiving a notification from the first ticketing server via the second ticketing server, activate the overbooking control rules for scheduled bus routes and receive user purchase instructions in real time. Based on the overbooking control rules for scheduled bus routes, respond to the user purchase instructions by sending available vehicle information and available seat information to the client.

[0090] As can be seen from the description of Embodiment 1, the application scenario and implementation principle of this embodiment are the same as those of Embodiment 1, so they will not be repeated here.

[0091] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A route overbooking control system based on adaptive passenger flow, characterized in that, include: The virtual query and ticket purchase terminal is used to obtain the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server, generate automated query instructions and automated ticket purchase instructions corresponding to the source type, and send the automated query instructions to the ticket query server and the automated ticket purchase instructions to the first ticket server. The ticket query server stores the source types of ticket query instructions. It is used to receive automated query instructions and user query instructions, and to determine whether the user query instruction matches the automated query instruction. If it matches, it responds to the user query instruction and sends the query result information to the client. The first ticketing server stores the source type of ticket purchase instructions and is used to determine in real time whether the first ticketing server has reached a load balancing state. When it has not reached a load balancing state, it receives automated ticket purchase instructions and user ticket purchase instructions, and determines whether the user ticket purchase instructions match based on the automated ticket purchase instructions. When they match, it responds to the user ticket purchase instructions and sends the remaining seat information of the pre-arranged train to the client. When the load balancing is achieved, it notifies the second ticketing server. The second ticketing server stores the overbooking control rules for scheduled bus routes. When it receives a notification from the first ticketing server, it activates the overbooking control rules for scheduled bus routes and receives user ticket purchase instructions in real time. Based on the overbooking control rules for scheduled bus routes, it responds to user ticket purchase instructions by sending available vehicle information and available seat information to the client.

2. The passenger flow adaptive overbooking control system for scheduled routes according to claim 1, characterized in that, In the virtual query and ticket purchase terminal, the automated query instruction is used to simulate a user's ticket query behavior, and the automated ticket purchase instruction is used to simulate a user's ticket purchase behavior.

3. The passenger flow adaptive overbooking control system for scheduled routes according to claim 1, characterized in that, Before obtaining the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server, the virtual query and ticket purchase terminal further includes: Establish a first receiving thread between the virtual query and ticket purchase terminal and the ticket query server, and establish a second receiving thread between the virtual query and ticket purchase terminal and the first ticket server; The virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread and the source type of the ticket purchase instruction through the second receiving thread.

4. The passenger flow adaptive overbooking control system for scheduled routes according to claim 3, characterized in that, After the virtual query and ticket purchase terminal receives the source type of the ticket query instruction through the first receiving thread, it also includes: A first sending thread and a third receiving thread are established between the virtual query and ticket purchase terminal and the ticket query server. The first sending thread sends the automated query instruction corresponding to the source type to the ticket query server. When the ticket query server responds to the user's query instruction, the third receiving thread receives the query result information. After the virtual query and ticket purchase terminal receives the source type of the ticket purchase instruction through the second receiving thread, it also includes: A second sending thread and a fourth receiving thread are established between the virtual query and ticket purchase terminal and the first ticketing server. The second sending thread sends the automated ticket purchase instruction corresponding to the source type to the first ticketing server. When the first ticketing server responds to the user's ticket purchase instruction, the fourth receiving thread receives the remaining seat information of the pre-scheduled train.

5. The passenger flow adaptive overbooking control system for scheduled bus routes according to any one of claims 1-4, characterized in that, The query results and remaining seat information for pre-scheduled trains received by the virtual query and ticket purchase terminal are set to be read only via hardware access.

6. The passenger flow adaptive overbooking control system for scheduled routes according to claim 1, characterized in that, When the source type of the ticket query instruction stored in the ticket query server is updated, it includes: The source type of the ticket query command to be updated is cached, and it is determined whether the ticket query server has reached a load balance state. If it has not reached a load balance state, the source type of the cached ticket query command is sent to the virtual query and ticket purchase terminal. When the virtual query and ticket purchase terminal generates an automated query instruction corresponding to the source type and sends it to the ticket query server, it will again determine whether the ticket query server has reached a load balance state. If it has not, the source type of the ticket query instruction to be updated will be updated.

7. The passenger flow adaptive overbooking control system for scheduled routes according to claim 1, characterized in that, The ticketing query server determines whether a user's query command matches the automated query command, meaning: Obtain the source of the user's query instruction and determine whether it belongs to the source type of the ticket query instruction corresponding to the current automated query instruction. If it does, then the user's query instruction is considered to match.

8. The passenger flow adaptive overbooking control system for scheduled bus routes according to claim 1, characterized in that, When the first ticketing server reaches load balancing status, it also includes: The first ticketing server notifies the virtual query and ticketing terminal to stop generating automated ticketing instructions.

9. The passenger flow adaptive overbooking control system for scheduled routes according to claim 1, characterized in that, The overbooking control rules for scheduled bus routes stored in the second ticketing server refer to: Before the second ticketing server receives the notification from the first ticketing server: Set up an initial oversold pool, and set the number, type, and number of seats of oversold vehicles based on the initial oversold pool; Obtain the remaining seat information for the pre-scheduled train from the first ticketing server, and determine whether the corresponding order has been placed and paid for. If completed, the remaining seats for the corresponding pre-scheduled train will be locked, and when the second ticketing server receives a user's ticket purchase instruction, the order will be directly allocated to the initial overbooking pool and marked as an overbooking order. Otherwise, the remaining seats of the pre-scheduled trains corresponding to orders that have not completed the order placement and payment process will be released. When the second ticketing server receives a user's ticket purchase instruction, it will allocate the order to the remaining seats of the pre-scheduled trains according to the order time from earliest to latest and mark the order as a normal order. When the tickets corresponding to the remaining seats of the pre-scheduled trains are sold out, the order will be allocated to the initial oversold pool and marked as an oversold order. Set all oversold orders to waitlist status, obtain the payment time of oversold orders in waitlist status, and adjust the initial oversold pool based on the payment time.

10. A route overbooking control method based on adaptive passenger flow, applied to the route overbooking control system based on adaptive passenger flow as described in any one of claims 1-9, characterized in that, Includes the following steps: Configure a virtual query and ticket purchase terminal, a ticket query server, a first ticket server, and a second ticket server. Store the source type of ticket query instructions on the ticket query server, the source type of ticket purchase instructions on the first ticket server, and the overbooking control rules for bus routes on the second ticket server. The system obtains the source type of the ticket query instruction from the ticket query server and the source type of the ticket purchase instruction from the first ticket server through the virtual query and ticket purchase terminal, generates automated query instructions and automated ticket purchase instructions corresponding to the source types, and sends the automated query instructions to the ticket query server and the automated ticket purchase instructions to the first ticket server. The system receives automated query commands and user query commands through the ticket query server, and determines whether the user query command matches the automated query command. If they match, the system responds to the user query command by sending the query result information to the client. The system continuously checks whether the first ticketing server has reached a load-balanced state. If it has not, it receives automated ticketing instructions and user ticketing instructions, and determines whether the user ticketing instructions match based on the automated ticketing instructions. If they match, it responds to the user ticketing instructions and sends the remaining seat information of the pre-arranged train to the client. If the system reaches a load balanced state, it notifies the second ticketing server. Upon receiving a notification from the first ticketing server via the second ticketing server, the overbooking control rules for scheduled bus routes are activated, and user purchase instructions are received in real time. Based on the overbooking control rules for scheduled bus routes, in response to user purchase instructions, available vehicle information and available seat information are sent to the client.

Images