A method and related apparatus for high availability of resources in a financial trading system

Abstract

This invention relates to a method and related apparatus for high availability of resources in a financial trading system. The method operates as follows: after assigning a special request header to a request to be sent, it is sent to the server; during server operation, the resource pool for processing requests is isolated and divided into high-priority and low-priority resource pools. After receiving a client request, the server obtains the special request header, records the initial information and business module entering the server, and marks the arrival time; the request is assigned to different resource pools for processing, with priority given to preempting resources in the low-priority resource pool; after the request is fully executed, the result of the request processing is fed back to the calculation module, which performs backtracking calculations on the data to support subsequent resource allocation. This invention solves the problem that financial trading systems cannot ensure high availability of a single service node in a low-cost and user-friendly manner under limited resource conditions. The system of this invention has high real-time performance, low cost, achieves high availability design, and maintains stable service availability.

Description

Technical Field

[0001] This invention relates to an Internet service technology, and more particularly to a method and related apparatus for high availability of resources in a financial transaction system. Background Technology

[0002] With the increasing popularity and development of mobile internet, the number of internet participants is growing, and the number of requests transmitted on the network is expanding rapidly. This poses a challenge to the performance and stability of internet service providers. For core systems involving the flow of funds, such as financial transaction systems, high availability under high traffic is even more crucial.

[0003] In theory, there is an upper limit to the ability of a server machine to process requests. When a server machine receives more requests than its capacity limit within a unit of time, the requests will not be processed and responded to in a timely manner, resulting in a backlog of requests. This will cause the machine to operate under overload until it crashes. A single point of failure will trigger a chain reaction, further dragging down the entire system and causing the service to be paralyzed.

[0004] Current technologies for solving this problem:

[0005] Option 1: Horizontally scale up the bottleneck service by adding machines and service nodes. During peak traffic periods, it is often difficult to prepare enough physical machines and deploy the corresponding service nodes in a short time, resulting in poor handling of sudden large traffic surges and insufficient real-time performance.

[0006] Option 2: Server-side rate limiting and circuit breaking. This involves setting a threshold for the number of requests processed per unit of time, discarding all requests exceeding this threshold. However, discarding requests leads to a poor user experience. Furthermore, since the threshold is a static parameter, it's difficult to calculate the boundary threshold based on the actual operating conditions of the service nodes to maximize their performance. Setting the threshold too high may also cause circuit breaking to fail, resulting in service downtime.

[0007] shortcoming:

[0008] 1. Option 1 is costly and has poor timeliness.

[0009] 2. Solution 2 suffers from inaccurate threshold calculation and poor user experience, resulting in low efficiency and insecurity. Summary of the Invention

[0010] To address the problem that financial trading systems cannot ensure high availability of a single service node in a low-cost and user-friendly manner under limited resource conditions, a method and related apparatus for high resource availability in financial trading systems are proposed. The solution approach is as follows:

[0011] 1. This invention improves node processing performance by adjusting the request processing method of a single service node, thus addressing the problems of high cost and poor timeliness brought about by Solution 1.

[0012] 2. This invention solves the problems of inaccurate threshold calculation and poor user experience in Solution 2 by dynamically calculating and setting thresholds through an algorithm.

[0013] 3. This invention differs from previous high availability implementation approaches. Previous high availability approaches used multiple machines, multiple nodes, and multiple clusters to achieve high availability in terms of deployment. This invention empowers a single node to improve its service capabilities under high traffic conditions, thereby achieving high availability under limited resources.

[0014] The technical solution of this invention is as follows:

[0015] A method for achieving high availability of resources in a financial trading system, based on a fundamental traffic calculation formula, is implemented through the following request processing method:

[0016] Step 1: When a request is sent through the client, it carries a pre-defined special communication request header, which includes the business module to which the request belongs, the caller's IP address, and the call weight.

[0017] Step 2: After assigning a special request header to the request to be sent, send it to the server;

[0018] Step 3: During server operation, the resource pool for processing requests is isolated and divided into high-priority and low-priority resource pools to achieve complete isolation at the resource level. Different resource pools contain different numbers of resources, with the high-priority resource pool accommodating more processing resources.

[0019] Step 4: After receiving the client's request, the server obtains the special request header, records the initial information and business module entering the server, and marks the arrival time;

[0020] Step 5: Based on the basic information of the request, past call time records, and the proportion of abnormal cases, the request is divided into different resource pools for processing. The specific operation is as follows:

[0021] Step 5.1: Set the influence factors α1, α2, α3…α x …ɑ n ;

