Network service acceleration method and system applied to security transaction service platform

Abstract

The invention provides a network service acceleration method and system applied to a security transaction service platform, and the method comprises the steps: firstly obtaining a security transaction request set sent by a user terminal in a transaction period, enabling each transaction request unit to comprise a request type identifier, a timestamp and content data, and then carrying out the classification according to the request type identifier to generate a priority queue, the method comprises the following steps: determining a queue ordering rule according to a timestamp, dynamically screening a proper service node group from a pre-established distributed service node cluster, mapping and binding the proper service node group with a priority queue, distributing request units to corresponding service node groups in batches according to the ordering rule to execute transaction operation, generating a response data packet, and returning the response data packet to a user terminal. And when the service node group executes the operation, the load state parameters are updated in real time and synchronized to the global load monitoring module, so that the network service acceleration performance of the security transaction service platform is effectively improved, and efficient transaction is ensured.

Description

Technical Field

[0001] The present invention relates to the field of network communication technology, and in particular to a network service acceleration method and system applied to a securities trading service platform. Background Art

[0002] In the context of the booming securities market today, the trading volume carried by securities trading service platforms is increasing, and users are increasingly demanding trading efficiency and response speed. The timeliness and accuracy of securities trading have a vital impact on investors' decisions and returns.

[0003] At present, the traditional network service mode of securities trading service platform faces many challenges in dealing with high-concurrency trading requests. On the one hand, there is a lack of comprehensive and detailed classification and processing mechanism for trading requests sent by user terminals. The existing processing method often simply processes them in the order of receipt, without fully considering the differences in urgency and importance of different types of trading business, resulting in some key trading requests not being processed in time due to the backlog of a large number of ordinary requests, affecting trading timing and user experience.

[0004] On the other hand, there are obvious deficiencies in the allocation and management of service nodes. Most traditional methods use fixed service node allocation strategies, and do not dynamically adjust according to the real-time load status of service nodes. As a result, during peak trading periods, some service nodes may be overloaded, resulting in a decrease in processing speed or even system crashes, while other nodes fail to fully function, resulting in a waste of resources and seriously affecting the operating efficiency and stability of the entire securities trading service platform.

[0005] In addition, the existing technology lacks a reasonable sorting and batch allocation strategy in the process of allocating transaction requests; the request allocation is relatively arbitrary, and does not comprehensively consider the characteristics of the transaction requests and the carrying capacity of the service nodes, which makes the execution of transaction operations lack systematicity and efficiency, resulting in a long transaction response time, and cannot meet the securities market's demand for fast and accurate transactions. Summary of the invention

[0006] In view of the above-mentioned problems, in combination with the first aspect of the present invention, an embodiment of the present invention provides a network service acceleration method applied to a securities trading service platform, the method comprising: Acquire a securities trading request set sent by a user terminal during a trading period, wherein the securities trading request set includes a plurality of trading request units, each of which includes a request type identifier, a request timestamp, and request content data; Classify the transaction request units according to the request type identifier, generate priority queues matching different transaction business types, and determine a sorting rule within each priority queue based on the request timestamp; Dynamically select a service node group that meets the current load status from a pre-established distributed service node cluster, and map and bind the service node group to the priority queue; Allocating the transaction request units to corresponding service node groups in batches based on the sorting rule to perform transaction operations, generating transaction response data packets, and returning the transaction response data packets to the user terminal; When executing a transaction operation, the service node group updates its own load status parameters in real time and synchronizes them to the global load monitoring module of the distributed service node cluster.

[0007] On the other hand, an embodiment of the present invention also provides a network service acceleration system applied to a securities trading service platform, including a processor and a machine-readable storage medium, wherein the machine-readable storage medium is connected to the processor, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to implement the above method.

[0008] Based on the above aspects, the embodiment of the present application obtains the securities trading request set within the trading period of the user terminal, and generates a priority queue based on the classification processing of the request type identifier, and determines the sorting rules in combination with the request timestamp, which can accurately and reasonably prioritize and arrange the trading requests of different types and times in order, avoiding the confusion and disordered processing of requests that may occur in the traditional processing method, ensuring that important and urgent trading requests can be processed first, and greatly improving the pertinence and timeliness of trading request processing. Secondly, the service node group that meets the current load status is dynamically selected from the pre-established distributed service node cluster, and it is mapped and bound to the priority queue, realizing the intelligent allocation of service node resources. The distributed service node cluster can dynamically select the appropriate service node group to process the request according to the real-time load status of each node, avoiding the imbalance problem of some nodes being overloaded and some nodes being idle, improving the resource utilization and processing efficiency of the entire cluster, and also ensuring that the trading operation can be efficiently executed on the node with appropriate load. Furthermore, based on the sorting rules, the trading request units are allocated to the corresponding service node group in batches to perform trading operations, and the trading response data packets are generated in time and returned to the user terminal, realizing the consistency and efficiency of trading request processing. When executing trading operations, the service node group updates its own load status parameters in real time and synchronizes them to the global load monitoring module, further strengthening the system's adaptive capabilities, enabling the distributed service node cluster to continuously optimize the selection and allocation of service nodes according to the real-time changing load conditions. In other words, through the above steps, the network service acceleration performance of the securities trading service platform is significantly improved, transaction delays are effectively reduced, user experience and transaction efficiency are improved, and the stable operation and efficient service of the securities trading service platform in a high-concurrency and complex trading environment are guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 It is a schematic diagram of the execution flow of a network service acceleration method applied to a securities trading service platform provided by an embodiment of the present invention.

[0010] Figure 2 It is a schematic diagram of the hardware architecture of a network service acceleration system applied to a securities trading service platform provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0011] The present invention will be described in detail below with reference to the accompanying drawings. Figure 1 It is a flow chart of a network service acceleration method applied to a securities trading service platform provided by an embodiment of the present invention. The network service acceleration method applied to a securities trading service platform is introduced in detail below.

[0012] Step S110, obtaining a securities trading request set sent by a user terminal during a trading period, wherein the securities trading request set includes a plurality of trading request units, each of which includes a request type identifier, a request timestamp, and request content data.

[0013] In this embodiment, for a certain securities trading service platform, during the trading period from 9:00 to 11:30 a.m. on a busy trading day, many investors send securities trading requests to the securities trading service platform through their respective user terminals (such as smart phones or computers with trading software installed). Take an investor named Mr. Li as an example. He uses the securities trading software on his mobile terminal to conduct stock trading operations. His mobile terminal is a user terminal.

[0014] In detail, Mr. Li first wants to buy a company's stock. He enters the relevant trading instructions on the trading software interface, including the stock code, purchase quantity, etc. When he clicks the confirmation button, the user terminal will generate a transaction request unit. In this transaction request unit, the request type identifier may be "stock buy", which is used to make it clear that this is a request to buy stocks; the request timestamp accurately records the time when he clicks the confirmation button, such as "2024-09-1510:15:30"; the request content data includes the specific stock code (assuming that it is the stock code of ABC Company "ABC123"), the purchase quantity (100 shares) and his securities account identifier and other information.

[0015] At the same time, during this trading period, many other investors are also conducting different types of securities trading operations, such as stock selling, fund subscription, bond trading, etc. Each trading operation of each investor will generate a similar transaction request unit on their respective user terminals. These transaction request units together constitute a securities trading request set and are sent to the securities trading service platform. For example, another investor, Ms. Zhang, wants to sell a fund share she holds. The request type in her transaction request unit is marked as "fund selling", the request timestamp records the exact time of her operation, and the request content data includes information such as the fund code, the number of shares sold, and her own securities account identifier.

[0016] Step S120, classifying the transaction request units according to the request type identifier, generating priority queues matching different transaction service types, and determining a sorting rule within each priority queue based on the request timestamp.

[0017] After receiving many transaction request units, they are first classified and processed. For example, for the previously mentioned stock purchase request of Mr. Li and fund sale request of Ms. Zhang, the request content data in the transaction request unit is first parsed to extract the associated securities account identifier, transaction target code and operation type field.

[0018] Assume that the rules for determining the risk level parameter based on the operation type field are as follows: if the stock purchase operation involves a large amount or a stock with large fluctuations, the risk level is relatively high; while the risk level of the fund selling operation is relatively low. The ABC company stock purchased by Mr. Li was determined to be at a high risk level due to the recent market fluctuations. Assume that the risk level parameter is 3 (risk level 1-5, 5 is the highest risk). The fund sold by Ms. Zhang is a relatively stable money fund, so the risk level parameter is 1.

[0019] At the same time, the real-time risk control evaluation results can be generated in combination with the historical transaction frequency data corresponding to the securities account identifier. Mr. Li is an active investor with a high historical transaction frequency, but his account asset size is large and his past transaction record is good. After comprehensive evaluation, although he purchased stocks with large fluctuations this time, his real-time risk control evaluation results still meet the preset risk threshold (assuming that the preset risk threshold is a risk level of no more than 4). Therefore, his transaction request unit is marked as the first priority type and inserted into the head of the priority queue of the corresponding business type (stock trading business type). This is because the platform hopes to give priority to transactions that meet the risk threshold and may bring greater benefits or impacts.

[0020] Since Ms. Zhang has a low risk level and relatively simple transactions, the real-time risk control assessment results also meet the preset risk threshold. However, since her transaction risk level is low, the delay tolerance can be calculated based on the difference between the request timestamp and the current system time. Assuming that the current system time is 10:20:00, Ms. Zhang's request timestamp is 10:18:00, and the difference is 2 minutes. According to the delay tolerance calculation rules set by the platform (for example, the delay tolerance is 1 unit every 10 minutes), her delay tolerance is 0.2 units. Based on this delay tolerance, her transaction request unit can be inserted into the specified position in the priority queue of the fund transaction business type. The specified position may be determined based on the delay tolerance of other transaction request units already in the queue. For example, if there are other earlier fund selling requests with lower delay tolerance, her request will be ranked later.

[0021] Then, a dynamic weight value can be generated based on the operation type field and delay tolerance of the transaction request unit in each priority queue. For the stock trading priority queue, since Mr. Li's transaction is high-risk and first-priority type, the operation type is to buy stocks with large fluctuations, and the delay tolerance is low (assuming it is 0.1 units, because he hopes to complete the transaction as soon as possible to obtain a better price), his dynamic weight value may be higher. For the fund trading priority queue, Ms. Zhang's transaction risk is low, the delay tolerance is 0.2 units, the operation type is to sell stable funds, and her dynamic weight value is relatively low. Therefore, the execution order of the sorting rules is adjusted based on these dynamic weight values, so that resources can be arranged more reasonably when the transaction request units are subsequently allocated to the service node group.

[0022] Step S130: dynamically select a service node group that meets the current load status from the pre-established distributed service node cluster, and map and bind the service node group to the priority queue.

[0023] In this embodiment, the securities trading service platform pre-establishes a distributed service node cluster, which includes multiple service nodes, each of which has its own computing resources, network resources, etc. The global load monitoring module of the securities trading service platform monitors the status of each service node in real time.

