Ticket transaction message queue processing method, system, device and medium

Abstract

The application relates to the technical field of railway traffic, in particular to a ticket transaction message queue processing method and system, computer equipment and a storage medium. The method comprises the following steps: differentiating and distributing real-time received ticket purchase requests to corresponding small queues based on preset queue dynamic constraint conditions and risk levels corresponding to the ticket purchase requests; monitoring the running state of a ticket transaction queuing system in real time according to a pre-configured multi-objective optimization function and preset function constraint conditions; and adaptively and dynamically adjusting each small queue according to the current running state of the ticket transaction queuing system. The adaptive dynamic adjustment content comprises at least one of the following: small queue length, thread pool expansion and contraction, extreme congestion control and parameter closed-loop optimization. A method for efficiently processing a large number of ticket purchase requests is provided.

Description

Technical Field

[0001] This application relates to the field of railway transportation technology, specifically to a method, system, computer equipment, and storage medium for processing ticket transaction message queues. Background Technology

[0002] The uneven spatial and temporal distribution of railway passenger travel demand and limited transport capacity, coupled with a large number of automated ticket-grabbing behaviors constantly refreshing and submitting ticket purchase requests, have resulted in the 12306 ticketing system facing complex high-concurrency transaction scenarios for a long time. Especially during peak travel periods such as the Spring Festival and other holidays, and at the time when tickets go on sale at various railway bureaus and stations, the instantaneous massive number of disordered and concurrent valid or invalid requests, if concentrated on a small number of servers, may lead to server overload, response delays, or even crashes. This could result in legitimate users' ticket purchase needs not being met, thus affecting the fairness of the ticket purchase process. Therefore, to ensure the stable operation of the system and provide users with efficient and orderly ticket transaction services, there is an urgent need for a message queue processing method for large-scale high-concurrency requests. Summary of the Invention

[0003] This application provides a ticketing transaction message queue processing method, system, computer device, and storage medium.

[0004] A first aspect of the embodiments of this application provides a ticketing transaction message queue processing method, comprising at least: Based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the real-time received ticket purchase requests are differentiated and allocated to the corresponding small queues. The operation status of the ticketing transaction queuing system is monitored in real time based on the pre-configured multi-objective optimization function and the preset function constraints. The ticketing transaction queuing system is used to adaptively and dynamically adjust each queue according to its current operating status. The adaptive dynamic adjustment includes at least one of the following: queue length, thread pool expansion and contraction, extreme congestion control, and parameter closed-loop optimization.

[0005] In an optional embodiment of this application, before the step of differentially allocating real-time received ticket purchase requests to corresponding sub-queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase requests, the method further includes: Determine the total number of threads, the total number of processes, and the number of consumer threads in each process in the current seat center queuing service resources; The maximum number of parallel threads in the current seat center is estimated based on the total number of threads, the total number of processes, and the number of consumer threads contained in each process. The quantity characteristic value of each small queue is determined based on the maximum number of parallel threads and the initial number of threads in each small queue within the current seat center; The prime number not less than the specified quantity characteristic value is determined as the number of small queues in the current seat center.

[0006] In one optional embodiment of this application, the step of differentially allocating real-time received ticket purchase requests to corresponding small queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase requests includes: Based on the pre-set risk control strategy, the user information, device information, and IP information corresponding to the ticket purchase request, the risk level corresponding to the ticket purchase request is determined; For risky ticket purchase requests with a risk level higher than a preset risk threshold, request delay processing is performed; the request delay processing includes at least one of the following: assigning the request to the tail of the current small queue, increasing the ticket purchase delay time, and assigning the request to a dedicated slow small queue; If the queuing time of the risky ticket purchase request exceeds the preset waiting time, the risky ticket purchase request will be adjusted to a normal ticket purchase request and processed normally based on the preset queue dynamic constraints. The normal ticket purchase request processing includes at least one of the following: eliminating the ticket purchase delay time, adjusting to the corresponding normal ticket purchase order, and allocating to a normal ticket purchase sub-queue.

[0007] In one optional embodiment of this application, the step of real-time monitoring of the operating status of the ticketing transaction queuing system based on a pre-configured multi-objective optimization function and preset function constraints includes: Based on the pre-configured multi-objective optimization function and preset function constraints, the operation status of the ticketing transaction queuing system is monitored in real time from multiple monitoring dimensions; among them, the multiple monitoring dimensions include at least: preset basic indicators and preset composite indicators; The preset basic indicators include at least one of the following: number of queuing ticket purchase requests, number of remaining tickets, ticket purchase request arrival rate, number of threads occupied, average processing time, total number of ticket purchase requests received by the seat center within a preset time period, and total number of successful ticket purchases. The preset composite indicators include: the load rate of each small queue, the total number of threads running in the seat center, the average estimated queuing time of each small queue, real-time constraints, and the ticket purchase success rate of the seat center within the preset time.

[0008] In an optional embodiment of this application, the pre-configured multi-objective optimization function is as follows: ,

[0009] The optimization objective is: in time To minimize the average user queuing time and request drop rate at the seat center; Represents a small queue In time The number of queued ticket purchase requests; Represents a small queue In time Average estimated queue waiting time; Represents a small queue In time The weighting coefficient for successful ticket purchase in queues; Represents a small queue In time The rate at which ticket purchase requests arrive; Represents a small queue In time The queue length amplification factor; Represents a small queue In time The number of remaining tickets.