[0022] Step 5.2: Set the exception call thresholds β1, β2, β3…β x …β n ;

[0023] Step 5.3: Set the total time consumption θ1, θ2, θ3…θ within each data acquisition cycle. x …θ n ;

[0024] Step 5.4: Set the total number of calls φ1, φ2, φ3…φ within each data collection cycle. x …φ n;

[0025] Step 5.5:

[0026] Step 5.6:

[0027] Step 5.7: When the time taken for past calls exceeds the time threshold, the request is classified as low priority;

[0028] Step 5.8: When the number of past abnormal calls exceeds the abnormal call threshold, the request is determined to be of low priority;

[0029] Step 6: Allow preemptive resource allocation. When a request is assigned to a high priority pool, if the low priority resource pool is not busy, the low priority resource pool will be preempted to provide service.

[0030] Step 7: After the request is fully executed, the result of the request processing is fed back to the calculation module. The calculation module performs backtracking calculations on the data to support subsequent resource allocation.

[0031] Step 7.1: Set the sampling period;

[0032] Step 7.2: Cumulative number of requests processed within the period;

[0033] Step 7.3: Accumulate the number of request exceptions within the period;

[0034] Step 7.4: Calculate the average request time and queuing delay;

[0035] Step 7.5: After each sampling period, observe the relationship between the number of requests processed and the queuing delay;

[0036] Step 7.6: When the number of requests processed and the queuing delay continue to rise in the same direction, record the number of requests processed within this sampling period and set it as the service upper limit threshold;

[0037] Furthermore, this method introduces a basic flow calculation formula:

[0038] When the service is stable, concurrency = queuing latency * number of requests processed per second;

[0039] When the service is not overloaded, concurrency and the number of requests processed per second are linearly related.

[0040] When the service is overloaded, concurrency and queuing latency will increase together, while the number of requests processed per second will tend to stabilize.

[0041] This shows that when a service is overloaded and on the verge of collapse, queuing latency and concurrency will both increase.

[0042] Furthermore, when making service requests, adaptive scheduling is performed on the client side. The client establishes a resource pool and selects one of the service nodes from multiple available service nodes for invocation. This approach relies on the server and client maintaining communication, requiring numerous and redundant heartbeat messages to keep the client aware of the server's load status, and rate limiting is performed on the client side.

[0043] A device for ensuring high availability of resources in a financial trading system, used to implement the method for high availability of resources in a financial trading system as described above, specifically includes: a client module, a client agent module, a data acquisition module, a backtracking calculation module, a priority identification module, and an execution module. The client and client agent modules belong to the client module, while the data acquisition, backtracking, priority identification, and execution modules belong to the server module. The client and server modules communicate via a network, and the client and server internally interact directly using memory data. The operational relationships between the modules of this system are as follows:

[0044] Step 1: When the client module is running, it sends a call request to the client proxy module;

[0045] Step 2: The client proxy module adds special headers to the call request for special processing. Special fields that frequently appear in the financial transaction system are compressed using a special mapping algorithm to reduce the data transmission size.

[0046] Step 3: The client proxy module specifies a special communication request header based on the client module's request. This request header includes the business module to which the client belongs, the caller's IP address, and the call weight.

[0047] Step 4: After receiving the client's request, the collection module obtains the special request header, records the initial information and business modules entering the server, and marks the arrival time.

[0048] Step 5: The priority identification module divides requests into different resource pools based on the basic information of the request, past call time records, and the proportion of abnormal situations.

[0049] Step Six: The priority identification module passes the request to the execution module, which is responsible for the specific execution of the request and produces a return value.

[0050] Step 7: The data collection module generates the collected data results based on whether errors occurred during the request execution process and the total execution time of the request, and then passes them to the calculation backtracking module.

[0051] Step 8: The calculation backtracking module, based on step 7 of the high availability method for financial transaction system resources, calculates various performance indicators in real time according to the pre-set influence factors within the gradient range and the collection results generated by the collection module, and transmits the output to the priority identification module.

[0052] Step 9: The priority identification module identifies subsequent requests based on output indicators and preset indicator thresholds.

[0053] Furthermore, the specific steps for allocating requests to different resource pools in step five are as follows:

[0054] Step 51: Determine whether the current request exceeds the service limit threshold. If it does not exceed the service limit threshold, directly submit the request to the high-priority resource pool for execution. If it exceeds the service limit threshold, proceed to step 52.

[0055] Step 52: Determine whether the call time of the current specific request exceeds the time consumption threshold generated by the backtracking calculation module. If it does, submit the request to the low-priority resource pool for execution; otherwise, proceed to step 53.