[0024] Assume that the global load monitoring module records the real-time resource occupancy rate, network throughput and task processing delay parameters of each service node. For example, the real-time resource occupancy rate of service node A is 30% (indicating the proportion of its CPU, memory and other resources occupied), the network throughput is 100Mbps (the amount of data that can be processed per second), and the task processing delay parameter is 50ms (the average time required to process a task); the real-time resource occupancy rate of service node B is 50%, the network throughput is 80Mbps, and the task processing delay parameter is 80ms.

[0025] The platform constructs the availability score of the service node based on the real-time resource utilization and network throughput. Assume that the calculation rule of the availability score is: availability score = (1-real-time resource utilization) × network throughput. According to this rule, the availability score of service node A is (1-0.3) × 100 = 70, and the availability score of service node B is (1-0.5) × 80 = 40. If the preset threshold is 50, then service node B will be eliminated because its availability score is lower than the preset threshold.

[0026] The remaining service nodes (such as service node A, etc.) are divided into a delay optimization node group and a high throughput node group according to the task processing delay parameter. Assuming that the delay optimization node group is the node with a task processing delay parameter lower than 60ms, and the high throughput node group is the node with a higher network throughput (assuming it is higher than 90Mbps), then a mapping relationship table with the priority queue is established.

[0027] Since Mr. Li's stock purchase request was previously marked as the first priority type and was at the head of the stock trading priority queue, the platform binds the delay optimization node group to the stock trading priority queue and allocates a preset number (assuming 2) of redundant nodes as fault-tolerant backups. This is because the stock purchase operation may be urgent for Mr. Li and needs to be processed as soon as possible and to ensure the reliability of the transaction, the delay optimization node group can process the transaction request faster, and the redundant node can take over the task in time when a failure occurs.

[0028] As for the fund transaction priority queue where Ms. Zhang's fund selling request is located, since it only contains the second priority type of transaction request units, the high-throughput node group can be bound to the priority queue, and the task allocation ratio within the node group can be adjusted based on the previously calculated dynamic weight value. For example, if there are multiple fund selling requests, according to the dynamic weight value of each request (such as Ms. Zhang's relatively low dynamic weight value), the tasks are reasonably allocated within the high-throughput node group, and the low dynamic weight value may be allocated a relatively small share of resources.

[0029] Step S140: Allocate the transaction request units to corresponding service node groups in batches based on the sorting rule to perform transaction operations, generate transaction response data packets, and return the transaction response data packets to the user terminal.

[0030] When executing a transaction operation, the service node group updates its own load status parameters in real time and synchronizes them to the global load monitoring module of the distributed service node cluster.

[0031] In detail, still taking the above example, for Mr. Li's stock purchase request, first calculate the number of transaction request units that can be processed in a single batch according to the resource capacity limit of the service node group (delay optimization node group). Assuming that the resource capacity limit of the delay optimization node group is 5 transaction request units per batch, according to the previously determined sorting rules (Mr. Li's request is at the head of the stock transaction priority queue and has a higher dynamic weight value), extract Mr. Li's transaction request unit from the stock transaction priority queue.

[0032] The extracted transaction request units are then encapsulated into standardized task instructions, and a communication protocol header matching the service node group is added. For example, the communication protocol header contains information such as the address and port number of the target service node, so that the task instruction can be accurately sent to the corresponding service node.

[0033] The standardized task instruction is sent to the service node group through the predefined transmission channel. During the sending process, a unique transaction serial number (assuming it is 12345) is assigned to this standardized task instruction in the predefined transmission channel, and the mapping relationship between the transaction serial number and Mr. Li's user terminal is recorded. The standardized task instruction is split into multiple data fragments (assuming it is split into 3 data fragments), and error correction coding and fragment serial numbers (such as 1, 2, 3) are added to each data fragment.

[0034] A multi-path parallel transmission strategy is used to send data shards to the service node group. Obtain the bandwidth utilization, delay parameters, and stability scores of all available transmission paths in the current network topology. For example, the bandwidth utilization of path 1 is 40%, the delay parameter is 30ms, and the stability score is 80 points (out of 100 points); the bandwidth utilization of path 2 is 30%, the delay parameter is 20ms, and the stability score is 90 points. Since the size of the data shard is small and more urgent (because it is a stock purchase request), path 2 is selected as the main transmission path, and an independent transmission path identifier is assigned to each data shard.

[0035] On the service node group side, a data shard cache is set up to temporarily store the received data shards according to the transaction serial number. Assume that the service node group first receives the data shard with shard sequence number 2 and stores it in the cache waiting for other shards. Reorganization and integrity verification are performed on the receiving end according to the shard sequence number. If all data shards are correctly received and reorganized, a security audit is performed on the reorganized standardized task instructions, including verification of digital signatures and checking of instruction format compliance. After the security audit passes, the task is submitted to the execution queue to execute the transaction operation.

[0036] During the execution of transaction operations, the service node group updates its own load status parameters in real time, such as resource occupancy rate, number of tasks processed, etc., and synchronizes them to the global load monitoring module of the distributed service node cluster.

[0037] When the transaction operation is completed, the service node group generates transaction result data. Assuming that Mr. Li's stock purchase transaction is successful, the transaction result data includes information such as the number of stocks purchased and the transaction price. The platform matches the transaction result data with the session identifier of Mr. Li's user terminal and encapsulates it into a transaction response data packet. It is routed to Mr. Li's user terminal through the content distribution network. After receiving the transaction response data packet, Mr. Li's mobile terminal displays information about the successful transaction, including the number of stocks purchased and the transaction price.

[0038] Ms. Zhang's fund selling request is also processed in a similar process. The number of transactions that can be processed in a single batch is calculated based on the resource capacity of the high-throughput node group, and her transaction request units are extracted according to the sorting rules, encapsulated into standardized task instructions and sent to the service node group, which executes the transaction operation, generates a transaction response data packet and returns it to her user terminal, informing her of the results of the fund selling transaction, such as the sold shares, transaction amount, and other information.

[0039] Based on the above steps, the embodiment of the present application obtains the securities trading request set within the trading period of the user terminal, and generates a priority queue based on the classification processing of the request type identifier, and determines the sorting rules in combination with the request timestamp, which can accurately and reasonably prioritize and arrange the trading requests of different types and times in order, avoiding the confusion and disordered processing of requests that may occur in the traditional processing method, ensuring that important and urgent trading requests can be processed first, and greatly improving the pertinence and timeliness of trading request processing. Secondly, the service node group that meets the current load status is dynamically selected from the pre-established distributed service node cluster, and it is mapped and bound to the priority queue, realizing the intelligent allocation of service node resources. The distributed service node cluster can dynamically select the appropriate service node group to process the request according to the real-time load status of each node, avoiding the imbalance problem of some nodes being overloaded and some nodes being idle, improving the resource utilization and processing efficiency of the entire cluster, and also ensuring that the trading operation can be efficiently executed on the node with appropriate load. Furthermore, based on the sorting rules, the trading request units are allocated to the corresponding service node group in batches to perform trading operations, and the trading response data packets are generated in time and returned to the user terminal, realizing the consistency and efficiency of trading request processing. When executing trading operations, the service node group updates its own load status parameters in real time and synchronizes them to the global load monitoring module, further strengthening the system's adaptive capabilities, enabling the distributed service node cluster to continuously optimize the selection and allocation of service nodes according to the real-time changing load conditions. In other words, through the above steps, the network service acceleration performance of the securities trading service platform is significantly improved, transaction delays are effectively reduced, user experience and transaction efficiency are improved, and the stable operation and efficient service of the securities trading service platform in a high-concurrency and complex trading environment are guaranteed.

[0040] In a possible implementation, step S120 includes: Step S121, parsing the request content data in the transaction request unit, extracting the securities account identifier, transaction subject code and operation type field associated with the transaction request unit.

[0041] Step S122, determining the risk level parameter of the transaction request unit according to the operation type field, and generating a real-time risk control assessment result in combination with the historical transaction frequency data corresponding to the securities account identifier.

[0042] Step S123: If the real-time risk control assessment result meets the preset risk threshold, the transaction request unit is marked as a first priority type and inserted into the head of the priority queue of the corresponding business type.

[0043] Step S124, if the real-time risk control assessment result does not meet the preset risk threshold, the delay tolerance is calculated according to the difference between the request timestamp and the current system time, and the transaction request unit is inserted into the specified position of the priority queue based on the delay tolerance.

[0044] Step S125 , generating a dynamic weight value according to the operation type field and delay tolerance of the transaction request unit in each priority queue, and adjusting the execution order of the sorting rules based on the dynamic weight value.

[0045] In the previously set securities trading scenarios, such as investor Mr. Li buying stocks and Ms. Zhang selling funds, the relevant technical steps are further explained.

[0046] In this embodiment, after the securities trading service platform receives the transaction request units sent by many investors during the trading period, it carries out detailed processing for each transaction request unit. Taking Mr. Li's stock purchase transaction request unit as an example, the request content data is first parsed to accurately extract the securities account identifier associated with the transaction request unit. This securities account identifier is the unique identity identifier registered by Mr. Li on the platform, which is used to distinguish the accounts of different investors; the transaction target code, that is, the code "ABC123" of the ABC company stock he wants to buy; and the operation type field, which is clearly a stock purchase operation here. Similarly, for Ms. Zhang's fund sale request unit, her securities account identifier, fund code, and operation type of fund sale will also be extracted.

[0047] Next, the risk level parameter of the transaction request unit is determined according to the operation type field. For the ABC company stock purchased by Mr. Li, due to the frequent and large price fluctuations of the company's stock in the market recently, according to the risk assessment rules preset by the platform, this stock purchase operation is determined to have a high risk level parameter, assuming that it is assessed as 3 (the risk level parameter range is set to 1-5, 5 represents the highest risk). The fund sold by Ms. Zhang is a relatively stable money fund, and its risk level parameter is determined to be 1 according to the platform rules. While determining the risk level parameter, the platform will also generate a real-time risk control assessment result in combination with the historical transaction frequency data corresponding to the securities account identifier. Mr. Li is a relatively active investor on the platform, and his historical transaction frequency is relatively high. Although the risk of the stock purchased this time is relatively high, considering the large asset scale of his account and the past transaction records showing that he has a certain risk tolerance and good transaction credit, after combining these factors, the platform concludes that Mr. Li's real-time risk control assessment result meets the preset risk threshold (assuming that the preset risk threshold is set to a risk level of no more than 4). Therefore, Mr. Li's transaction request unit is marked as the first priority type and inserted into the head of the priority queue of the corresponding business type, that is, the stock trading business type.