[0010] In one optional embodiment of this application, the adaptive dynamic adjustment of each queue based on the current operating state of the ticketing transaction queuing system includes: The length of the current small queue is dynamically adjusted based on the sensitivity coefficient, queue length amplification coefficient, and ticket purchase success rate of the current small queue. Based on the load rate metric and the average estimated queuing time, increase the number of threads for small queues with high load or queuing time exceeding the first waiting threshold, and reduce the number of threads for queues with low load or queuing time below the second waiting threshold; the second waiting threshold is less than the first waiting threshold. If all subqueries in the seat center are under high load, the circuit breaker and boundary shrinking mechanism will be activated to stop the thread pool expansion of all subqueries; and / or, the queue length amplification factor of each subquery will be reduced. The maximum difference between the queue waiting time for ticket purchase requests and the average total queue waiting time, as well as the real-time adjustment of queue length amplification factor and sensitivity factor based on various preset basic indicators.

[0011] In an optional embodiment of this application, the queue dynamic constraints are determined according to the following method: For each small queue in the current seat center, the queue capacity constraint is determined in real time based on the queue length magnification factor of the current small queue and the remaining tickets for the train; and / or, Fairness constraints are determined based on the current queuing service resources of the seat center and the preset maximum queuing time; and / or, The real-time constraint is determined based on the maximum request processing delay allowed by the ticketing transaction queuing system.

[0012] A second aspect of this application provides a ticketing transaction message queue processing system, comprising: The queue allocation module is used to differentiate and allocate real-time received ticket purchase requests to corresponding small queues based on preset dynamic queue constraints and the risk level corresponding to the ticket purchase request. The queue monitoring module is used to monitor the operating status of the ticketing transaction queuing system in real time according to the pre-configured multi-objective optimization function and preset function constraints. The queue dynamic adjustment module is used to adaptively and dynamically adjust each small queue according to the current operating status of the ticketing transaction queuing system; the adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool expansion and contraction, extreme congestion control, and parameter closed-loop optimization.

[0013] A third aspect of this application provides a computer device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0015] This application provides a ticketing transaction message queue processing method. Based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the method differentiates the real-time received ticket purchase requests to corresponding small queues. It monitors the operating status of the ticketing transaction queuing system in real time according to a pre-configured multi-objective optimization function and preset function constraints. It adaptively and dynamically adjusts each small queue according to the current operating status of the ticketing transaction queuing system. The adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool scaling, extreme congestion control, and parameter closed-loop optimization. Firstly, it can batch process large-scale, high-concurrency ticket purchase requests, resulting in higher efficiency. Secondly, by configuring a multi-objective optimization function and function constraints for ticketing transaction queuing, and using real-time monitoring through function constraints, it achieves adaptive dynamic adjustment of small queue length, thread pool, extreme congestion, and parameters. This results in multiple objectives, including minimizing the average queuing time for all users, maximizing the success rate of ticket purchase requests, maximizing system throughput, and maximizing the fair ticket purchase opportunity for individual users, thereby improving the overall efficiency of ticketing transaction queuing system processing. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 An interaction diagram of a ticketing transaction message queue processing method provided in one embodiment of this application; Figure 2 A flowchart illustrating a ticket transaction message queue processing method provided in one embodiment of this application; Figure 3 A flowchart illustrating a ticket transaction message queue processing method provided in one embodiment of this application; Figure 4 A flowchart illustrating a ticket transaction message queue processing method provided in one embodiment of this application; Figure 5 This is an application example diagram of a ticketing transaction message queue processing method provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of a ticketing transaction message queue processing system provided in one embodiment of this application; Figure 7 This is a schematic diagram of a computer device structure provided in one embodiment of this application. Detailed Implementation

[0017] The solutions in this application embodiment can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0018] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0019] This application provides a ticketing transaction message queue processing method applied to a ticketing transaction queuing system. This ticketing transaction queuing system can be configured on a server, in the cloud, or in a distributed system, such as the 12306 ticketing system, used to provide ticketing services to multiple railway bureaus. This application does not impose specific limitations and can be flexibly selected or configured according to actual circumstances.

[0020] A railway bureau may have one or more seat centers. The queuing service resources of each seat center are physically isolated. Each seat center has multiple small queues, and the queuing service resources within a seat center are shared among all small queues. Each small queue acts as a ticketing port for ticket issuance. Each seat center is independent of the others and does not share system resources. When an individual seat center experiences an anomaly or failure, other seat centers can continue to provide normal service.

[0021] Please see also Figure 1 and Figure 2 For each seat center, the ticketing transaction message queue processing method provided in this application embodiment mainly includes four parts: queue initialization and construction; real-time request classification and differentiated queuing; real-time system status monitoring; and dynamic adaptive adjustment of the queue. Specifically, the ticketing transaction message queue processing method provided in this application embodiment includes at least the following steps 100-300: Step 100: Based on the preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the real-time received ticket purchase requests are differentiated and allocated to the corresponding small queues. The dynamic constraints of the queue refer to additional constraints added when processing ticket purchase requests, including but not limited to: queue capacity constraints, fairness constraints, and real-time constraints. It should be explained that a ticket purchase request can only be mapped to a small queue according to a hash function, and multiple ticket purchase requests can be bound to a small queue. The risk level is used to characterize whether the current ticket purchase request is malicious, etc., and can include levels from 1 to 10, where level 1 represents the lowest risk and level 10 represents the highest risk, possibly indicating malicious ticket scalping, requiring corresponding delayed processing or ticket purchase prohibition, etc. This application differentiates and assigns these requests to the corresponding small queues. Here, a small queue refers to the various ticket purchase queues within a seat center.