[0056] Step 53: Determine whether the percentage of calls with exceptions for the current specific request exceeds the exception threshold. If it does, deliver the request to the low-priority resource pool for execution; otherwise, proceed to step 54.

[0057] Step 54: Reaching this point indicates that under high load, this request is still a specific request that needs to be resolved as soon as possible and is in good condition. It is then submitted to the high-priority resource pool for execution.

[0058] The beneficial effects of this invention are as follows:

[0059] Compared with Solution 1, this invention has the advantages of high real-time performance and low cost. Solution 1 relies on multi-node deployment to achieve high availability design, while this invention does not rely on redundant machines. Under the condition of limited resources, it can provide services to the outside world to the greatest extent while maintaining service stability and availability.

[0060] Compared with Solution 2, this invention has higher performance and availability. Solution 2 relies on manually setting static service thresholds for each service node, while this invention comprehensively determines the upper limit threshold by combining past service data and local load, thus maximizing performance and availability. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of the high availability method for financial transaction system resources and related device architecture of the present invention;

[0062] Figure 2 This is a schematic diagram illustrating how the present invention divides requests into different resource pools for processing. Detailed Implementation

[0063] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0064] This invention provides a method for high availability of resources in a financial trading system. Here, we first introduce a basic traffic calculation formula:

[0065] When the service is stable, concurrency = queuing latency * number of requests processed per second;

[0066] When the service is not overloaded, concurrency and the number of requests processed per second are linearly related.

[0067] When the service is overloaded, concurrency and queuing latency will increase together, while the number of requests processed per second will tend to stabilize.

[0068] This shows that when a service is overloaded and on the verge of collapse, queuing latency and concurrency will both increase.

[0069] Please see Figure 1 This application provides a method for high availability of financial transaction system resources, which is applied to a financial transaction system consisting of a client module, a client agent module, a data acquisition module, a backtracking calculation module, a priority identification module, and an execution module.

[0070] Based on this theory, this invention proposes the following method for processing requests: After assigning a special request header to the request to be sent, it is sent to the server; during server operation, the request processing resource pool is isolated and divided into high-priority and low-priority resource pools; after receiving a client request, the server obtains the special request header, records the initial information and business module entering the server, and marks the arrival time; the request is assigned to different resource pools for processing, prioritizing the use of resources in the low-priority resource pool; after the request is fully executed, the result of the request processing is fed back to the calculation module, which performs backtracking calculations on the data to support subsequent resource allocation: improving the service capacity of a single node under high-traffic environments to achieve high availability under limited resource conditions. Specifically:

[0071] Step 1: When a request is sent through the client, it carries a pre-defined special communication request header, which includes the business module to which the request belongs, the caller's IP address, and the call weight.

[0072] Step 2: After assigning a special request header to the request to be sent, send it to the server;

[0073] Step 3: During server operation, the resource pool for processing requests is isolated by dividing it into high-priority and low-priority resource pools to achieve complete isolation at the resource level. Different resource pools contain different numbers of resources, with the high-priority resource pool accommodating more processing resources.

[0074] Step 4: After receiving the client's request, the server obtains the special request header, records the initial information and business module entering the server, and marks the arrival time;

[0075] Step 5: Based on the basic information of the request, past call time records, and the proportion of abnormal cases, the request is divided into different resource pools for processing. The specific operation is as follows:

[0076] Step 5.1: Set the influence factors α1, α2, α3…α x …ɑ n ;

[0077] Step 5.2: Set the exception call thresholds β1, β2, β3…β x …β n ;

[0078] Step 5.3: Set the total time consumption θ1, θ2, θ3…θ within each data acquisition cycle. x …θ n ;

[0079] Step 5.4: Set the total number of calls φ1, φ2, φ3…φ within each data collection cycle. x …φ n ;

[0080] Step 5.5:

[0081] Step 5.6:

[0082] Step 5.7: When the time taken for past calls exceeds the time threshold, the request is classified as low priority;

[0083] Step 5.8: When the number of past abnormal calls exceeds the abnormal call threshold, the request is determined to be of low priority;

[0084] Step 6: Allow preemptive resource allocation. When a request is assigned to a high priority pool, if the low priority resource pool is not busy, the low priority resource pool will be preempted to provide service.

[0085] Step 7: After the request is fully executed, the result of the request processing is fed back to the calculation module. The calculation module performs backtracking calculations on the data to support subsequent resource allocation.

[0086] Step 7.1: Set the sampling period;

[0087] Step 7.2: Cumulative number of requests processed within the period;

[0088] Step 7.3: Accumulate the number of request exceptions within the period;