[0048] In the case of Ms. Zhang, since her fund selling operation risk level is relatively low, and the platform has found that her historical transaction frequency is relatively low and the account asset size is medium based on her securities account ID, her real-time risk control assessment results also meet the preset risk threshold after comprehensive evaluation. However, since her transaction risk level is low and does not reach the high priority level like Mr. Li, the platform will calculate the delay tolerance based on the difference between her request timestamp and the current system time. Assume that Ms. Zhang's request timestamp is "2024-09-1510:18:00", and the current system time is "2024-09-1510:20:00", and the difference between the two is 2 minutes. According to the calculation rules set by the platform (for example, the delay tolerance is 1 unit every 10 minutes), her delay tolerance is 0.2 units. Based on this delay tolerance, the platform inserts her transaction request unit into the designated position in the priority queue of the fund trading business type. The designated position is determined based on the delay tolerance of other transaction request units already in the queue. If there are other fund selling requests before her with a lower delay tolerance, her request will be ranked later.

[0049] After that, the dynamic weight value is generated according to the operation type field and delay tolerance of the transaction request unit in each priority queue. In the stock trading priority queue, Mr. Li's transaction is a stock buy operation, with a risk level of 3 and a low delay tolerance (assuming 0.1 units, because he hopes to complete the transaction as soon as possible to obtain a better price). According to the platform's dynamic weight value calculation rules (for example, the higher the risk level and the lower the delay tolerance, the higher the dynamic weight value), his dynamic weight value is relatively high. In the fund trading priority queue, Ms. Zhang's transaction is a fund sell operation, with a risk level of 1 and a delay tolerance of 0.2 units. According to the rules, her dynamic weight value is relatively low. The platform adjusts the execution order of the sorting rules based on these dynamic weight values. For example, when subsequently allocating transaction request units to service node groups, if resources are limited, transaction request units with high dynamic weight values ​​will be given priority to ensure that more important, more urgent or higher-risk transactions can be processed first.

[0050] In a possible implementation, step S130 includes: Step S131, obtaining the real-time resource occupancy rate, network throughput and task processing delay parameters of each service node recorded in the global load monitoring module.

[0051] Step S132: constructing an availability score of a service node according to the real-time resource occupancy rate and the network throughput, and eliminating service nodes whose availability score is lower than a preset threshold.

[0052] Step S133: dividing the remaining service nodes into a delay optimization node group and a high throughput node group according to the task processing delay parameter, and establishing a mapping relationship table with the priority queue.

[0053] Step S134: if the priority queue contains a transaction request unit of the first priority type, the delay optimization node group is bound to the priority queue, and a preset number of redundant nodes are allocated as fault-tolerant backups.

[0054] Step S135, if the priority queue only contains transaction request units of the second priority type, the high-throughput node group is bound to the priority queue, and the task allocation ratio within the node group is adjusted based on the dynamic weight value, wherein the priority of the first priority type is higher than the priority of the second priority type.

[0055] In this embodiment, the distributed service node cluster of the securities trading service platform includes multiple service nodes, and the global load monitoring module continuously monitors each service node and records the real-time resource occupancy rate, network throughput, and task processing delay parameters of each service node. For example, the real-time resource occupancy rate of service node A is 30%, which means that the proportion of its CPU, memory and other computing resources currently occupied is 30%; the network throughput is 100Mbps, which means that 100 megabits of data can be processed per second; the task processing delay parameter is 50ms, which means that it takes an average of 50 milliseconds to process a task. Looking at service node B again, its real-time resource occupancy rate is 50%, the network throughput is 80Mbps, and the task processing delay parameter is 80ms.

[0056] The availability score of the service node is constructed based on the real-time resource utilization and network throughput. Assume that the availability score calculation rule set by the platform is: availability score = (1-real-time resource utilization) × network throughput. According to this rule, the availability score of service node A is (1-0.3) × 100 = 70, and the availability score of service node B is (1-0.5) × 80 = 40. If the preset threshold is set to 50, then service node B will be eliminated from the range of selectable service nodes because its availability score is lower than the preset threshold.

[0057] The remaining service nodes (such as service node A, etc.) are divided into a delay optimization node group and a high throughput node group according to the task processing delay parameters. Assume that the platform sets the delay optimization node group as the node with a task processing delay parameter lower than 60ms, and the high throughput node group is the node with a higher network throughput (assuming it is higher than 90Mbps). According to this standard, if service node A meets the standard of the delay optimization node group, it will be divided into this group. Then the platform establishes a mapping relationship table with the priority queue.

[0058] Since Mr. Li's stock purchase request is marked as the first priority type and is at the head of the stock trading priority queue, the platform binds the delay optimization node group to the stock trading priority queue and allocates a preset number (assuming 2) of redundant nodes as fault-tolerant backup. This is because the stock purchase operation may be urgent for Mr. Li and needs to be processed as soon as possible and the reliability of the transaction must be guaranteed. The delay optimization node group can process the transaction request faster, and the redundant node can take over the task in time when a failure occurs.

[0059] As for the fund transaction priority queue where Ms. Zhang's fund selling request is located, since it only contains the second priority type of transaction request units, the platform binds the high-throughput node group to the priority queue and adjusts the task allocation ratio within the node group based on the previously calculated dynamic weight value. For example, there are multiple service nodes in the high-throughput node group that can be used to process fund selling requests. According to the dynamic weight value of each request (such as Ms. Zhang's relatively low dynamic weight value), tasks are reasonably allocated within the high-throughput node group, and those with low dynamic weight values ​​may be allocated relatively fewer resource shares. For example, if there are 10 service nodes in the high-throughput node group and the total resource share is 100, according to the dynamic weight value calculation, Ms. Zhang's transaction request may only be allocated 10 resource shares, while other fund selling requests with higher dynamic weight values ​​may be allocated more resource shares, so as to ensure the rationality and efficiency of overall resource allocation.

[0060] Based on the above steps, it is possible to effectively utilize service node resources while meeting different transaction needs, thereby improving the overall operating efficiency of the securities trading service platform and the accuracy and timeliness of transaction processing.

[0061] In a possible implementation, step S140 includes: Step S141, according to the resource capacity limit of the service node group, calculate the number of transaction request units that can be processed in a single batch, and extract the corresponding number of transaction request units from the priority queue according to the sorting rule.

[0062] Let's continue to use Mr. Li's stock purchase request and Ms. Zhang's fund sale request as examples. First, in terms of the service node group, the delay optimization node group to which Mr. Li's stock purchase request is assigned has certain resource capacity restrictions. Assume that the resource capacity limit of this delay optimization node group is that 5 transaction request units can be processed per batch. According to the previously determined sorting rules, Mr. Li's transaction request is at the head of the stock transaction priority queue and has a higher dynamic weight value, so Mr. Li's transaction request unit is extracted from the stock transaction priority queue. For Ms. Zhang's fund sale request, the high-throughput node group in which it is located is assumed to be able to process 8 transaction request units per batch, and the corresponding transaction request unit is extracted from the fund transaction priority queue according to the sorting rules (her dynamic weight value and other factors).

[0063] Step S142, encapsulating the extracted transaction request unit into a standardized task instruction, and adding a communication protocol header that matches the service node group.

[0064] For Mr. Li's stock purchase request unit, the stock code "ABC123", the purchase quantity of 100 shares, his securities account ID and other information contained therein can be encapsulated in a predetermined format. And add a communication protocol header that matches the delay optimization node group. This communication protocol header contains key information such as the address and port number of the target service node, so that the task instruction can be sent to the corresponding service node accurately. Similarly, a similar encapsulation operation is performed for Ms. Zhang's fund sale request unit, and a communication protocol header that matches the high-throughput node group is added.

[0065] Step S143: sending the standardized task instruction to the service node group through a predefined transmission channel, and monitoring the intermediate processing status signal returned by the service node group.

[0066] For example, in this process, for the standardized task instruction of Mr. Li's stock purchase request, a unique transaction serial number, such as 12345, is assigned to it in the predefined transmission channel, and the mapping relationship between this transaction serial number and Mr. Li's user terminal is recorded. The standardized task instruction is split into multiple data slices, assuming that it is split into 3 data slices, and error correction coding and slice sequence numbers 1, 2, and 3 are added to each data slice. The data slices are sent to the service node group using a multi-path parallel transmission strategy. During the sending process, the bandwidth utilization, delay parameters, stability scores and other information of all available transmission paths in the current network topology are obtained. For example, the bandwidth utilization of path 1 is 40%, the delay parameter is 30ms, and the stability score is 80 points; the bandwidth utilization of path 2 is 30%, the delay parameter is 20ms, and the stability score is 90 points. Since Mr. Li's stock purchase request is more urgent and the data slices are smaller, path 2 is selected as the main transmission path, and an independent transmission path identifier is assigned to each data slice. Similar operations are performed for Ms. Zhang's fund selling request, except that a suitable transmission path is selected according to the characteristics of her request and the network conditions.

[0067] Step S144: if the intermediate processing status signal indicates that the task execution is abnormal, the fault-tolerant backup node is triggered to take over the unfinished standardized task instructions and reallocate them to the redundant nodes for execution.

[0068] For example, if the intermediate processing status signal corresponding to Mr. Li's stock purchase request indicates that the task execution is abnormal, such as a service node failure or network connection interruption, the fault-tolerant backup node is triggered to take over the unfinished standardized task instructions. Since two redundant nodes were previously assigned to Mr. Li's transaction request as fault-tolerant backups, these redundant nodes will reallocate the unfinished tasks and execute them according to the predetermined rules. If a similar abnormal situation occurs in Ms. Zhang's fund selling request, there will also be a corresponding fault-tolerant processing mechanism.

[0069] Step S145, receiving the transaction result data returned by the service node group, matching the transaction result data with the session identifier of the user terminal, encapsulating the data into a transaction response data packet, and routing it to the user terminal through the content distribution network.

[0070] For example, for Mr. Li's stock purchase request, assuming that the transaction is successful, the transaction result data returned by the service node group includes the number of stocks purchased (100 shares), the transaction price and other information. The platform matches these transaction result data with the session identifier of Mr. Li's user terminal, and then encapsulates them into a transaction response data packet. It is routed to Mr. Li's mobile terminal through the content distribution network. After receiving this transaction response data packet, Mr. Li's mobile terminal displays information about the successful transaction, including the number of stocks purchased and the transaction price. For Ms. Zhang's fund sale request, when the service node group returns the transaction result data, such as the sale share, transaction amount and other information, it is also matched with her user terminal session identifier and encapsulated into a transaction response data packet, and then sent to her terminal through the content distribution network. Her terminal displays the relevant transaction result information of the fund sale. In this way, the entire process from transaction request to transaction response is completed, ensuring that securities transactions can be completed accurately and efficiently in a complex system environment.

[0071] In a possible implementation, after step S140, the method further includes: Step S150, parsing the execution result code in the transaction response data packet, and if an abnormal state of transaction failure is detected based on the execution result code, extracting the abnormal type code and the associated securities account identifier.

[0072] Step S160, matching a corresponding compensation operation instruction from a preset fault recovery strategy library according to the exception type code, and generating a retry task request including the compensation operation instruction.

[0073] Step S170: adding the retry task request to an emergency processing channel independent of the priority queue, and allocating it to the delay optimization node group for priority execution.

[0074] Step S180, when the retry task request is successfully executed, the execution result code in the transaction response data packet is updated, and a transaction compensation log is generated and synchronized to the user terminal and the associated clearing system.