[0022] Step 200: Monitor the operating status of the ticketing transaction queuing system in real time according to the pre-configured multi-objective optimization function and the preset function constraints; This multi-objective optimization function refers to a processing function that continuously optimizes the processing of ticket purchase requests based on multiple set optimization objectives. The number and types of these optimization objectives can be flexibly set according to actual conditions, including but not limited to: average user queuing time and request drop rate. The operating status can be characterized by various operating parameters of the ticket transaction queuing system, including but not limited to: number of queued ticket purchase requests, number of remaining tickets, ticket purchase request arrival rate, number of threads occupied, average processing time, total number of ticket purchase requests received by the seat center within a preset time period, and total number of successful ticket purchases, etc. These are not exhaustive and can be flexibly set or adjusted according to actual conditions.

[0023] Step 300: Adaptively and dynamically adjust each queue according to the current operating status of the ticket transaction queuing system.

[0024] The adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool scaling, extreme congestion control, and parameter closed-loop optimization. That is, the queue length of the small queue can be adjusted, and the thread pool can be scaled up or down.

[0025] This application provides a ticketing transaction message queue processing method. Based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the method differentiates the real-time received ticket purchase requests to corresponding small queues. It monitors the operating status of the ticketing transaction queuing system in real time according to a pre-configured multi-objective optimization function and preset function constraints. It adaptively and dynamically adjusts each small queue according to the current operating status of the ticketing transaction queuing system. The adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool scaling, extreme congestion control, and parameter closed-loop optimization. Firstly, it can batch process large-scale, high-concurrency ticket purchase requests, resulting in higher efficiency. Secondly, by configuring a multi-objective optimization function and function constraints for ticketing transaction queuing, and using real-time monitoring through function constraints, it achieves adaptive dynamic adjustment of small queue length, thread pool, extreme congestion, and parameters. This results in multiple objectives, including minimizing the average queuing time for all users, maximizing the success rate of ticket purchase requests, maximizing system throughput, and maximizing the fair ticket purchase opportunity for individual users, thereby improving the overall efficiency of ticketing transaction queuing system processing.

[0026] Please see Figure 3 In an optional embodiment of this application, before step 100 above, and before the differentiated allocation of real-time received ticket purchase requests to corresponding small queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the above ticket transaction message queue processing method further includes the following steps 001-004: Step 001: Determine the total number of threads, the total number of processes, and the number of consumer threads in each process in the current seat center queuing service resources; The thread pool above contains multiple consumer threads, each bound to a small queue for use by that queue. The total number of threads is the total number of consumer threads in the thread pool. A process is an execution sequence within the current seat center queuing service resources used to process ticket purchase requests. It consists of a program segment, a data segment, and a process control block, and is the basic unit for resource allocation and scheduling in the system.

[0027] Step 002: Estimate the maximum number of parallel threads in the current seat center based on the total number of threads, the total number of processes, and the number of consumer threads contained in each process; Step 003: Determine the quantity characteristic value of each small queue based on the maximum number of parallel threads and the initial number of threads in each small queue within the current seat center; Step 004: Determine the number of small queues in the current seat center as the prime number that is not less than the quantity characteristic value.

[0028] This embodiment describes the process of building a dynamically allocated set of small queues before allocating ticket purchase requests. ,in, Q represents the number of small queues at the center of that seat. i Let i represent the i-th subqueue. Since the train number (train_no) and travel date (date) can uniquely identify a train, a hash function is used. Ticket purchase requests are routed to corresponding queues to ensure that requests are evenly distributed across different queues and that queuing service resources are shared fairly. The calculation method is as follows: The total number of allocable threads is calculated based on the queuing service resource allocation of the seat center. Total number of processes and the number of consumer threads contained in each process. Each consumer thread is bound to a thread pool to process a small queue. The thread pool handles ticket purchase requests within a given timeframe. The number of threads is ,and It can be dynamically adjusted. Estimate the maximum number of parallel threads a seat center can handle concurrent requests using the following formula (1). : (1) Uneven thread resource usage among the smaller queues within the seat center can lead to service lag and latency issues across the entire seat center. Therefore, this embodiment sets the initial number of threads for each smaller queue within the seat center. ,Right now For example, based on ticket purchase request log data, the minimum number of threads allocated can be selected within a certain period of time when successful ticket purchases are made and CPU utilization reaches a certain peak range (e.g., 70%-80%). The value can also be set based on business experience. Value. Calculated according to the following formula (2). : (2) Based on formula (2), we obtain Value, and select one that is not less than The prime number is used as the total number of small queues within the seat center. This is to optimize the uniformity of request hash distribution.

[0029] Firstly, this embodiment determines the quantity characteristic value of each small queue based on the maximum number of parallel threads and the initial number of threads in each small queue within the current seat center. Prime numbers not less than the quantity characteristic value are determined as the number of small queues in the current seat center. Selecting prime numbers, especially prime numbers, as the number of small queues can reduce hash collisions and improve distribution uniformity. Hash functions typically take the modulo of M (e.g., hash mod M). If M is a composite number (e.g., even, or containing a small factor), and the key fields in the request (e.g., train number, date, etc.) themselves have certain multiples or regular characteristics, the modulo result is prone to periodic clustering, leading to severe skewness in some queues and idleness in others. When M is a prime number, the remainder distribution of the modulo operation is closer to random, effectively breaking down the regularity of the input data and making requests more evenly distributed across the small queues. Secondly, for example, if the train number itself is a multiple of 10, and M=10, then all such requests will fall into queue 0, resulting in severe imbalance. If M is a prime number (such as 11 or 13), even if the input data has implicit multiple relationships, it is difficult to form a simple multiple correspondence with M, thus reducing the risk of structural skew. Thirdly, traditional hash functions such as Java's HashMap and Redis tend to use prime numbers or powers of 2 mixed with perturbations when calculating slots. However, if the hash function itself is not random enough, prime number modulo is the simplest and most effective remedy. Fourthly, since subsequent steps dynamically adjust queue length and thread resources, if the initial queue size is unevenly distributed, the complexity of subsequent scaling and load balancing will increase significantly. Finally, choosing a prime number as M can reduce the chain of adjustments caused by uneven distribution from the source, making the initial state of the system more stable.