[0089] Step 7.4: Calculate the average request time and queuing delay;

[0090] Step 7.5: After each sampling period, observe the relationship between the number of requests processed and the queuing delay;

[0091] Step 7.6: When the number of requests processed and the queuing delay continue to rise in the same direction, record the number of requests processed within this sampling period and set it as the service upper limit threshold;

[0092] The key point of this invention is a complete set of algorithms and processes for server-side request processing. This set of algorithms provides dynamic threshold protection and bottlenecks for the server's performance limits.

[0093] In this approach, when a service request is made, adaptive scheduling is performed on the client side. The client establishes a resource pool and selects one of the service nodes from multiple available service nodes for invocation. This approach relies on the server and client to maintain communication, requiring numerous redundant communications such as heartbeat messages to keep the client aware of the server load. Rate limiting is then implemented on the client side.

[0094] like Figure 1 As shown, attached Figure 1 This diagram illustrates the components and data flow of a high-availability resource system, showcasing the overall system's processing methods. The system comprises a client module, a client agent module, a data acquisition module, a backtracking calculation module, a priority assessment module, and an execution module. The operational relationships between these modules are as follows:

[0095] Step 1: When the client module is running, it sends a call request to the client proxy module;

[0096] Step 2: The client proxy module adds special headers to the call request for special processing. Special fields such as StockCode (stock code) and ClientId (user ID) that frequently appear in financial trading systems are compressed using a special mapping algorithm to reduce the data transmission size.

[0097] Step 3: The client proxy module specifies a special communication request header based on the client module's request. This request header includes the business module to which the client belongs, the caller's IP address, and the call weight.

[0098] Step 4: After receiving the client's request, the collection module obtains the special request header, records the initial information and business modules entering the server, and marks the arrival time.

[0099] Step 5: The priority assessment module classifies requests into different resource pools based on basic request information, past call duration records, and the percentage of exceptions. See the documentation for detailed assessment steps. Figure 2 ;

[0100] Step Six: The priority identification module passes the request to the execution module, which is responsible for the specific execution of the request and produces a return value.

[0101] Step 7: The data collection module generates the collected data results based on whether errors occurred during the request execution process and the total execution time of the request, and then passes them to the calculation backtracking module.

[0102] Step 8: The calculation backtracking module, based on step 7 of the high availability method for financial transaction system resources, calculates various performance indicators in real time according to the pre-set impact factors within the gradient range of 10 requests, 100 requests, 200 requests, etc., combined with the collection results generated by the collection module, and transmits the output to the priority identification module.

[0103] Step 9: The priority identification module identifies subsequent requests based on output indicators and preset indicator thresholds.

[0104] like Figure 2 As shown, Figure 2 This invention illustrates how requests are divided into different resource pools for processing. The specific steps are as follows:

[0105] Step (1): Determine whether the current processing request exceeds the service limit threshold. If it does not exceed the service limit threshold, the request will be directly delivered to the high-priority resource pool for execution. If it exceeds the service limit threshold, proceed to step (2).

[0106] Step (2): Determine whether the call time of the current specific request exceeds the time consumption threshold generated by the backtracking calculation module. If it does, submit the request to the low-priority resource pool for execution; otherwise, proceed to step (3).

[0107] Step (3): Determine whether the proportion of call exceptions for the current specific request exceeds the exception threshold. If it does, deliver the request to the low-priority resource pool for execution; otherwise, proceed to step (4).

[0108] Step (4): Execution to this point indicates that under high load, the request is still a specific request that needs to be resolved as soon as possible and has a good call status, and is submitted to the high-priority resource pool for execution.

[0109] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention should be determined by the appended claims.

Claims