[0075] Step S190: adjust the risk control assessment parameters corresponding to the securities account identifier according to the transaction compensation log, and feed back to the global load monitoring module to optimize the subsequent task allocation strategy.

[0076] In a possible implementation, step S190 includes: Step S191, parsing the abnormal operation time interval, abnormal triggering times and associated securities account identifiers recorded in the transaction compensation log to extract the abnormal transaction times and abnormal type distribution data accumulated by the securities account identifier within a preset period.

[0077] Step S192, matching corresponding risk weight increment values ​​and risk level transition conditions from a preconfigured risk factor adjustment rule table based on the anomaly type distribution data, wherein the risk factor adjustment rule table contains risk weight increment values ​​and risk level transition conditions corresponding to different anomaly type codes.

[0078] Step S193, generating an initial risk coefficient correction value of the securities account identifier according to the product relationship between the number of abnormal triggering times and the risk weight increment value, and performing time attenuation compensation calculation on the initial risk coefficient correction value in combination with the density parameter of the abnormal operation time interval.

[0079] Step S194, superimpose the risk coefficient correction value after time attenuation compensation calculation with the benchmark risk value in the current risk control assessment parameter to generate an updated dynamic risk threshold, and detect whether the dynamic risk threshold reaches the level boundary value defined in the risk level transition condition.

[0080] Step S195, if it is detected that the dynamic risk threshold crosses the level boundary value, a risk level reclassification operation is triggered, the risk level mark of the securities account identifier is upgraded or downgraded to the target level, and the maximum concurrent transaction volume limit parameter corresponding to the target level is locked.

[0081] Step S196, reconstructing the risk control assessment parameter set of the securities account identifier according to the risk level mark and the maximum concurrent transaction volume limit parameter, and writing the risk control assessment parameter set into the real-time strategy storage area of ​​the distributed risk control database.

[0082] Step S197, extracting the latest risk control assessment parameter set from the real-time policy storage area of ​​the distributed risk control database, generating a parameter update event notification, and pushing the parameter update event notification to the task allocation policy engine of the global load monitoring module.

[0083] Step S198, loading the latest risk control assessment parameter set in the task allocation strategy engine, replacing the original historical risk control assessment parameters, and recalculating the priority weight factor of the securities account identifier in the subsequent transaction request unit according to the maximum concurrent transaction volume limit parameter.

[0084] Step S199, injecting the recalculated priority weight factor into the generation logic of the dynamic weight value, so that the transaction request unit subsequently initiated by the securities account identifier reflects the updated risk control strategy in the sorting rules in the priority queue.

[0085] Step S1910, establish a risk status tracking link for the securities account identifier in the global load monitoring module, capture the operation type field of the subsequent transaction request unit of the securities account in real time, and compare the captured operation type field with the risk level mark in real time to trigger dynamic interception or release operations.

[0086] In this embodiment, based on the previous securities trading scenarios, such as Mr. Li's stock buying transaction and Ms. Zhang's fund selling transaction related operations, the subsequent steps are further explained.

[0087] After the transaction response data packet is returned to the user terminal, taking Mr. Li's stock purchase transaction as an example, if the execution result code in the transaction response data packet received by Mr. Li's mobile terminal shows that the transaction failed, then the execution result code can be parsed. Once the abnormal state of transaction failure is detected based on the execution result code, the abnormal type code and the associated Mr. Li's securities account identifier can be further extracted. Assuming that Mr. Li's transaction failed due to insufficient funds (corresponding to an abnormal type code), the corresponding compensation operation instruction can be matched from the preset fault recovery strategy library based on this abnormal type code. For the case of insufficient funds, the compensation operation instruction may be to check whether Mr. Li has other available sources of funds or whether partial transactions can be performed, etc., and then generate a retry task request containing this compensation operation instruction. The retry task request will be added to an emergency processing channel independent of the previous priority queue, and because this situation that may affect the user experience and transaction process needs to be handled as soon as possible, it will be assigned to the delay optimization node group for priority execution.

[0088] When this retry task request is executed successfully, for example, Mr. Li successfully completes the stock purchase transaction by adjusting the source of funds, the execution result code in the transaction response data packet can be updated to a successful transaction, and a transaction compensation log is generated. The transaction compensation log contains information such as the abnormal operation time interval (such as the specific time period when the transaction failed), the number of abnormal triggers (this time is 1 time), and the associated Mr. Li’s securities account ID. The transaction compensation log will be synchronized to Mr. Li’s user terminal so that he can view the details of the transaction failure and successful retry. It will also be synchronized to the associated clearing system for operations such as account verification and settlement processing.

[0089] Then, adjust the risk control assessment parameters corresponding to Mr. Li's securities account ID according to the transaction compensation log. First, parse the abnormal operation time interval, abnormal trigger times, and the associated Mr. Li's securities account ID recorded in the transaction compensation log, so as to extract the abnormal transaction times and abnormal type distribution data accumulated by Mr. Li's securities account ID within the preset period (assuming one month). Assume that within this month, this is the first time that Mr. Li's transaction failed due to insufficient funds, and the abnormal type is a fund abnormality. Based on the abnormal type distribution data, the corresponding risk weight increment value and risk level transition condition can be matched from the pre-configured risk factor adjustment rule table. In the risk factor adjustment rule table, the risk weight increment value corresponding to the abnormal type code of insufficient funds may be 0.5 (assumed value), and the risk level transition condition may be when the risk factor reaches 3, the current risk level is upgraded to a higher risk level (assuming the current risk level is 2).

[0090] Then, based on the product relationship between the number of abnormal triggers and the incremental value of the risk weight, the initial risk coefficient correction value of Mr. Li's securities account identification is generated. Since the number of abnormal triggers is 1 and the incremental value of the risk weight is 0.5, the initial risk coefficient correction value is 0.5. Combined with the density parameter of the abnormal operation time interval, the initial risk coefficient correction value is calculated for time decay compensation. Assuming that the abnormal operation time interval is short and the density parameter is 0.8 (indicating that the impact is relatively small), the risk coefficient correction value after time decay compensation calculation is 0.5*0.8=0.4. This risk coefficient correction value after time decay compensation calculation is superimposed with the benchmark risk value in the current risk control assessment parameters (assuming that the current benchmark risk value is 2) to generate an updated dynamic risk threshold of 2+0.4=2.4.

[0091] Check whether this dynamic risk threshold reaches the level boundary value defined in the risk level transition condition. Since 2.4 does not reach 3, the risk level reclassification operation will not be triggered. However, if in subsequent transactions, Mr. Li encounters other abnormal situations that cause the dynamic risk threshold to cross the level boundary value, for example, reaching 3, then the risk level reclassification operation will be triggered. If it is an upgrade, the platform will upgrade the risk level mark of Mr. Li's securities account identification from 2 to target level 3, and lock the maximum concurrent transaction volume limit parameter corresponding to target level 3 (assuming a maximum of 5 transactions each time, while the previous risk level 2 may be a maximum of 10 transactions each time).

[0092] The risk control evaluation parameter set of Mr. Li's securities account identifier is reconstructed according to the new risk level mark and the maximum concurrent transaction volume limit parameter. The risk control evaluation parameter set includes risk level, maximum concurrent transaction volume limit, risk coefficient and other related parameters. Then the risk control evaluation parameter set is written into the real-time strategy storage area of ​​the distributed risk control database. The latest risk control evaluation parameter set is extracted from the real-time strategy storage area of ​​the distributed risk control database, a parameter update event notification is generated, and this parameter update event notification is pushed to the task allocation strategy engine of the global load monitoring module.

[0093] The latest risk control assessment parameter set is loaded into the task allocation strategy engine to replace the original historical risk control assessment parameters. In addition, the priority weight factor of Mr. Li's securities account identifier in the subsequent transaction request unit is recalculated according to the maximum concurrent transaction volume limit parameter. For example, due to the reduction of the maximum concurrent transaction volume limit, Mr. Li's priority weight factor may be reduced accordingly. The recalculated priority weight factor is injected into the generation logic of the dynamic weight value, so that the transaction request unit subsequently initiated by Mr. Li reflects the updated risk control strategy in the sorting rules in the priority queue. For example, if Mr. Li sells stocks later, the sorting in the stock transaction priority queue will change due to the new risk control strategy, and may be relatively backward.

[0094] In the global load monitoring module, a risk status tracking link for Mr. Li's securities account identification is established to capture the operation type field of the subsequent transaction request unit of Mr. Li's securities account in real time. For example, if Mr. Li subsequently performs a high-risk stock purchase operation, this operation type field can be compared with his risk level mark 3 in real time. If the risk of this operation type exceeds the range that his current risk level can bear, a dynamic interception operation will be triggered to prevent the transaction from proceeding; if it is within the risk tolerance range, the operation will be released to allow the transaction to proceed normally. In this way, through a series of operations, after the transaction is abnormal, not only a compensation operation is performed, but also the relevant risk control assessment parameters are adjusted, which in turn affects the subsequent transaction processing strategy, ensuring the stability, security and rationality of the entire securities trading system.

[0095] For Ms. Zhang's fund selling transaction, if similar transaction failures and subsequent processing occur, they will also be processed according to the same process, but the various parameters and specific processing logic will be adjusted accordingly according to her transaction type, account status, and corresponding abnormal type. For example, if her fund selling transaction failed because the fund shares were frozen (corresponding to another abnormal type code), when matching the compensation operation instructions from the fault recovery strategy library, it will be a processing operation for the fund share freeze, such as checking the cause of the freeze and trying to unfreeze, etc. Subsequent risk assessment parameter adjustments and other operations will also be performed based on the rules and data related to fund transactions.

[0096] In a possible implementation, before step S110, the method further includes: Step S210, establishing a long connection communication link between the user terminal and the securities trading service platform, and configuring a two-way heartbeat detection mechanism to maintain the link active state.

[0097] In a possible implementation, step S210 includes: Step S211, establishing a first heartbeat signal generator on the user terminal side, for sending a heartbeat request packet to the securities trading service platform at a fixed interval, wherein the heartbeat request packet includes a current terminal timestamp and a network status indicator.

[0098] In this embodiment, taking Mr. Li as an example, when he is preparing to conduct securities trading, a long-connection communication link needs to be established between the mobile terminal (user terminal) he uses and the securities trading service platform. The long-connection communication link can be understood as a continuously open dedicated channel for data interaction during the transaction process. In order to ensure that this communication link is always active and that possible problems with the link can be discovered in a timely manner, a two-way heartbeat detection mechanism is configured.

[0099] In detail, the first heartbeat signal generator is built into the trading software on Mr. Li's mobile terminal, which can send heartbeat request packets to the securities trading service platform at fixed intervals, which can be sent every 30 seconds (this is based on the rules set by the platform). The heartbeat request packet contains the current terminal timestamp, such as "2024-09-1510:00:00", which accurately records the time when the heartbeat request packet was sent, and also contains network status indicators, which may include the type of current mobile network (such as 4G or 5G), network signal strength (specific value in decibels), and the estimated bandwidth of the current network (such as 10Mbps).