[0030] Please see Figure 4 In an optional embodiment of this application, step 100 above, which involves differentiating real-time received ticket purchase requests to corresponding small queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, includes the following steps 110-130: Step 110: Determine the risk level corresponding to the ticket purchase request based on the pre-set risk control strategy, user information, device information, and IP information corresponding to the ticket purchase request; For example, after receiving a ticket purchase request, the ticketing transaction queuing system first extracts information such as the user, device, and IP from the request, and then judges the risk level of the user, device, and IP according to the risk control strategy. The risk control strategy can be implemented by a series of offline risk labeling algorithms, including various analysis methods such as clustering, classification, and statistics. This application embodiment does not make specific limitations.

[0031] Step 120: Delay the purchase requests for tickets with a risk level higher than the preset risk threshold; The request delay processing includes at least one of the following: allocating it to the tail of the current small queue, increasing the ticket purchase delay time, and allocating it to a dedicated slow small queue; For example, placing requests that reach a risk level threshold at the end of the queue and waiting for a period of time can lower their priority for queuing to purchase tickets. The minimum queuing time can be set according to factors such as peak and off-peak seasons, popularity of the train, and risk level. For example, for medium-risk requests, the queuing time can be set to 30 seconds in the off-peak season and 1 minute in the peak season. For high-risk requests, the queuing time can be set to 2 minutes in the off-peak season and 3 minutes in the peak season. Other values ​​can also be set based on actual business experience and system resources.

[0032] In addition, risk requests can be placed in a slow queue to reduce their ticketing priority. Slow queues can be created based on risk level classification, and the queuing time for risk requests in the slow queue can be set similarly to placing them at the end of the queue. The length of the slow queue can be set based on historical risk request data analysis and system resources, and it no longer hashes risk requests based on train number and travel date. For example, for a slow queue with a medium risk level, its queue length can be set to 2000, meaning it can receive a maximum of 2000 medium risk requests. Other values ​​can also be set.

[0033] Step 130: If the queuing time of the risky ticket purchase request is longer than the preset waiting time, the risky ticket purchase request is adjusted to a normal ticket purchase request, and the request is processed normally based on the preset queue dynamic constraint conditions. The normal ticket purchase request processing includes at least one of the following: eliminating the ticket purchase delay time, adjusting the order of normal ticket purchases, and allocating the request to a normal ticket purchase queue.

[0034] If the queuing time set for risk requests is too long, such as more than 5 minutes, in order to minimize the probability of false positives in risk assessment, user identity can be verified through methods such as facial recognition and SMS verification. For risk requests that pass the verification, the long queuing time restriction can be lifted, allowing the risk request to immediately participate in the ticket purchase queue normally.

[0035] This application embodiment differentiates ticket purchase queuing based on the risk anomaly level characteristics of ticket purchase requests, transferring ticket purchase requests with obvious malicious intent to the slow queue or the tail of the normal queue, thereby minimizing the disruption of normal ticket purchase order by risky requests.

[0036] In an optional embodiment of this application, step 200 above, namely, real-time monitoring of the operating status of the ticketing transaction queuing system based on a pre-configured multi-objective optimization function and preset function constraints, includes the following steps: Based on the pre-configured multi-objective optimization function and preset function constraints, the operation status of the ticketing transaction queuing system is monitored in real time from multiple monitoring dimensions; among them, the multiple monitoring dimensions include at least: preset basic indicators and preset composite indicators; This embodiment calculates and monitors the operating status of the ticketing transaction queuing system in real time from both basic and composite indicators, based on the constraint definition in the multi-objective optimization function.

[0037] Real-time statistics of each small queue In time Preset basic indicators for the time period, including but not limited to: number of ticket purchase requests in queue. Number of remaining votes Ticket purchase request arrival rate Number of threads used Average processing time Preset duration Total number of queuing requests received by the internal seating center and the total number of successful ticket purchases in the queue. ,in, This does not include requests from those who have already joined the queue but have voluntarily given up continuing to queue for tickets.

[0038] The preset composite indicators include, but are not limited to: the load rate of each small queue, the total number of threads running in the seat center, the average estimated queuing time of each small queue, real-time constraints, and the ticket purchase success rate of the seat center within a preset time. The preset composite indicators can be based on the statistical results of the basic indicators, and can be adjusted over time. The calculation is performed in real time, and the specific calculation formula is shown in the following example: Load rate of each queue ; Total number of running threads in the seat center ; Real-time average estimated waiting time for each queue ; Real-time constraints ; Preset duration Ticket purchase success rate in the inner seat center .