1. A method for high availability of resources in a financial transaction system, characterized in that, Based on the basic flow calculation formula, the following processing request method is realized: Step 1, when the request is sent through the client, a preset communication request header is carried, which includes the business module, the calling party IP, and the calling weight; Step 2, after assigning the communication request header to the request to be sent, it is sent to the server; Step 3, during the operation of the server, the processing request resource pool is isolated, and the resource pool is divided into high and low priority resource pools, realizing complete isolation at the resource level. Different resource pools contain different numbers of resources, and the high priority resource pool accommodates more processing resources; Step 4, after the server receives the client request, the communication request header is obtained, the initial information entering the server and the business module are recorded, and the arrival time is marked; Step 5, according to the basic information of the request and the past calling time consumption record, the abnormal situation proportion, the request is divided into different resource pools for processing, the specific operation is as follows: Step 5.1: Setting Influence Factors , , … … ; Step 5.2: Set the proportion of exception calls β 1, β 2, β 3… β x … β n ; Step 5.3: Set the total elapsed time of the call within each cycle of acquisition θ 1, θ 2, θ 3… … ; Step 5.4: Set the total number of calls in each cycle of the collection , , … … ; Step 5.5: Past call duration = ; Step 5.6: Abnormal call proportion in the past = ; Step 5.7: when the past calling time > time threshold, the request is determined as low priority; Step 5.8: when the past abnormal calling proportion > abnormal calling threshold percentage, the request is determined as low priority; Step 6, allow preemptive occupation of resources, when a request is divided into high priority, if the low priority resource pool is not in busy state, preferentially preempt the resources of low priority resource pool for service; Step 7, after the request is completely executed, the request processing result is fed back to the calculation module, and the calculation module performs backtracking calculation on the data to support subsequent resource allocation: Step 7.1: set the sampling period; Step 7.2: accumulate the number of processing requests in the period; Step 7.3: accumulate the number of request exceptions in the period; Step 7.4: calculate the average time consumption and queue delay of the request; Step 7.5: every time a sampling period passes, observe the relationship between the number of processing requests and the queue delay; Step 7.6: when the number of processing requests and the queue delay keep rising in the same trend, record the number of processing requests in this sampling period, and set it as the service upper limit threshold.

2. The financial transaction system resource high availability method of claim 1, wherein, The basic flow calculation formula is: When the service is stable, the concurrency = queue delay × number of processing requests per second; When the service is not overloaded, the concurrency and the number of processing requests per second are linearly related; When the service is overloaded, the concurrency and the queue delay will rise together, and the number of processing requests per second tends to be stable; Therefore, when the service processing is overloaded and is at the brink of collapse, the queue delay and the concurrency will rise together.

3. The financial transaction system resource high availability method of claim 1, wherein, When the service requests, the client does adaptive scheduling, the client establishes a resource pool, selects one of the multiple optional service nodes for calling, such a scheme will rely on the communication between the server and the client, and needs to keep the perception of the client to the load of the server through the heartbeat message, and does flow limiting in the client.

4. A financial transaction system resource high availability apparatus, characterized by, The application discloses a financial transaction system resource high-availability method, and belongs to the technical field of computer software. The method comprises the following steps of: when the client module runs, sending a calling request to the client agent module; the client agent module adds a header to the calling request and processes the calling request; for frequently-occurring fields in the financial transaction system, a mapping algorithm is used for compression processing to reduce the data transmission size; the client agent module specifies a communication request header according to the request of the client module, and the communication request header comprises a business module, a calling party IP and a calling weight; after the server receives the client request, the acquisition module acquires the communication request header, records the initial information entering the server and the business module, and marks the arrival time; the priority identification module divides the request into different resource pools according to the basic information of the request, the past calling time consumption record and the abnormal situation proportion; the priority identification module delivers the request to the execution module, and the execution module is responsible for the specific execution of the request and outputs a return value; the acquisition module generates acquisition data results according to whether an error occurs in the request execution process and the total request execution time consumption, and delivers the acquisition data results to the calculation backtracking module; the calculation backtracking module calculates various performance indexes in real time according to the influence factors preset in the gradient range and the acquisition results generated by the acquisition module, and outputs the performance indexes to the priority identification module; and the priority identification module identifies subsequent requests according to the output indexes and preset index threshold values. The specific steps of dividing the request into different resource pools in step five are as follows: step 51, determining whether the current processing request exceeds a service upper limit threshold value; if the current processing request does not exceed the service upper limit threshold value, the request is directly delivered to a high-priority resource pool for execution; if the current processing request exceeds the service upper limit threshold value, the method proceeds to step 52; step 52, determining whether the calling time consumption of the current request exceeds a time consumption threshold value generated by the backtracking calculation module; if the calling time consumption of the current request exceeds the time consumption threshold value, the request is delivered to a low-priority resource pool for execution; otherwise, the method proceeds to step 53; step 53, determining whether the calling abnormality proportion of the current request exceeds an abnormality threshold value; if the calling abnormality proportion of the current request exceeds the abnormality threshold value, the request is delivered to the low-priority resource pool for execution; otherwise, the method proceeds to step 54; step 54, indicating that the request is still a request that needs to be solved as soon as possible and has a good calling condition under high pressure load, and the request is delivered to the high-priority resource pool for execution. ​ ​ ​ ​ ​ ​ ​ 5. The financial transaction system resource high availability apparatus of claim 4, wherein, ​ ​ ​ ​ ​

Images