[0100] Step S212, establishing a second heartbeat signal generator on the securities trading service platform side, which is used to respond to the heartbeat request packet and return a heartbeat response packet, wherein the heartbeat response packet includes a platform timestamp and a link quality assessment result.

[0101] For example, the second heartbeat signal generator is used to respond to the heartbeat request packet sent by Mr. Li's mobile terminal. When the heartbeat request packet is received, a heartbeat response packet will be returned immediately. The heartbeat response packet contains a platform timestamp, such as "2024-09-1510:00:05" (here it is assumed that there is a certain time delay in processing the heartbeat request packet), and the link quality assessment result. The link quality assessment result is obtained by the platform based on the network status indicators in the received heartbeat request packet and the platform's own network monitoring data. For example, if Mr. Li's mobile network signal strength is high and the bandwidth is stable, the platform may give a link quality assessment result of "good"; if the network fluctuates or the signal strength is slightly weak, the assessment result may be "average".

[0102] Step S213: If the user terminal does not receive the heartbeat response packet within a preset timeout window, a link self-repair process is started to gradually reduce the data transmission rate and try to re-establish the connection.

[0103] For example, if Mr. Li's mobile terminal does not receive a heartbeat response packet within the preset timeout window, the link self-repair process will be started. Assuming the preset timeout window is 60 seconds, when Mr. Li's mobile terminal does not receive a response packet after this time, the mobile terminal will gradually reduce the data transmission rate and try to re-establish the connection. Reducing the data transmission rate may be from the current 10Mbps to 5Mbps, and then trying to send a heartbeat request packet again to re-establish the connection. This is because there may be temporary network congestion or some minor faults on the platform side. By reducing the transmission rate, the network pressure can be reduced and the success rate of re-establishing the connection can be increased.

[0104] Step S214: If the securities trading service platform detects abnormal network status indicators within multiple consecutive heartbeat cycles, a link optimization suggestion is sent to the user terminal, and the link optimization suggestion includes switching to a designated access point or enabling data compression mode.

[0105] For example, if the securities trading service platform detects abnormal network status indicators in multiple consecutive heartbeat cycles, it will send link optimization suggestions to Mr. Li's mobile terminal. Assuming that Mr. Li's mobile network bandwidth is detected to be unstable and the signal strength fluctuates greatly in 3 consecutive heartbeat cycles (each cycle is 30 seconds), link optimization suggestions can be sent to his mobile terminal. The link optimization suggestion may be to switch to a specified access point. For example, if a base station with a more stable signal is detected nearby, it is recommended that Mr. Li's mobile phone switch to the access point corresponding to this base station; or enable data compression mode to reduce the amount of data transmission by compressing the transaction data, thereby improving transmission efficiency in an unstable network environment.

[0106] Step S215, recording the interaction logs of all heartbeat request packets and heartbeat response packets, and generating a link health report based on the interaction logs to guide the dynamic optimization of the transmission path.

[0107] During the whole process, the interaction logs of all heartbeat request packets and heartbeat response packets can be recorded. The interaction logs record in detail the sending time of each heartbeat request packet, the network status indicators contained, the return time of the corresponding heartbeat response packet, the link quality evaluation results and other information. Based on this interaction log, a link health report can be generated. The link health report can intuitively reflect the status of the link in different time periods. For example, the link quality is good in some time periods, but may fluctuate in other time periods. Based on the link health report, the dynamic optimization of the transmission path can be guided. For example, if it is found that a certain access point often experiences a decrease in link quality in a specific time period, the platform can adjust the routing strategy to prevent users like Mr. Li from using this access point during this time period, thereby improving the overall trading experience.

[0108] Step S220: receiving the encrypted identity credentials uploaded by the user terminal through the long connection communication link, and calling the distributed identity authentication node cluster to decrypt and verify the legitimacy of the encrypted identity credentials.

[0109] For example, when Mr. Li opens the securities trading software on his mobile phone and tries to log in, his mobile terminal will send his encrypted identity credentials to the securities trading service platform through a long connection communication link. The encrypted identity credentials are generated by Mr. Li when he registered a securities account, and contain his account information, personal identity information and other encrypted content. Then, after receiving this encrypted identity credential, the distributed authentication node cluster is called for processing. The distributed authentication node cluster contains multiple verification nodes, each of which has corresponding decryption and verification functions. These verification nodes work together to decrypt the encrypted identity credentials, obtain the original identity information, and then perform a legitimacy check. The legitimacy check will check whether Mr. Li's account exists, whether it is in a normal state, and whether the identity information is consistent with the registration information.

[0110] Step S230: If the legality check passes, a temporary session identifier and an access permission token are allocated to the user terminal, and the access permission token is embedded into the protocol header of all subsequent transaction request units.

[0111] For example, if the legitimacy check passes, a temporary session identifier and access permission token can be assigned to Mr. Li's mobile terminal. The temporary session identifier is an identifier that uniquely identifies Mr. Li's mobile terminal during this trading session, such as a random string of numbers and letters "ABC123DEF456". The access permission token is a credential used to authorize Mr. Li to perform specific operations during this session, and the access permission token will be embedded in the protocol header of all subsequent transaction request units of Mr. Li. For example, when Mr. Li later buys stocks, the protocol header in his transaction request unit will contain this access permission token, so that the platform can quickly verify Mr. Li's permissions when processing transaction requests.

[0112] Step S240, monitor the signal strength and packet loss rate of the long connection communication link in real time. If it is detected that the signal strength is lower than a preset threshold or the packet loss rate exceeds a tolerance range, switch to the backup transmission path and renegotiate the encryption parameters.

[0113] For example, during the transaction process, the signal strength and packet loss rate of the long-connection communication link are monitored in real time. In detail, the signal strength and packet loss rate information of the long-connection communication link are obtained in real time through network monitoring equipment and related software algorithms. If it is detected that the signal strength is lower than the preset threshold or the packet loss rate exceeds the tolerance range, it will switch to the backup transmission path and renegotiate the encryption parameters. Assume that the preset threshold is -80dBm (signal strength) and the tolerance range is that the packet loss rate does not exceed 5%. If Mr. Li moves to an area with weaker signals during the transaction, the platform detects that the signal strength drops to -90dBm and the packet loss rate reaches 8%, then the platform will automatically switch to the backup transmission path. The backup transmission path may be another network connection channel pre-set by the platform, such as switching from the current 4G network to the Wi-Fi network (if available). At the same time, since different transmission paths may have different security requirements, encryption parameters can be renegotiated. Renegotiating encryption parameters may include selecting different encryption algorithms, adjusting encryption keys, and other operations to ensure the security of data on the new transmission path.

[0114] Step S250, at the end of the transaction period, close the persistent communication link and clear the temporary session identifier, and transfer the unfinished transaction request unit to the offline task pool for asynchronous processing.

[0115] In this embodiment, at the end of the trading period, for example, after the end of the securities trading period of the day (such as 9 am to 3 pm), the long connection communication link can be closed and the temporary session identifier can be cleared. Closing the long connection communication link can be understood as closing the previously established dedicated channel and releasing related network resources. Cleaning the temporary session identifier is to ensure that a new unique identifier is regenerated at the next transaction to ensure the security and independence of the transaction. At the same time, the unfinished transaction request unit is transferred to the offline task pool for asynchronous processing. If Mr. Li has a stock selling transaction request unit that has not been completed at the end of the trading period, the transaction request unit will be transferred to the offline task pool. In the offline task pool, these unfinished transaction request units can be processed in the background according to certain rules and order, for example, they may be processed according to market conditions, transaction priorities and other factors, and the processing results will be fed back to Mr. Li's mobile terminal or perform corresponding account adjustments and other operations.

[0116] Ms. Zhang will also go through the same process when selling funds. From establishing a long-connection communication link, performing identity authentication, obtaining a temporary session identifier and access permission token, to monitoring link status, processing unfinished transactions, etc., all operations follow the same mechanism and rules. There will only be individual differences in the specific transaction request content, identity information, and network status, but the overall processing flow and logic remain consistent. This ensures that the entire securities trading system can be carried out efficiently, safely, and orderly in terms of pre-trading preparations, link maintenance during the transaction, and post-trading cleanup and unfinished transaction processing.

[0117] In a possible implementation, the operations performed by the global load monitoring module include: Step S310, periodically collect the CPU usage rate, memory occupancy rate and disk input and output rate of each service node in the distributed service node cluster.

[0118] In this embodiment, in the previously mentioned securities trading scenarios, for example, when Mr. Li performs a stock buying operation and Ms. Zhang performs a fund selling operation, in the daily operation of securities trading, for each service node, the collection operation is performed according to a fixed time period, for example, once every 5 minutes. Taking service node A as an example, the CPU usage rate collected at a certain moment is 30%, which means that at this moment, 30% of the CPU resources of service node A are being used; the memory occupancy rate is 40%, indicating that 40% of its memory resources are occupied; the disk input and output rate is 50MB / s, which reflects the data reading and writing speed of the disk at this moment. By performing such a collection operation on each service node in the distributed service node cluster, the resource usage of the entire cluster can be obtained.

[0119] Step S320, input the collected resource indicators into the pre-trained resource prediction model to generate a load trend prediction curve for each service node in a future preset time period.

[0120] Assuming that the preset time period is the next hour, the resource indicators of service node A collected are input into the resource prediction model, which is obtained through a previous training process and can analyze the load trend of service node A in the next hour based on the input current resource indicator data. For example, it is predicted that in the next 10 minutes, the CPU usage rate may gradually rise to 40%, the memory occupancy rate will remain at around 40%, and the disk input and output rate may drop to 30MB / s, and a load trend prediction curve is generated based on the predicted values ​​at different time points. The load trend prediction curve can intuitively show the load change trend of service node A in the next hour. The same prediction operation is performed on other service nodes to obtain the load trend prediction of the entire distributed service node cluster.

[0121] Step S330, dynamically scaling the service node according to the load trend prediction curve, wherein the dynamic scaling operation includes automatically scaling the virtual node instance before the load peak is reached, or releasing idle node resources when the load reaches a valley value.

[0122] For example, if it is found in the load trend prediction curve that service node A is about to reach its load peak in 30 minutes, for example, the CPU utilization rate will reach 80%, close to its load limit, then the virtual node instance will be automatically expanded before the load peak arrives. This may be done by creating a new virtual computing resource in a cloud computing environment and associating it with service node A to share the upcoming high-load tasks. On the contrary, if it is predicted that service node B will be in a load valley in the next period of time, for example, the CPU utilization rate continues to be less than 10% and the memory occupancy rate is also low, then the idle node resources will be released. This means that the unused computing resources, memory resources, etc. on service node B will be recycled, which may be to shut down some unnecessary processes or release the free memory space to other service nodes in need, so as to improve the resource utilization of the entire distributed service node cluster.

[0123] Step S340: When it is detected that the resource index of any service node continues to exceed the safety threshold, an alarm event is triggered and the service node is marked as unavailable, and the unfinished tasks of the service node are migrated to an adjacent service node.