[0039] In an optional embodiment of this application, the pre-configured multi-objective optimization function is as follows: (3) (3) In formula (3), the optimization objective is: in time To minimize the average user queuing time and request drop rate at the seat center; The constraints of the multi-objective optimization function in the above formula (3) are as follows: formulas (4)-(7): ① Queue capacity constraint: (4) ②System resource constraints: (5) ③ Fairness constraints: (6) ④ Real-time constraints (the delay from request enqueuing to processing): (7) In formulas (3)-(7): Represents a small queue In time The number of queued ticket purchase requests; Represents a small queue In time Average estimated queue waiting time; Represents a small queue In time The weighting coefficient for successful ticket purchase in queues is set based on the success rate data, such as 0.05. This represents the maximum difference between the queue waiting time for any ticket purchase request and the average queue waiting time for all ticket purchase requests; Represents a small queue In time The rate at which ticket purchase requests arrive (requests / second); Represents a small queue In time The queue length amplification factor; Represents a small queue In time The number of remaining tickets; Represents a small queue In time The number of threads; Represents a small queue A single ticket purchase request within a certain time frame The average processing time (in seconds).

[0040] For the above real-time statistical indicators, under the condition of ensuring that the constraints defined in formulas (4)-(7) are met, each small queue is adaptively adjusted, including adjusting the length of the small queue, expanding or shrinking the thread pool, extreme congestion control, and parameter closed-loop optimization.

[0041] In one optional embodiment of this application, step 300 above, which involves adaptively and dynamically adjusting each queue based on the current operating status of the ticketing transaction queuing system, includes, but is not limited to, the following four adjustment methods: The first method involves adjusting the length of the smaller queue: The length of the current small queue is dynamically adjusted based on the sensitivity coefficient, queue length amplification coefficient, and ticket purchase success rate of the current small queue. According to the above formula (3), the queue length amplification factor And the number of remaining tickets Together affecting queue capacity constraints , and They are in a multiple relationship, while It can be accurately obtained through real-time statistical methods. This becomes the only way to adjust the queue length. When queuing service resources are sufficient, such as... If the queue is too large, new requests may have difficulty successfully purchasing tickets, resulting in a lower success rate than the target value. In this case, the queue length should be reduced. If the queue length is too small, it may lead to a large number of reasonable demands not being met when there are plenty of remaining tickets. In this case, the queue length should be increased. Therefore, the queue length can be adjusted according to formula (8). Adjustments were made to obtain a new queue length amplification factor. : (8) In formula (8), The target value for ticket purchase success rate should be set by statistical analysis, taking into account factors such as demand fluctuations during peak and off-peak seasons and the distribution of popular and unpopular train routes, or by setting other values ​​based on business experience, such as setting it to 95% during the off-peak season and 90% during the peak season. This is a sensitivity coefficient used to control the adjustment step size of the small queue length. Larger The value makes Accelerated adjustments could trigger systemic oscillations; smaller ones... The value makes A smooth adjustment is possible, but it may cause system response delays. Therefore, based on business experience, the adjustment should be carried out in small steps first, and then gradually increased in pace. value.

[0042] The second method involves scaling up and down a small queue thread pool: Based on the load rate metric and the average estimated queuing time, increase the number of threads for small queues with high load or queuing time exceeding the first waiting threshold, and reduce the number of threads for queues with low load or queuing time below the second waiting threshold; the second waiting threshold is less than the first waiting threshold. Based on the optimization goal of the message queue processing method proposed in this application, the thread pool size of each small queue needs to be adjusted to balance system resource load utilization and average user waiting time. According to the definition above, a small queue... In time The number of threads is Based on load rate metrics obtained from real-time statistics and average estimated queue waiting time For queues with high load or queuing times exceeding a threshold, the number of threads is increased; for queues with low load or queuing times below the threshold, the number of threads is reduced. Specific rules for scaling up and down the thread pool for each small queue can be exemplified below.

[0043] A. Thread pool expansion: like This means that the small queue is oversaturated and the average waiting time of users in that queue is significantly worse than the average level of the entire system, or the average estimated queuing waiting time exceeds the real-time constraint. First, check if the system resources are sufficient. If the conditions are met... Then, the small queue thread pool is expanded, so that... .

[0044] in, The maximum load rate is generally determined based on business experience, and a relatively large value is usually chosen, such as... ; To adjust the scaling step size, you can set it based on business experience. ; Calculate according to formula (1).

[0045] like If the system's queuing service resources are insufficient and the small queue cannot be directly expanded, a global scan of system resources is required, and thread resources should be reclaimed from the idle queue. In other words, step B below should be completed first.

[0046] B. Thread pool shrinking and idle resource reclamation: A global traversal search is performed to find the smallest queue that satisfies the absolute shrinkage condition. and That is, when the processing capacity of the small queue thread pool is lower than the minimum load rate set by the system. And the average estimated waiting time Significantly lower than the seat center fairness index At that time, it is considered that the thread pool of the small queue can be reduced in size, so that... This avoids small queues consuming too many resources and compensates the released thread quotas for popular queues that urgently need expansion.

[0047] in, The scaling step size can be set based on business experience. ; To constrain the minimum capacity of the thread pool, The determination is based on business experience and the principle of ensuring the minimum number of ticket purchase requests. To determine the minimum load rate, a smaller value can usually be determined based on business experience, such as taking... .

[0048] If the above conditions are not met, then maintain .

[0049] The third approach is extreme congestion control: If all subqueries in the seat center are under high load, the circuit breaker and boundary shrinking mechanism will be activated to stop the thread pool expansion of all subqueries; and / or, the queue length amplification factor of each subquery will be reduced. If all small queues in the seat center are under high load and no free queues with available resources can be found, while the average waiting time of the busy queues still exceeds the limit, circuit breaking and boundary contraction should be initiated to prevent a complete system collapse. First, stop expanding the thread pool for any queue. Second, accelerate the contraction of the busy queue length amplification factor according to formula (8), reduce the length of each small queue, refuse excessive requests from being enqueued, reduce the backlog of requests in the busy queue, and ensure that enqueued requests are within the maximum real-time constraints. Processing completed within the specified range.

[0050] The fourth method is parameter closed-loop optimization: The maximum difference between the queue waiting time for ticket purchase requests and the average total queue waiting time, as well as the real-time adjustment of queue length amplification factor and sensitivity factor based on various preset basic indicators.

[0051] Based on the real-time statistical values ​​of various indicators, adjustments are made online in real time. , , These parameters enable dynamic closed-loop optimization of asynchronous transaction queuing. For example, the maximum difference is calculated in real time, and the result is determined based on this maximum difference and preset fairness constraints. A comparison is made; if the maximum difference exceeds the fairness constraint... Then the queue will be dynamically adjusted.

[0052] This application embodiment adaptively and dynamically adjusts each small queue by adjusting the length of the small queue, scaling up and down the thread pool, extreme congestion control, and parameter closed-loop optimization. This achieves multiple goals, including minimizing the average queuing time for users, maximizing the success rate of ticket purchase requests, maximizing system throughput, and ensuring that individual users have the greatest possible fair opportunity to purchase tickets. Overall, this improves the efficiency of ticketing transaction queuing system.

[0053] like Figure 5 The diagram illustrates an example of applying the ticket transaction message queue processing method provided in this application to the 12306 ticket purchasing system. Figure 5 As can be clearly seen, at 17:21 on October 14, 2025, the actual operation of the 12306 ticketing transaction queuing system showed that the average response time for ticket purchase requests at all seat centers across the entire railway network was 1.4 seconds, the average waiting time was 1.3 seconds, and the ticket purchase success rate was close to 100%, greatly improving ticket purchase efficiency, orderliness, and success rate.

[0054] The ticketing transaction message queue processing method provided in this application embodiment has a maximum number of parallel threads within the seat center. Under these constraints, to ensure fairness and real-time performance in ticket purchasing for users, the length of each queue and queuing service resources are dynamically adjusted and allocated. This is done before accepting a user's ticket purchase request, i.e., within a short period of time. First, the queue capacity needs to be set. The initial values ​​of dynamic constraints such as fairness and real-time performance.

[0055] In an optional embodiment of this application, the queue dynamic constraints are determined according to the following method: The first type is queue capacity constraint. : For each small queue in the current seat center, the queue capacity constraint is determined in real time based on the queue length magnification factor of the current small queue and the remaining tickets for the train. Queue capacity constraints Indicates the time of the i-th small queue in the seat center. The maximum allowed number of queue requests is determined by factors such as ticket demand, remaining train tickets, system resources, and real-time load status. This is to prevent users from waiting for too long due to excessive queue length, and to ensure that the queue length is sufficient to cover the number of remaining tickets that can be processed, thereby reducing resource idleness. Before ticket sales begin, the system resources are sufficient and the real-time load status is good. Therefore, the main considerations are ticket demand and remaining train tickets. The queue capacity constraint is estimated using the following formula (9): (9) In formula (9), This represents the dynamically adjustable queue length amplification factor for the i-th sub-queue at time t. It is used to cover the impact of changes in available tickets during the processing on users' queuing for tickets. For example, some passengers may submit queuing requests but ultimately abandon their purchases, potentially freeing up reserved tickets for other passengers. Set to more than 1 times the number of remaining tickets; This represents the number of remaining tickets for all trains in the i-th sub-queue at time t.

[0056] exist At that time, the initial total number of remaining tickets can be accurately obtained based on railway ticket database data. Based on historical data statistical analysis, the distribution of the proportion of requests to abandon ticket purchases after joining the queue is analyzed, and the following is taken: Then the initial value of the i-th subqueue is set to... Alternatively, other values ​​can be set based on business experience and the distribution of ticket abandonment rates at each seat center.

[0057] The second type is fairness constraints.

[0058] Fairness constraints are determined based on the current queuing service resources of the seat center and the preset maximum queuing time; Fairness constraints This is used to ensure that the queuing time for user requests is relatively balanced, and to avoid some queues being starved or over-prioritized for a long time. It is generally determined based on business experience and the queuing service resources of each seat center. For example, during the off-season, the maximum queuing time difference between requests is set to 1 second, and during the peak travel season, it is set to 3 seconds.

[0059] The third type is real-time constraints.

[0060] The real-time constraint is determined based on the maximum request processing delay allowed by the ticketing transaction queuing system.

[0061] Real-time constraints Used to ensure efficient queuing for ticket purchases and to balance system performance and user experience, it represents the maximum allowable delay in request processing. It is the maximum time threshold from when a user request enters the queue to when it begins to be processed by the thread pool, consisting of the user request queuing time and processing time.

[0062] Based on business experience, during the off-season The initial value is usually set to 10 seconds to quickly respond to users' ticket purchase requests; during peak travel periods, it can be appropriately extended, such as to 30 seconds, to avoid increasing the probability of users failing to purchase tickets due to excessively short delay times.

[0063] If the queue time for ticket purchase requests exceeds Users may abandon their ticket purchase due to waiting timeouts, and this can serve as an important monitoring indicator to trigger dynamic system adjustments (such as expanding the thread pool or allocating more resources).