[0124] For example, suppose that the CPU usage of service node C exceeds the safety threshold of 85% for 10 minutes. At this time, the global load monitoring module will trigger an alarm event, which will be sent to the system management terminal and the notification system of the relevant operation and maintenance personnel to inform them that the service node C has a resource overload. At the same time, the service node C is marked as unavailable to avoid further assigning new tasks to this overloaded service node. Then, the unfinished tasks of service node C are migrated to adjacent service nodes, such as service node D. The process of migrating tasks needs to ensure the integrity and correctness of the tasks, which may involve operations such as data transmission and synchronization of task status to ensure that the transaction business can continue normally in the event of problems with service node C.

[0125] Step S350: Aggregate the operating status data of all service nodes to generate a global load heat map, and push the global load heat map to the management terminal for visual monitoring.

[0126] For example, the global load monitoring module collects operating status data such as the CPU usage rate, memory occupancy rate, disk input and output rate, and whether it is in an available state for each service node. Then a global load heat map is generated based on this data. In this global load heat map, different colors or brightness can represent different load levels, such as red for high load and green for low load. The operation and maintenance personnel of the management terminal can intuitively see the load distribution of the entire distributed service node cluster, and quickly locate the service nodes with high load or problems, so as to take corresponding measures in time for optimization and adjustment.

[0127] For example, in a possible implementation, the training step of the resource prediction model includes: Step S410, obtaining original monitoring data of the CPU usage, memory occupancy and disk input / output rate at continuous timestamps recorded by the distributed service node cluster in a historical operation cycle, and forming a historical resource indicator data set.

[0128] For example, during the long-term operation of the securities trading system, each service node will record its own resource usage, and these records carry timestamps. For example, from January 1, 2024 to June 30, 2024, service node A records the CPU usage, memory occupancy, and disk input and output rate every 5 minutes every day. These large amounts of data with precise time stamps constitute the original monitoring data. Collecting these original monitoring data from all service nodes forms a historical resource indicator data set.

[0129] Step S420, fill in missing values ​​and filter noise for the historical resource indicator data set to generate cleaned time series resource indicator data, and divide the time series resource indicator data into multiple training sample segments according to a preset time window length, and extract a time series feature set related to the load trend from each training sample segment, wherein the time series feature set includes the mean, variance, peak interval and change slope of the resource indicator.

[0130] For example, in the original historical resource indicator data set, there may be some missing values ​​caused by network failure or acquisition equipment problems, such as the disk input and output rate of service node B at a certain moment is not recorded. Therefore, these missing values ​​are completed through the missing value filling algorithm, such as the mean filling or interpolation filling method. At the same time, there may be some noise caused by measurement errors or other interference factors in the original historical resource indicator data set. These noises are removed by the filtering algorithm to generate the cleaned time series resource indicator data. Assuming that the preset time window length is 1 hour, the cleaned time series resource indicator data is divided into multiple training sample segments according to the preset time window length. For each training sample segment, a set of time series features related to the load trend is extracted from it, such as the mean of the resource indicator, that is, the average value of the CPU usage within this 1 hour; the variance, which reflects the fluctuation of the resource indicator in this time period; the peak interval, that is, the time interval between the two CPU usage peaks; the change slope, such as the rising or falling speed of the CPU usage in this time period.

[0131] Step S430, aligning the time series feature set with the actual load status label in the subsequent preset time period of the corresponding time window to generate a supervised training data set, wherein the actual load status label includes the true values ​​of the CPU usage, memory occupancy and disk input and output rate of the next time window.

[0132] For example, for a 1-hour training sample segment, after the corresponding time series feature set is calculated, the actual values ​​of the CPU usage, memory occupancy, and disk input and output rate in the next 1 hour (preset time period) after this training sample segment are used as the actual load state label. The time series feature set and the corresponding actual load state label are matched one by one, thus generating a supervised training data set. Each sample in the supervised training data set contains input features (time series feature set) and corresponding output labels (actual load state labels), which can be used to train prediction models.

[0133] Step S440, initialize an initial prediction model with a multi-layer neural unit structure, configure the input layer dimension of the initial prediction model to match the number of features of the time series feature set, and configure the output layer dimension to be consistent with the dimension of the actual load state label.

[0134] Assume that the initial prediction model is a multi-layer neural network, for example, including an input layer, a hidden layer, and an output layer. Based on the previously extracted time series feature set, assuming that this time series feature set contains 4 features (mean, variance, peak interval, and change slope), the dimension of the input layer is set to 4 so that these input features can be received. The dimension of the output layer is set to 3 because the actual load status label includes three indicators: CPU usage, memory occupancy, and disk input and output rate. This completes the initial configuration of the initial prediction model.

[0135] Step S450, divide the supervised training data set into a training subset and a validation subset in chronological order, input the training subset into the initial prediction model for forward propagation calculation using a sliding window method, generate predicted load state data, calculate the error loss value between the predicted load state data and the actual load state label, adjust the weight parameters of the initial prediction model based on the error back propagation algorithm, iteratively update until the error loss value converges to a stable interval, and input the validation subset into the updated initial prediction model to generate a validation prediction result, and generate a performance evaluation report based on the difference between the validation prediction result and the actual load state label of the validation subset.

[0136] For example, the supervised training data set is divided into a training subset and a validation subset in a ratio of 80% and 20%. A sliding window method is used to take a certain number of training subset samples each time and input them into the initial prediction model. In the initial prediction model, the data is calculated from the input layer to the output layer after being calculated by the neurons of the hidden layer. This process is the forward propagation calculation, thereby generating the predicted load state data. Then the error loss value between the predicted load state data and the actual load state label is calculated. For example, the mean square error loss function can be used. If the error loss value is large, the weight parameter of the initial prediction model is adjusted based on the error back propagation algorithm. This process will be iterated continuously until the error loss value converges to a stable interval. When the weight parameter is updated to a certain extent, the validation subset is input into the updated initial prediction model to obtain the validation prediction result. The validation prediction result is compared with the actual load state label of the validation subset, for example, the difference between the predicted CPU usage and the actual CPU usage is compared. A performance evaluation report is generated based on these differences. This report can reflect the prediction accuracy, error distribution, etc. of the initial prediction model.

[0137] Step S460, after adjusting the hyperparameter configuration of the initial prediction model according to the error distribution in the performance evaluation report, return to execute the step of dividing the supervised training data set into a training subset and a validation subset in chronological order, inputting the training subset into the initial prediction model for forward propagation calculation using a sliding window method, and generating predicted load status data, until the prediction accuracy in the performance evaluation report reaches a preset threshold, and marking the final trained initial prediction model as the resource prediction model, wherein the hyperparameter configuration includes a learning rate decay strategy, a batch processing size, and a regularization strength.

[0138] For example, if the performance evaluation report shows that the prediction error is large in some cases, such as the prediction of CPU usage has obvious errors under high load conditions, adjust the hyperparameter configuration of the initial prediction model according to this error distribution. Hyperparameter configuration includes learning rate decay strategy, such as adjusting the speed at which the learning rate decreases; batch processing size, changing the number of samples input into the model each time; regularization strength, controlling the complexity of the model to prevent overfitting. After adjusting the hyperparameters, train again according to the previous steps, and repeat this process until the prediction accuracy in the performance evaluation report reaches the preset threshold, such as the prediction error is within 5%. At this time, the final trained initial prediction model is marked as a resource prediction model.

[0139] Step S470, deploy the resource prediction model to the prediction engine of the global load monitoring module, configure the real-time data interface to receive periodically collected resource indicators, and trigger the online reasoning process of the resource prediction model. In addition, during the online reasoning process of the resource prediction model, continuously collect new real-time monitoring data of the CPU usage, memory occupancy and disk input and output rates, and append them to the historical resource indicator data set to start an incremental training loop. In the incremental training loop, according to the temporal continuity of the new real-time monitoring data and the historical resource indicator data set, dynamically expand the time window range of the training sample segment, and update the extraction rules of the temporal feature set.

[0140] For example, after the resource prediction model is deployed to the prediction engine of the global load monitoring module, a real-time data interface is configured. This real-time data interface can receive resource indicators such as the CPU usage rate, memory occupancy rate, and disk input and output rate of the service node collected every 5 minutes. After receiving these data, the online reasoning process of the resource prediction model is triggered, that is, the trained model is used to predict the new data. In this process, new resource indicator data is continuously collected, such as resource usage data in the new trading period, and these new data are appended to the historical resource indicator data set. Due to the addition of new data, according to the temporal continuity of the new real-time monitoring data and the historical resource indicator data set, for example, the new data and the historical data are continuous in time and may reflect the new load mode, the time window range of the training sample segment is dynamically expanded from the original 1 hour to 2 hours. At the same time, according to the new time window range and data characteristics, the extraction rules of the time series feature set are updated, such as adding new features or adjusting the calculation method of the original features.

[0141] Step S480, use the updated training sample segments and time series feature sets to perform rolling retraining on the resource prediction model, generate optimized model parameters that adapt to the latest load pattern, and hot load the optimized model parameters to the prediction engine, establish a model version management mechanism in the prediction engine, retain snapshots of historical versions of resource prediction model parameters, and roll back to the specified version of model parameters when a decrease in prediction accuracy is detected to maintain prediction stability.

[0142] For example, the resource prediction model is trained again using the updated training sample segments and time series feature sets. This process generates optimized model parameters that adapt to the latest load pattern. These optimized model parameters are hot loaded into the prediction engine, that is, the model parameters can be updated without restarting the prediction engine, so that the prediction engine can immediately use the new model parameters for prediction. A model version management mechanism is established in the prediction engine to record snapshots of resource prediction model parameters for each version. If the prediction accuracy is detected to be reduced during the subsequent operation, for example, the predicted load trend deviates greatly from the actual situation, the model parameters of the previously specified version can be rolled back. This specified version may be a version with higher prediction accuracy. In this way, the stability of the prediction is maintained, ensuring that the global load monitoring module can accurately predict the load trend of the service node, thereby effectively performing operations such as resource management and task scheduling, and ensuring the stable operation of the entire securities trading system.

[0143] In a possible implementation, step S143 includes: Step S1431, assigning a unique transaction serial number to each standardized task instruction in the predefined transmission channel, and recording a mapping relationship between the transaction serial number and the user terminal.

[0144] In this embodiment, in the previously set securities trading scenario, such as Mr. Li's stock purchase operation and Ms. Zhang's fund selling operation, taking Mr. Li's stock purchase transaction as an example, when his transaction request unit is encapsulated as a standardized task instruction, a unique transaction serial number is assigned to this task instruction in the predefined transmission channel, assuming it is 56789. At the same time, in the relevant records of the platform, the transaction serial number 56789 is clearly recorded as a mapping relationship with Mr. Li's mobile terminal (user terminal). This mapping relationship record can accurately track the source of the task instruction and the corresponding user terminal in the subsequent processing process, ensuring the accuracy and traceability of transaction processing.

[0145] Step S1432, split the standardized task instruction into multiple data slices, and add an error correction code and a slice sequence number to each data slice.