[0064] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0065] Please see Figure 6 One embodiment of this application provides a ticketing transaction message queue processing system 600, including: The queue allocation module 610 is used to differentiate the real-time received ticket purchase requests to the corresponding small queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase requests. The queue monitoring module 620 is used to monitor the operating status of the ticket transaction queuing system in real time according to the pre-configured multi-objective optimization function and preset function constraints. The queue dynamic adjustment module 630 is used to adaptively and dynamically adjust each small queue according to the current operating status of the ticketing transaction queuing system; the adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool expansion and contraction, extreme congestion control, and parameter closed-loop optimization.

[0066] In an optional embodiment of this application, the queue allocation module 610 is further configured to: determine the total number of threads, the total number of processes, and the number of consumer threads contained in each process in the current seat center queuing service resources; estimate the maximum number of parallel threads in the current seat center based on the total number of threads, the total number of processes, and the number of consumer threads contained in each process; determine the quantity characteristic value of each small queue based on the maximum number of parallel threads and the initial number of threads in each small queue in the current seat center; and determine the number of small queues in the current seat center as a prime number not less than the quantity characteristic value.

[0067] In an optional embodiment of this application, the queue allocation module 610 is specifically used to: determine the risk level corresponding to the ticket purchase request based on a pre-set risk control strategy, user information, device information, and IP information corresponding to the ticket purchase request; perform request delay processing on risky ticket purchase requests whose risk level is higher than a preset risk threshold; the request delay processing includes at least one of the following: allocating the request to the tail of the current small queue, increasing the ticket purchase delay duration, and allocating the request to a dedicated slow small queue; if the queuing waiting time of the risky ticket purchase request is greater than a preset waiting time, then the risky ticket purchase request is adjusted to a normal ticket purchase request, and the request is processed normally based on preset queue dynamic constraints; the normal ticket purchase request processing includes at least one of the following: eliminating the ticket purchase delay duration, adjusting the request to the corresponding normal ticket purchase order, and allocating the request to a normal ticket purchase small queue.

[0068] In an optional embodiment of this application, the queue monitoring module 620 is specifically used to monitor the operating status of the ticket transaction queuing system in real time from multiple monitoring dimensions according to a pre-configured multi-objective optimization function and preset function constraints. The multiple monitoring dimensions include at least: preset basic indicators and preset composite indicators. The preset basic indicators include at least one of the following: number of queuing ticket purchase requests, number of remaining tickets, ticket purchase request arrival rate, number of threads occupied, average processing time, total number of ticket purchase requests received by the seat center within a preset time period, and total number of successful ticket purchases. The preset composite indicators include: load rate of each small queue, total number of threads running in the seat center, average estimated queuing waiting time of each small queue, real-time constraints, and ticket purchase success rate of the seat center within a preset time period.

[0069] In an optional embodiment of this application, the pre-configured multi-objective optimization function is as follows: ,

[0070] The optimization objective is: in time To minimize the average user queuing time and request drop rate at the seat center; Represents a small queue In time The number of queued ticket purchase requests; Represents a small queue In time Average estimated queue waiting time; Represents a small queue In time The weighting coefficient for successful ticket purchase in queues; Represents a small queue In time The rate at which ticket purchase requests arrive; Represents a small queue In time The queue length amplification factor; Represents a small queue In time The number of remaining tickets.

[0071] In an optional embodiment of this application, the queue dynamic adjustment module 630 is specifically used to: dynamically adjust the queue length of the current small queue based on the sensitivity coefficient, queue length amplification coefficient, and ticket purchase success rate of the current small queue; increase the number of threads for small queues with high load or queue waiting time exceeding a first waiting threshold based on load rate indicators and average estimated queuing waiting time, and reduce the number of threads for queues with low load or queue waiting time below a second waiting threshold; the second waiting threshold is less than the first waiting threshold; if all small queues in the seat center are in a high load state, then activate the circuit breaker and boundary contraction mechanism to stop the expansion of the thread pool of all small queues; and / or, contract the queue length amplification coefficient of each small queue; and real-time adjust the queue length amplification coefficient and sensitivity coefficient based on the maximum difference between the queuing waiting time of the ticket purchase request and the average total queuing waiting time, as well as various preset basic indicators.

[0072] In an optional embodiment of this application, the queue allocation module 610 is further configured to: determine queue capacity constraints in real time for each small queue in the current seat center based on the queue length amplification factor of the current small queue and the remaining tickets for the train; and / or determine fairness constraints based on the queuing service resources of the current seat center and the preset maximum queuing waiting time; and / or determine real-time constraints based on the maximum request processing delay time allowed by the ticketing transaction queuing system.

[0073] Specific limitations regarding the aforementioned ticketing transaction message queue processing system 600 can be found in the above description of the limitations on the ticketing transaction message queue processing method, and will not be repeated here. Each module in the aforementioned ticketing transaction message queue processing system 600 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0074] In one embodiment, a computer device is provided, the internal structure of which can be as follows: Figure 7As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described ticketing transaction message queue processing system method. It includes: a memory and a processor; the memory stores a computer program; and the processor executes the computer program to implement any step of the above-described ticketing transaction message queue processing system method.

[0075] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, can perform any of the steps in the ticketing transaction message queue processing method described above.

[0076] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0078] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0079] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0080] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0081] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for processing ticket transaction message queues, characterized in that, At least including: Based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request, the real-time received ticket purchase requests are differentiated and allocated to the corresponding small queues. The operation status of the ticketing transaction queuing system is monitored in real time based on the pre-configured multi-objective optimization function and the preset function constraints. The ticketing transaction queuing system is used to adaptively and dynamically adjust each queue according to its current operating status. The adaptive dynamic adjustment includes at least one of the following: queue length, thread pool expansion and contraction, extreme congestion control, and parameter closed-loop optimization.

2. The ticketing transaction message queue processing method according to claim 1, characterized in that, Before the method differentiates the real-time received ticket purchase requests to corresponding sub-queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase requests, the method further includes: Determine the total number of threads, the total number of processes, and the number of consumer threads in each process in the current seat center queuing service resources; The maximum number of parallel threads in the current seat center is estimated based on the total number of threads, the total number of processes, and the number of consumer threads contained in each process. The quantity characteristic value of each small queue is determined based on the maximum number of parallel threads and the initial number of threads in each small queue within the current seat center; The prime number not less than the specified quantity characteristic value is determined as the number of small queues in the current seat center.

3. The ticketing transaction message queue processing method according to claim 1, characterized in that, The method of differentially allocating real-time received ticket purchase requests to corresponding small queues based on preset queue dynamic constraints and the risk level corresponding to the ticket purchase request includes: Based on the pre-set risk control strategy, the user information, device information, and IP information corresponding to the ticket purchase request, the risk level corresponding to the ticket purchase request is determined; For risky ticket purchase requests with a risk level higher than a preset risk threshold, request delay processing is performed; the request delay processing includes at least one of the following: assigning the request to the tail of the current small queue, increasing the ticket purchase delay time, and assigning the request to a dedicated slow small queue; If the queuing time of the risky ticket purchase request exceeds the preset waiting time, the risky ticket purchase request will be adjusted to a normal ticket purchase request and processed normally based on the preset queue dynamic constraints. The normal ticket purchase request processing includes at least one of the following: eliminating the ticket purchase delay time, adjusting to the corresponding normal ticket purchase order, and allocating to a normal ticket purchase sub-queue.

4. The ticketing transaction message queue processing method according to claim 1, characterized in that, The real-time monitoring of the ticketing transaction queuing system's operational status based on a pre-configured multi-objective optimization function and preset function constraints includes: Based on the pre-configured multi-objective optimization function and preset function constraints, the operation status of the ticketing transaction queuing system is monitored in real time from multiple monitoring dimensions; among them, the multiple monitoring dimensions include at least: preset basic indicators and preset composite indicators; The preset basic indicators include at least one of the following: number of queuing ticket purchase requests, number of remaining tickets, ticket purchase request arrival rate, number of threads occupied, average processing time, total number of ticket purchase requests received by the seat center within a preset time period, and total number of successful ticket purchases. The preset composite indicators include: the load rate of each small queue, the total number of threads running in the seat center, the average estimated queuing time of each small queue, real-time constraints, and the ticket purchase success rate of the seat center within the preset time.

5. The ticketing transaction message queue processing method according to claim 4, characterized in that, The pre-configured multi-objective optimization function is as follows: ， ； The optimization objective is: in time To minimize the average user queuing time and request drop rate at the seat center; Represents a small queue In time The number of queued ticket purchase requests; Represents a small queue In time Average estimated queue waiting time; Represents a small queue In time The weighting coefficient for successful ticket purchase in queues; Represents a small queue In time The rate at which ticket purchase requests arrive; Represents a small queue In time The queue length amplification factor; Represents a small queue In time The number of remaining tickets.

6. The ticketing transaction message queue processing method according to claim 1, characterized in that, The adaptive dynamic adjustment of each queue based on the current operating status of the ticketing transaction queuing system includes: The length of the current small queue is dynamically adjusted based on the sensitivity coefficient, queue length amplification coefficient, and ticket purchase success rate of the current small queue. Based on the load rate metric and the average estimated queuing time, increase the number of threads for small queues with high load or queuing time exceeding the first waiting threshold, and reduce the number of threads for queues with low load or queuing time below the second waiting threshold; the second waiting threshold is less than the first waiting threshold. If all subqueries in the seat center are under high load, the circuit breaker and boundary shrinking mechanism will be activated to stop the thread pool expansion of all subqueries; and / or, the queue length amplification factor of each subquery will be reduced. The maximum difference between the queue waiting time for ticket purchase requests and the average total queue waiting time, as well as the real-time adjustment of queue length amplification factor and sensitivity factor based on various preset basic indicators.

7. The ticketing transaction message queue processing method according to claim 1, characterized in that, The dynamic constraints of the queue are determined according to the following method: For each small queue in the current seat center, the queue capacity constraint is determined in real time based on the queue length magnification factor of the current small queue and the remaining tickets for the train; and / or, Fairness constraints are determined based on the current queuing service resources of the seat center and the preset maximum queuing time; and / or, The real-time constraint is determined based on the maximum request processing delay allowed by the ticketing transaction queuing system.

8. A ticketing transaction message queue processing system, characterized in that, include: The queue allocation module is used to differentiate and allocate real-time received ticket purchase requests to corresponding small queues based on preset dynamic queue constraints and the risk level corresponding to the ticket purchase request. The queue monitoring module is used to monitor the operating status of the ticketing transaction queuing system in real time according to the pre-configured multi-objective optimization function and preset function constraints. The queue dynamic adjustment module is used to adaptively and dynamically adjust each small queue according to the current operating status of the ticketing transaction queuing system; the adaptive dynamic adjustment includes at least one of the following: small queue length, thread pool expansion and contraction, extreme congestion control, and parameter closed-loop optimization.

9. A computer device, comprising: A memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images