[0146] For example, for Mr. Li's stock purchase standardized task instruction, assume that it is split into 4 data fragments according to predefined rules. For each data fragment, add error correction code, which is generated according to a specific algorithm and is used to detect and correct possible errors during data transmission. For example, if an error occurs in a byte of a data fragment during transmission, the error correction code can detect and correct the error according to the algorithm to ensure the accuracy of the data. At the same time, add fragment sequence numbers to each data fragment, which are 1, 2, 3, and 4 respectively. These fragment sequence numbers help to reorganize the data fragments in the correct order at the receiving end.

[0147] Step S1433: adopt a multi-path parallel transmission strategy to send the data fragments to the service node group, and reassemble and verify the integrity of the fragments at the receiving end according to the fragment sequence numbers.

[0148] Wherein, step S1433 includes: Step S1433-1, obtaining the bandwidth utilization, delay parameters and stability scores of all available transmission paths in the current network topology.

[0149] In the network environment where the securities trading service platform is located, there are usually multiple available transmission paths. For example, there are path A, path B and path C. For path A, after analysis by network monitoring equipment and related algorithms, its bandwidth utilization is 30%, which means that at the current moment, 70% of the bandwidth of path A is available for data transmission; the delay parameter is 20ms, which means that it takes an average of 20 milliseconds for data to be transmitted back and forth on this path; the stability score is 80 points (out of 100 points), which is obtained by comprehensively considering the stability factors of the network. For example, factors such as the low failure rate and small signal fluctuation of path A in the past period of time make its stability score higher. Similarly, the bandwidth utilization of path B is 40%, the delay parameter is 30ms, and the stability score is 70 points; the bandwidth utilization of path C is 25%, the delay parameter is 15ms, and the stability score is 85 points.

[0150] Step S1433-2: Select the optimal transmission path combination according to the size and urgency of the data fragments, and assign an independent transmission path identifier to each data fragment.

[0151] For example, Mr. Li's stock purchase transaction is relatively urgent because the stock price may change at any time, and the size of his transaction data shard is medium. Based on these factors, the platform selects path C as the main transmission path to transmit data shard 1, because path C has a lower latency parameter and a higher stability score, and can transmit data quickly and stably. For data shard 2, considering that path A may be more suitable for transmitting this data shard although it has a slightly higher latency but lower bandwidth utilization, path A is selected to transmit data shard 2. For data shard 3, path B is selected for transmission. Assign an independent transmission path identifier to each data shard, for example, assign an identifier of C-1 to data shard 1 transmitted on path C, an identifier of A-2 to data shard 2 transmitted on path A, and an identifier of B-3 to data shard 3 transmitted on path B. In this way, the transmission path of each data shard can be accurately identified during the transmission process.

[0152] Step S1433-3, during the transmission process, the transmission quality of each path is monitored in real time. If the delay parameter of a path suddenly increases or the packet loss rate exceeds a preset threshold, the data fragments on the path are dynamically migrated to a backup path.

[0153] For example, suppose that during the transmission of a data shard, network congestion suddenly occurs on path B, causing the delay parameter to increase from 30ms to 100ms, and the packet loss rate also exceeds the preset threshold of 5%. At this time, after the platform detects this situation, it dynamically migrates data shard 3 from path B to the backup path according to the identifier B-3 previously assigned to data shard 3. The backup path may be other available paths that have been evaluated before, such as path D (assuming that its bandwidth utilization is 35%, the delay parameter is 25ms, and the stability score is 80 points). Through this dynamic migration mechanism, it can be ensured that the transmission of data shards will not be interrupted due to the failure of a certain path, thereby improving the reliability of data transmission.

[0154] Step S1433-4, a data shard cache area is set on the service node group side, and the received data shards are temporarily stored according to the transaction serial number until all shards are received.

[0155] When the service node group starts to receive data shards, for example, a service node in the service node group receives a data shard with the identifier C-1, it will store this data shard in the data shard cache according to the transaction serial number 56789. As time goes by, the service node group may successively receive other data shards, such as A-2, B-3, etc., which will be temporarily stored according to the transaction serial number 56789. Only when all the 4 data shards corresponding to the transaction serial number 56789 are received, the next step will be taken.

[0156] Step S1433-5, perform a security audit on the reorganized standardized task instructions, the security audit includes verifying the digital signature and checking the compliance of the instruction format, and submitting it to the execution queue after the security audit passes.

[0157] For example, when the service node group receives all four data shards corresponding to transaction serial number 56789, the data shards are reorganized according to shard serial numbers 1, 2, 3, and 4. The reorganization process combines the data shards in the order of the shard serial numbers to form a complete standardized task instruction. After the reorganization is completed, an integrity check is performed. The integrity check includes checking the integrity of the data, such as checking whether the length of the data is consistent with the original standardized task instruction before splitting, and checking whether there are errors in the data through the error correction code added previously. If the integrity check passes, it means that the received data is complete and correct.

[0158] Step S1434: If the service node group does not return the intermediate processing status signal within a preset time, the unconfirmed data fragments are queried according to the transaction serial number and a retransmission mechanism is triggered.

[0159] For example, after the service node group completes the reorganization and integrity verification of the data shards, a security audit is performed on the reorganized standardized task instructions. The purpose of verifying the digital signature is to ensure that the source of the task instruction is legal and has not been tampered with. The digital signature is generated by the sender (such as the platform-side processing module corresponding to Mr. Li's mobile terminal) using a private key according to a specific algorithm when the task instruction is generated, and the service node group uses the corresponding public key to verify this digital signature. At the same time, check the compliance of the instruction format to ensure that the format of the standardized task instruction meets the format requirements specified by the platform, such as the field order and data type of the instruction are correct. If the security audit passes, it means that the standardized task instruction is legal, complete and correct, and then it is submitted to the execution queue, waiting for the service nodes in the service node group to execute the task instruction in sequence.

[0160] During the entire process, it is necessary to monitor the intermediate processing status signal returned by the service node group. If the service node group does not return the intermediate processing status signal within the preset time, the unconfirmed data shards are queried according to the transaction serial number and the retransmission mechanism is triggered. Assuming that the preset time is 60 seconds, within these 60 seconds, if the platform does not receive the intermediate processing status signal returned by the service node group regarding the standardized task instruction corresponding to the transaction serial number 56789, the platform will query which data shards have not been confirmed to be received by the service node group according to the transaction serial number 56789. For example, if it is found that data shard 4 has not been confirmed to be received, the platform will trigger the retransmission mechanism and resend data shard 4 to the service node group according to the previous multi-path parallel transmission strategy to ensure that the task instruction can be correctly processed by the service node group.

[0161] Step S1435, after receiving confirmation signals from all data fragments, a task reception success notification is sent to the user terminal, and execution timeout countdown monitoring is started.

[0162] For example, when the service node group successfully receives and confirms all data shards corresponding to transaction serial number 56789, the platform will send a task reception success notification to Mr. Li's mobile terminal (user terminal). The task reception success notification is used to inform Mr. Li's mobile terminal that the task instruction corresponding to his stock purchase transaction request has been successfully received by the service node group. At the same time, the execution timeout countdown monitoring is started. The countdown monitoring is to ensure that the service node group completes the execution of the task instruction and returns the transaction result within the specified time. For example, the execution timeout is set to 120 seconds. During these 120 seconds, the execution of the service node group can be continuously monitored. If the transaction result returned by the service node group is not received within the timeout period, appropriate measures are taken, such as further querying the execution status of the service node group or triggering the exception handling process.

[0163] Ms. Zhang's fund selling transaction will also be processed in the same process. After her fund selling transaction request is encapsulated into a standardized task instruction, the same operations will be performed, such as assigning a transaction serial number, splitting data shards, selecting a transmission path, transmitting data shards, receiving end processing, and monitoring intermediate processing status signals. However, the specific parameters and processing logic will be adjusted accordingly according to factors such as her transaction type, data size, and network conditions to ensure that her fund selling transaction can be accurately and efficiently processed in the service node group.

[0164] Figure 2 A schematic diagram of exemplary hardware and software components of a network service acceleration system 100 applied to a securities trading service platform that can implement the concept of the present application provided by some embodiments of the present application is shown. For example, the processor 120 can be used in the network service acceleration system 100 applied to the securities trading service platform and used to perform the functions in the present application.

[0165] The network service acceleration system 100 applied to the securities trading service platform can be a general-purpose server or a special-purpose server, both of which can be used to implement the network service acceleration method applied to the securities trading service platform of the present application. Although only one server is shown in the present application, for convenience, the functions described in the present application can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0166] For example, the network service acceleration system 100 applied to the securities trading service platform may include a network port 110 connected to the network, one or more processors 120 for executing program instructions, a communication bus 130, and storage media 140 in different forms, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the network service acceleration system 100 applied to the securities trading service platform may also include program instructions stored in ROM, RAM, or other types of non-temporary storage media, or any combination thereof. The method of the present application can be implemented according to these program instructions. The network service acceleration system 100 applied to the securities trading service platform also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0167] For ease of explanation, only one processor is described in the network service acceleration system 100 applied to the securities trading service platform. However, it should be noted that the network service acceleration system 100 applied to the securities trading service platform in the present application may also include multiple processors, so the steps performed by one processor described in the present application may also be performed jointly or individually by multiple processors. For example, if the processor of the network service acceleration system 100 applied to the securities trading service platform executes step A and step B, it should be understood that step A and step B may also be performed jointly by two different processors or individually in one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor execute steps A and B together.

[0168] In addition, an embodiment of the present invention further provides a readable storage medium, in which computer executable instructions are preset. When a processor executes the computer executable instructions, the network service acceleration method applied to the securities trading service platform as above is implemented.

[0169] It should be noted that in order to simplify the description of the present invention and thus help understand one or more embodiments of the invention, in the foregoing description of the embodiments of the present invention, various features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A network service acceleration method applied to a securities trading service platform, characterized in that: The method comprises: Acquire a securities trading request set sent by a user terminal during a trading period, wherein the securities trading request set includes a plurality of trading request units, each of which includes a request type identifier, a request timestamp, and request content data; Classify the transaction request units according to the request type identifier, generate priority queues matching different transaction business types, and determine a sorting rule within each priority queue based on the request timestamp; Dynamically select a service node group that meets the current load status from a pre-established distributed service node cluster, and map and bind the service node group to the priority queue; Allocating the transaction request units to corresponding service node groups in batches based on the sorting rule to perform transaction operations, generating transaction response data packets, and returning the transaction response data packets to the user terminal; When executing a transaction operation, the service node group updates its own load status parameters in real time and synchronizes them to the global load monitoring module of the distributed service node cluster.

2. The network service acceleration method applied to the securities trading service platform according to claim 1, characterized in that: The classifying and processing the transaction request units according to the request type identifier, generating priority queues matching different transaction business types, and determining a sorting rule within each priority queue based on the request timestamp, includes: Parsing the request content data in the transaction request unit, extracting the securities account identifier, transaction subject code and operation type field associated with the transaction request unit; Determine the risk level parameter of the transaction request unit according to the operation type field, and generate a real-time risk control assessment result in combination with the historical transaction frequency data corresponding to the securities account identifier; If the real-time risk control assessment result meets the preset risk threshold, the transaction request unit is marked as a first priority type and inserted into the head of the priority queue of the corresponding business type; If the real-time risk control assessment result does not meet the preset risk threshold, the delay tolerance is calculated according to the difference between the request timestamp and the current system time, and the transaction request unit is inserted into the designated position of the priority queue based on the delay tolerance; A dynamic weight value is generated according to the operation type field and delay tolerance of the transaction request unit in each priority queue, and the execution order of the sorting rule is adjusted based on the dynamic weight value.

3. The network service acceleration method applied to the securities trading service platform according to claim 2 is characterized in that: The dynamically selecting a service node group that meets the current load status from the pre-established distributed service node cluster, and mapping and binding the service node group to the priority queue, includes: Obtaining the real-time resource occupancy rate, network throughput and task processing delay parameters of each service node recorded in the global load monitoring module; Build an availability score for the service node based on the real-time resource occupancy rate and the network throughput, and remove service nodes whose availability score is lower than a preset threshold; Dividing the remaining service nodes into a delay optimization node group and a high throughput node group according to the task processing delay parameter, and establishing a mapping relationship table with the priority queue; If the priority queue contains a transaction request unit of the first priority type, the delay optimization node group is bound to the priority queue, and a preset number of redundant nodes are allocated as fault-tolerant backups; If the priority queue only contains transaction request units of the second priority type, the high-throughput node group is bound to the priority queue, and the task allocation ratio within the node group is adjusted based on the dynamic weight value, wherein the priority of the first priority type is higher than the priority of the second priority type.

4. The network service acceleration method applied to the securities trading service platform according to claim 3 is characterized in that: The step of allocating the transaction request units to the corresponding service node groups in batches based on the sorting rule to perform transaction operations, generating transaction response data packets, and returning the transaction response data packets to the user terminal includes: Calculate the number of transaction request units that can be processed in a single batch according to the resource capacity limit of the service node group, and extract a corresponding number of transaction request units from the priority queue according to the sorting rule; Encapsulating the extracted transaction request unit into a standardized task instruction and adding a communication protocol header matching the service node group; Sending the standardized task instruction to the service node group through a predefined transmission channel, and monitoring the intermediate processing status signal returned by the service node group; If the intermediate processing status signal indicates that the task execution is abnormal, the fault-tolerant backup node is triggered to take over the unfinished standardized task instructions and redistribute them to the redundant node for execution; Receive the transaction result data returned by the service node group, match the transaction result data with the session identifier of the user terminal, encapsulate it into a transaction response data packet, and route it to the user terminal through a content distribution network.

5. The network service acceleration method applied to the securities trading service platform according to claim 4 is characterized in that: After the step of returning the transaction response data packet to the user terminal, the method further includes: Parsing the execution result code in the transaction response data packet, and if an abnormal state of transaction failure is detected according to the execution result code, extracting the abnormal type code and the associated securities account identifier; Matching a corresponding compensation operation instruction from a preset fault recovery strategy library according to the exception type code, and generating a retry task request including the compensation operation instruction; Adding the retry task request to an emergency processing channel independent of the priority queue, and allocating it to a delay optimization node group for priority execution; When the retry task request is successfully executed, the execution result code in the transaction response data packet is updated, and a transaction compensation log is generated and synchronized to the user terminal and the associated clearing system; Adjust the risk control assessment parameters corresponding to the securities account identifier according to the transaction compensation log, and feed back to the global load monitoring module to optimize the subsequent task allocation strategy; Wherein, the step of adjusting the risk control assessment parameter corresponding to the securities account identifier according to the transaction compensation log includes: Parsing the abnormal operation time interval, abnormal triggering times and associated securities account identifiers recorded in the transaction compensation log to extract the abnormal transaction times and abnormal type distribution data accumulated by the securities account identifier within a preset period; Based on the abnormal type distribution data, the corresponding risk weight increment value and risk level transition condition are matched from a pre-configured risk factor adjustment rule table, wherein the risk factor adjustment rule table includes risk weight increment values ​​and risk level transition conditions corresponding to different abnormal type codes; Generate an initial risk coefficient correction value of the securities account identifier according to the product relationship between the number of abnormal triggers and the incremental value of the risk weight, and perform time decay compensation calculation on the initial risk coefficient correction value in combination with the density parameter of the abnormal operation time interval; The risk coefficient correction value after time decay compensation calculation is superimposed on the benchmark risk value in the current risk control assessment parameter to generate an updated dynamic risk threshold, and detect whether the dynamic risk threshold reaches the level boundary value defined in the risk level transition condition; If it is detected that the dynamic risk threshold crosses the level boundary value, a risk level reclassification operation is triggered, the risk level mark of the securities account identifier is upgraded or downgraded to the target level, and the maximum concurrent transaction volume limit parameter corresponding to the target level is locked; Reconstruct the risk control evaluation parameter set of the securities account identifier according to the risk level mark and the maximum concurrent transaction volume limit parameter, and write the risk control evaluation parameter set into the real-time strategy storage area of ​​the distributed risk control database; Extracting the latest risk control assessment parameter set from the real-time strategy storage area of ​​the distributed risk control database, generating a parameter update event notification, and pushing the parameter update event notification to the task allocation strategy engine of the global load monitoring module; Loading the latest risk control assessment parameter set in the task allocation strategy engine, replacing the original historical risk control assessment parameters, and recalculating the priority weight factor of the securities account identifier in the subsequent transaction request unit according to the maximum concurrent transaction volume limit parameter; Injecting the recalculated priority weight factor into the generation logic of the dynamic weight value, so that the transaction request unit subsequently initiated by the securities account identifier reflects the updated risk control strategy in the sorting rule in the priority queue; A risk status tracking link of the securities account identifier is established in the global load monitoring module, the operation type field of the subsequent transaction request unit of the securities account is captured in real time, and the captured operation type field is compared with the risk level mark in real time to trigger dynamic interception or release operations.

6. The network service acceleration method applied to the securities trading service platform according to claim 1, characterized in that: Before obtaining the securities trading request set sent by the user terminal during the trading period, the method further includes: Establishing a long-connection communication link between the user terminal and the securities trading service platform, and configuring a two-way heartbeat detection mechanism to maintain the link active; Receiving the encrypted identity credentials uploaded by the user terminal through the long connection communication link, and calling the distributed identity authentication node cluster to decrypt and verify the legitimacy of the encrypted identity credentials; If the legality check passes, a temporary session identifier and an access rights token are allocated to the user terminal, and the access rights token is embedded into the protocol header of all subsequent transaction request units; Monitor the signal strength and packet loss rate of the long connection communication link in real time, and if it is detected that the signal strength is lower than a preset threshold or the packet loss rate exceeds a tolerance range, switch to an alternative transmission path and renegotiate encryption parameters; At the end of the transaction period, the long connection communication link is closed and the temporary session identifier is cleared, and the unfinished transaction request unit is transferred to the offline task pool for asynchronous processing.

7. The network service acceleration method applied to the securities trading service platform according to claim 6, characterized in that: The configuring of a bidirectional heartbeat detection mechanism to maintain the link active state includes: A first heartbeat signal generator is established on the user terminal side, which is used to send a heartbeat request packet to the securities trading service platform at a fixed interval, wherein the heartbeat request packet includes a current terminal timestamp and a network status indicator; A second heartbeat signal generator is established on the securities trading service platform side, which is used to respond to the heartbeat request packet and return a heartbeat response packet, wherein the heartbeat response packet includes a platform timestamp and a link quality assessment result; If the user terminal does not receive the heartbeat response packet within the preset timeout window, the link self-repair process is started to gradually reduce the data transmission rate and try to re-establish the connection; If the securities trading service platform detects abnormal network status indicators within a plurality of consecutive heartbeat cycles, a link optimization suggestion is sent to the user terminal, wherein the link optimization suggestion includes switching to a designated access point or enabling a data compression mode; The interaction logs of all heartbeat request packets and heartbeat response packets are recorded, and a link health report is generated based on the interaction logs to guide the dynamic optimization of the transmission path.

8. The network service acceleration method applied to the securities trading service platform according to claim 1, characterized in that: The operations performed by the global load monitoring module include: Periodically collecting the CPU usage, memory occupancy, and disk input / output rate of each service node in the distributed service node cluster; Input the collected resource indicators into the pre-trained resource prediction model to generate the load trend prediction curve of each service node in the future preset time period; Dynamically scaling the service node according to the load trend prediction curve, wherein the dynamic scaling operation includes automatically scaling the virtual node instance before the load peak is reached, or releasing idle node resources when the load is at a valley value; When it is detected that the resource indicators of any service node continue to exceed the safety threshold, an alarm event is triggered and the service node is marked as unavailable. At the same time, the unfinished tasks of the service node are migrated to adjacent service nodes. The operating status data of all service nodes are aggregated to generate a global load heat map, and the global load heat map is pushed to the management terminal for visual monitoring.

9. The network service acceleration method applied to the securities trading service platform according to claim 4, characterized in that: The sending of the standardized task instruction to the service node group through a predefined transmission channel and monitoring of an intermediate processing status signal returned by the service node group includes: Allocating a unique transaction serial number to each standardized task instruction in the predefined transmission channel, and recording a mapping relationship between the transaction serial number and the user terminal; Splitting the standardized task instruction into multiple data slices, and adding an error correction code and a slice sequence number to each data slice; The data slices are sent to the service node group using a multi-path parallel transmission strategy, and reorganized and integrity checked according to the slice sequence numbers at the receiving end; If the service node group does not return the intermediate processing status signal within a preset time, query the unconfirmed data shards according to the transaction serial number and trigger a retransmission mechanism; After receiving confirmation signals from all data shards, a task reception success notification is sent to the user terminal, and execution timeout countdown monitoring is started; The adopting a multi-path parallel transmission strategy to send the data slices to the service node group includes: Obtain the bandwidth utilization, delay parameters and stability scores of all available transmission paths in the current network topology; Selecting an optimal transmission path combination according to the size and urgency of the data slices, and assigning an independent transmission path identifier to each data slice; During the transmission process, the transmission quality of each path is monitored in real time. If the delay parameter of a path suddenly increases or the packet loss rate exceeds the preset threshold, the data fragments on the path are dynamically migrated to the backup path; A data shard cache area is set on the service node group side to temporarily store the received data shards according to the transaction serial number until all shards are received; A security audit is performed on the reorganized standardized task instructions, which includes verifying the digital signature and checking the compliance of the instruction format, and the instructions are submitted to the execution queue after passing the security audit.

10. A network service acceleration system applied to a securities trading service platform, characterized in that: The network service acceleration system applied to the securities trading service platform includes a processor and a memory, the memory is connected to the processor, the memory is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the memory to implement the network service acceleration method applied to the securities trading service platform as described in any one of claims 1 to 9 above.

Images