Multi-account high-frequency transaction system based on dynamic resource scheduling

Abstract

The invention discloses a multi-account high-frequency transaction system based on dynamic resource scheduling, which relates to the technical field of financial transactions, and comprises the following steps: an account management module establishes a monitoring data structure, creates a transaction process and a strategy process and connects the transaction process and the strategy process through a shared memory queue according to processor and memory upper limit and account sub-strategy configuration; the strategy management module regularly collects indexes such as a strategy process processor, a memory, event response time and queue length, and the account management module generates a sub-strategy resource use permission in combination with a strategy priority level; the market preferential module selects a target market from multiple paths of markets and sends the target market to the strategy process, the strategy process generates entrustment according to the market, and the transaction process selects a transaction channel to send and process counter return under account level risk control constraint; and low-delay transaction and account risk centralized control under a multi-account multi-strategy scene and overall improvement of the resource utilization rate are realized.

Description

Technical Field

[0001] This invention relates to the field of financial transaction technology, specifically a multi-account high-frequency trading system based on dynamic resource scheduling. Background Technology

[0002] The rapid development of electronic trading and quantitative investment in the securities and futures industries has enabled institutional algorithmic trading systems to automate multi-account and multi-strategy trading. However, in practice, a single data center or even a single server within an institution may host multiple trading accounts and different sub-strategies. The system needs to quickly access market data, calculate strategies, send orders, and process trades to meet the risk monitoring and compliance requirements of trading venues and regulatory authorities. With the continuous increase in funds, accounts, and sub-strategies, the daily requests to a single server are rapidly increasing under limited memory and processor resources. The performance and risk control pressures brought about by high-frequency operation of multiple accounts and strategies are becoming increasingly significant.

[0003] Existing algorithmic trading systems are primarily based on single accounts or a small number of strategies. During deployment, fixed processor cores and memory space are often reserved for each trading and strategy module based on experience, without automatic adjustment based on actual load during operation. When there are many accounts and sub-strategies, and the market fluctuates sharply, differences in computational load and order volume emerge among various strategies. Some strategies may trigger trades frequently within a short period, quickly accumulating internal events or order queues, while other strategies remain under low load or idle. The lack of centralized collection and unified analysis of all strategy performance metrics prevents the system from timely reallocating computational resources among strategy processes. This can easily lead to critical strategies not being able to meet demands during peak trading hours, resulting in queued market data processing and order generation, and a significant increase in end-to-end latency.

[0004] Meanwhile, for the sake of module decoupling and ease of maintenance, most existing systems decompose market data, strategies, and trading into different processes, with network communication between different modules to exchange market data, order instructions, and trade results. In the process of multiple accounts and multiple sub-strategies running in parallel, each path from market data to strategy and then to trading requires multiple cross-process communications, and when server resources are strained, the link latency is difficult to predict.

[0005] Institutions often simultaneously access multiple market data sources and trading channels. Market data selection, channel selection, and account risk control logic are scattered across various components. When there is a concentrated surge in volume or extreme price fluctuations within a short period, issues such as insufficient processing capacity of the main strategies and slow updates on account risk exposure become prominent. Therefore, the technical problem this invention aims to solve is how to address the lack of consistent operational status awareness and resource allocation control when multiple accounts and sub-strategies are running on the same platform, resulting in difficulties in unifying processing timeliness and account risk control. Summary of the Invention

[0006] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a multi-account high-frequency trading system based on dynamic resource scheduling. It establishes a monitoring data structure, creates trading processes and strategy processes, and connects them via a shared memory queue. The strategy management module periodically collects metrics such as the strategy process's processor, memory, event response time, and queue length. The account management module generates sub-strategy resource usage licenses based on strategy priority levels. The market data selection module selects target market data from multiple sources and sends it to the strategy process. The strategy process generates orders based on the market data. Under account-level risk control constraints, the trading process selects a trading channel to send and process counter feedback, achieving low-latency trading, centralized account risk control, and overall improved resource utilization in multi-account, multi-strategy scenarios. This solves the technical problems described in the background section.

[0007] (II) Technical Solution To achieve the above objectives, the present invention provides the following technical solution: A multi-account high-frequency trading system based on dynamic resource scheduling includes: configuring processor cores and memory limits by the account management module; configuring priority levels and processor core and memory quotas for sub-strategies; starting trading processes and strategy processes; establishing a shared memory queue between trading processes and strategy processes; and establishing a market data selection module to establish a market data channel. The policy management module periodically collects policy process monitoring indicators and sends them to the account management module. The account management module determines the overall load of sub-policies based on the monitoring indicators and priority levels, and generates resource usage licenses for each sub-policy under the constraints of processor core and memory limits and quotas, and sends them to the policy management module. The market data selection module selects the best market data from multiple sources and provides it to the strategy process. The strategy process then submits order requests to the trading process. The trading process, based on account risk control parameters and capital check orders, sends orders that pass the check to the counter via the selected trading channel with the appropriate delay.

[0008] Furthermore, after configuring trading accounts and sub-strategies, the account management module also establishes a fixed-length sliding sampling window for each sub-strategy and each type of monitoring indicator, reserves storage area for each sub-strategy to record the smoothed monitoring indicators, overall load and resource usage permissions, and establishes a mapping table between sub-strategies and processor cores and memory quotas.

[0009] Furthermore, the monitoring metrics include processor utilization, memory usage, event response time from receiving market data to issuing orders, and internal event queue length for each strategy process. When calculating the overall load of sub-strategies, the account management module uses pre-configured weights to weight and synthesize various monitoring metrics.

[0010] Furthermore, the policy management module collects monitoring indicators from the operating system and policy process according to a preset sampling period. The account management module writes the new monitoring values ​​into the corresponding sliding sampling window and removes the oldest monitoring value in each sampling period. The monitoring values ​​in the window are weighted and summed according to the weight corresponding to the sampling order to obtain the smoothed monitoring indicators.

[0011] Furthermore, the resource usage license includes the lower and upper limits of the number of processor cores and the lower and upper limits of memory quota for each sub-policy. When generating resource usage licenses, the account management module first ensures that each sub-policy obtains no less than the lower limit of resources. When system resources are insufficient, the sub-policy with the lower priority level is marked as restricted operation or suspended operation.

[0012] Furthermore, the trading process, strategy process, and market data selection module are deployed on the same physical server. The strategy process and the trading process communicate through a pair of shared memory queues to exchange order requests and counter reports. The strategy process also reads market data from the market data selection module through the shared memory queue and polls the shared memory queue in a busy-wait manner on the processor core allocated by the resource usage license.

[0013] Furthermore, the market data selection module starts an independent receiving thread for each market data source and performs field integrity and format checks on the received market data. It reorders out-of-order data according to timestamps to maintain the time order of each market data source. After selecting the target market data source from multiple market data sources based on arrival time and delay statistics, it writes it into a shared memory queue.

[0014] Furthermore, after receiving the order request written by the strategy process, the trading process generates an internally maintained global number for each order and checks it in conjunction with account funds, positions, and account-level risk control parameters. For orders that fail the check, a reward record containing the rejection reason is written to the shared memory queue. For orders that pass the check, the global number is retained to associate with subsequent counter rewards.

[0015] Furthermore, when the trading process sends an order request to different trading channels, it records the sending time and the corresponding channel identifier. When receiving a counter report, it records the report time and calculates the round-trip time for each trading channel. The round-trip time is statistically analyzed into channel delay data according to the time window. The step of selecting a channel based on the channel delay data determines the trading channel with the smaller delay.

[0016] Furthermore, the client sends account-level or strategy-level control instructions to the account management module. The account management module forwards the account-level control instructions to the trading process to control the order placement behavior of the sub-strategies under the corresponding account, and forwards the strategy-level control instructions to the corresponding strategy process to change the strategy's running status and parameters. The changed running status affects the calculation of subsequent resource usage licenses through monitoring indicators.

[0017] (III) Beneficial Effects This invention provides a multi-account high-frequency trading system based on dynamic resource scheduling, which has the following advantages: The account management module centrally sets the processor cores, memory limits, and sub-policy priority levels, generates resource usage licenses, and dynamically sets the processor cores and memory capacity at the sub-policy granularity. This reduces resource waste and policy contention during multi-account, multi-sub-policy operation, and reduces queuing during peak hours.

[0018] A shared memory queue is established for the trading process and strategy process. Shared memory is used to transmit market data, orders and results, and the key trading links are confined to the memory space to run, reducing network transmission and copying. This makes the path from market data to strategy calculation to order entry into the trading process shorter and less volatile, which is suitable for the latency control requirements of high-frequency trading.

[0019] Risk control parameters are set at the account level, and the trading process performs account-level risk control checks on each sub-strategy order. The internal global number is used to manage the order and return relationship, so that the capital occupation and position changes caused by different sub-strategies under one account are centrally processed in the trading process. This reduces the inconsistency caused by multiple independent risk controls and multiple limit settings, and facilitates the formation of a consistent risk view.

[0020] In step one, the market data selection module establishes multiple market data access channels and performs validity verification, time sequence organization, and latency comparison on each market data source before selecting the best one to send to the strategy process. The trading process maintains the latency statistics of each trading channel and selects the channel to place orders based on the channel latency, reducing queuing during peak trading hours. This allows market data selection and channel selection to work together, improving the overall stability of the link when network conditions change. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of the multi-account high-frequency trading system based on dynamic resource scheduling according to the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Please see Figure 1 This invention provides a multi-account high-frequency trading system based on dynamic resource scheduling, comprising: Step 1: Before the system is officially connected to market data and strategies begin issuing orders, complete the integrated collection and modeling of global resources, account and strategy parameters, and initialize all data structures required for monitoring and scheduling, so that subsequent steps can directly perform load assessment and resource allocation based on these structures.

[0024] When multiple accounts and sub-strategies run in parallel on the same server, the trading targets, algorithm models, and expected trading frequencies of different strategies vary significantly. If a simple static configuration is used, fixing the number of processor cores and memory for each strategy, it is difficult to accurately depict the true resource requirements of each strategy during the startup phase. Therefore, a measurable resource requirement profile needs to be introduced during the configuration phase and modeled in a unified manner with account priority levels and strategy priority levels, serving as the basis for subsequent load assessment and resource scheduling.

[0025] Starting with system-level hardware resources, the system obtains basic capabilities such as the number of physical processor cores and allocable memory capacity of the server, and then breaks this down to the account and strategy layers. The account management module reads the hardware and software quota information for each account entered by the administrator in the graphical interface or configuration file, including the range of processor cores allowed for each account, the memory limit, and the number of sub-strategies and estimated trading activity under that account. For each sub-strategy, the system further collects information such as its estimated order frequency, computational complexity per order, and number of underlying assets, forming a preliminary characterization of the resource requirements for that sub-strategy.

[0026] For each strategy and each monitoring metric, a moving weighted average function is provided: Among them, strategy number For a certain sub-strategy; sampling time It is an integer, that is, the first... Secondary sampling; monitoring of raw values For this strategy time A sampled value of a specific monitoring metric, such as processor utilization, memory usage, event response time, or internal queue length; time weighting. A non-negative real number used to describe the weights of different historical sample values ​​of the window; smoothing value. For this indicator time The smoothed value. Represent the above information as the strategy baseline resource requirement value.

[0027] For each sub-strategy, the account management module calculates the baseline resource requirements based on configuration parameters such as estimated order frequency and computational intensity per order. For example, it can be calculated using the following formula: Where: Strategy baseline resource requirements : indicates the first The baseline resource demand intensity of the strip strategy during the system initialization phase is a non-negative real number; the strategy's estimated delegation frequency. : indicates the first The number of orders expected to be generated by the tick strategy per unit of time is a non-negative real number, which can be estimated by the manager based on historical trading records or strategy design. Strategy Single-Transaction Calculation Strength : indicates the first The average computational workload required for a single delegate to complete a task using a bar strategy can be given by evaluating the internal computational steps of the strategy and the scale of data involved; it is a non-negative real number; coefficient weights. : Indicates the estimated frequency of orders based on the strategy. The adjustment coefficient for the degree of influence is generally in the range of [range missing]. Internal values ​​can be provided by the system with default values ​​and can be adjusted by administrators based on experience; coefficient weights : Indicates the strength of a single policy order calculation. The adjustment coefficient for the degree of influence is generally in the range of [range missing]. Take the value from the inside.

[0028] Therefore, the baseline resource requirements for each sub-strategy are calculated during the startup phase. This is then cross-compared with the minimum number of processor cores and minimum memory quota of the sub-policy. Significantly deviating configurations are highlighted on the interface, prompting the administrator to correct them, ensuring that subsequent scheduling is not based on distorted parameters. Policy baseline resource requirements. This information is then written into the policy baseline resource requirement table for subsequent load assessment and resource scheduling. This allows for fine-grained expression of the strength of resource requirements for different policies during the initialization phase without increasing runtime complexity, creating conditions for on-demand resource allocation in subsequent steps.

[0029] After obtaining the baseline resource requirements for the strategy, simply sorting them by the size of the resource requirements is insufficient to reflect the importance of the business, because the business status of different accounts and different strategies may be different.

[0030] The account priority level and policy priority level subjectively set by the administrator need to be normalized and coded using a unified standard during the configuration phase, so that subsequent scheduling can consider both the strength of resource demand and the order of business priority, rather than a single dimension.

[0031] Record the account priority level for each trading account, and record the original strategy priority value for each sub-strategy under the account. The initial value can be an integer level, such as level 1 to level 10, provided by the administrator in the interface. Since administrators may use different scoring habits for different accounts, directly comparing the initial level values ​​of strategies across different accounts may lead to discrepancies. Therefore, it is necessary to specify the initial value of the strategy priority level. Normalize the values ​​globally to obtain the normalized values ​​for strategy priority levels. : Where: Original value of strategy priority level : indicates that the manager is the first The priority level directly set by the policy, a positive integer; the normalized value of the policy priority level. : Indicates the scope of the entire system for the first Normalized results of the priority ranking of the bar strategy, in intervals Internal; highest priority level : Represents the maximum original value of the policy priority level among all sub-policies in the current system, used to uniformly scale all original levels to . Interval.

[0032] After normalization, the strategy priority values ​​are normalized. Write it into the priority table and compare it with the strategy baseline resource requirements. By associating storage under the same policy identifier, subsequent scheduling can simultaneously obtain the resource requirements and business priority order of any sub-policy record when reading it. Account priority levels and policy priority levels are no longer merely textual descriptions in the configuration interface, but are solidified into quantifiable parameters that can be used in calculations, thus providing a unified and computable priority level basis for subsequent resource scheduling steps.

[0033] In one embodiment, a securities firm configures three key proprietary trading accounts and several asset management accounts on a trading server. The asset managers use the account management module to assign higher initial priority values ​​to the arbitrage, market-making, and trend-following strategies under the proprietary trading accounts. And configure lower policy priority levels for some test policies. The system calculates the priority level normalized value according to the above relational formula. Then, a list is automatically generated, which centrally displays the baseline resource requirements for each strategy. and strategy priority level normalized value Managers can fine-tune the level settings of some strategies accordingly, so that strategies that should logically be prioritized also reflect a higher degree of importance in the parameters.

[0034] After modeling global resources, accounts, and strategy parameters, all necessary monitoring windows, time-weighted sequences, and resource mapping matrices are prepared in advance for load assessment and resource scheduling in subsequent steps. Based on this, the topological relationships between transaction processes, strategy processes, processor cores, memory resources, and shared memory queues are initially solidified. This avoids temporary structure allocation and dynamic array expansion during peak trading periods, shifting the overhead of data structure initialization to the system startup phase.

[0035] Load assessment requires continuous observation of the changing trends of each sub-policy across monitoring metrics such as processor utilization, memory usage, event response time, and internal queue length, rather than focusing on a single instantaneous value. Therefore, during system startup, a sliding sampling window needs to be established for each monitoring metric of each sub-policy, and time weights need to be assigned to each sampling point within the window, allowing subsequent steps to directly perform weighted calculations based on this information.

[0036] The account management module pre-registers the sampling window length for each sub-policy and each monitoring metric. and sampling interval And according to the time decay factor set by the administrator Generate time weight series ,For example: Where: time weight sequence : indicates the first digit within the sliding sampling window Time weight of each sampling point; time decay factor : Represents the rate at which the weight decays over time, with values ​​ranging from 0 to 10. ; Sampling window length : Indicates the number of sampling points stored within the sliding window for each monitoring indicator, a positive integer, configured by the administrator based on the strategy's operating cycle and hardware capabilities; sampling interval. : Represents the time interval between two consecutive samples, a positive real number; During the initialization phase, the time weight sequence is calculated based on the above relationship. Pre-calculate and store the weights in the monitoring window table, and simultaneously create a sampling window length for each monitoring metric of each sub-strategy. The corresponding fixed-length buffers are labeled with the time weight sequence used for each buffer. Subsequent steps simply involve writing new values ​​to the buffer and performing calculations using existing weights when collecting metrics, eliminating the need to repeatedly create or adjust time weights under high load. This allows for smooth processing of monitoring metrics through pre-planning in the structure and runtime follow-through, thereby reducing structural overhead during runtime.

[0037] After establishing the monitoring window and time weight structure, the system also needs to define the available range of each sub-strategy on the processor core and memory during the startup phase, forming a resource mapping matrix, and sharing the memory queue topology between the trading process and the strategy process, and between the strategy process and the market data selection module.

[0038] By using a static resource mapping matrix and a fixed queue topology, any subsequent resource adjustment becomes a modification of matrix elements and queue states, rather than a reallocation of memory and connection relationships.

[0039] The account management module first generates a resource mapping matrix element for each policy-core combination based on the minimum and maximum number of processor cores configured by the administrator for each sub-policy, as well as the set of bindable processor core numbers. And limit its set of values: Where: resource mapping matrix : indicates the first The strategy of the bar and the first The availability relationship between individual processor cores, when Values The time indicates that the first time is allowed to be included in subsequent scheduling. The processor cores are allocated to the first The strategy of using strips, when Values This indicates that the strategy is not allowed to use this core; Strategy Index : Represents a unique identifier for a specific sub-strategy in the system, usually a positive integer; Core Index : Represents the number of a processor core in the server, usually a positive integer.

[0040] Resource mapping matrix The data is stored in a resource mapping table, and a list of candidate processor cores is pre-allocated for each sub-strategy based on this table. The transaction management module creates a transaction process according to the account configuration, and the strategy management module creates a strategy process for each strategy. Under the constraints of the resource mapping table provided by the account management module, both parties complete the initial binding in the candidate core set through the operating system interface. At the same time, the transaction process creates two shared memory queue identifiers for each registered sub-strategy for order requests and feedback. When the strategy process starts, it binds to the corresponding shared memory queue according to the account identifier and strategy identifier. The market data selection module establishes a corresponding market data shared memory queue identifier for each strategy according to the configuration.

[0041] For a generalized implementation, the resource mapping matrix It can also be decomposed into a multi-dimensional structure, where resource attributes such as memory quota levels and network bandwidth priorities are recorded in additional attributes, and the allowed / disallowed relationship is represented by the 0 / 1 values ​​of the elements in the matrix. Here, we can fix the topological relationship of policy-core-queue, and subsequent resource scheduling only needs to add or remove resources in this topology without having to rebuild the communication paths of processes. This structurally facilitates the operation of multi-account and multi-sub-policy systems.

[0042] Step 2, runtime load assessment and priority-based dynamic resource scheduling, is a set of logics that run continuously during the transaction process to transform monitoring data into resource allocation decisions and form a coherent feedback chain between multiple scheduling cycles.

[0043] A complete link is established around each strategy process, consisting of metric collection, sliding smoothing, and unified scale representation. This allows the account management module to compare the stress levels of different strategies in terms of processor usage, memory usage, event response time, and queue length on the same scale during each sampling period, providing a solid quantitative foundation for subsequent resource reallocation.

[0044] In an environment where multiple accounts and multiple sub-policies are running simultaneously, if we rely solely on the operating system's own statistical interface without establishing a unified data collection link and monitoring buffer within the system, it is difficult to match external sampling results with specific policies one by one, and it is also difficult to guarantee time alignment between different indicators.

[0045] Therefore, it is necessary to coordinate the strategy management module and the account management module to integrate the collection of indicators from the operating system layer and the internal strategy layer into a fixed-rhythm sampling cycle, and connect it with the monitoring window structure pre-allocated in step one.

[0046] The policy management module maintains a policy sampling task table, where each record corresponds to a policy process and the set of metrics that process needs to collect. Whenever a sampling period arrives, the policy management module drives the sampling thread to access this table sequentially. For each record, it first calls the operating system interface to obtain the processor usage percentage and memory usage of the corresponding policy process within that period, and then calls the policy process's internal status query interface to read the processing latency of the latest batch of events and the queue length of currently pending events or delegates within that period. After collection is complete, the policy management module packages these four types of raw metrics, attaches a policy identifier and a sampling time identifier, and passes it to the account management module.

[0047] After receiving the packaged data, the account management module, based on the policy identifier and indicator category, selects the corresponding sliding window from the monitoring window mapping table constructed in step one, writes the new sampled value to the window position, and updates the window pointer at the same time.

[0048] When the window is not full, it is filled with the data; when the window is full, the first value is filled, maintaining a fixed length of historical samples. A sampling time identifier is used to record the time position of each new sample, enabling subsequent filtering of abnormal intervals by time span. The data acquisition chain is typically implemented using a combination of a single sampling thread and an asynchronous queue: the policy management module's sampling thread interacts with the operating system and policy process, writing the collected raw metrics one by one into an internal linked list queue; the account management module's metric receiving thread retrieves the metric data from the head of this queue, finds the corresponding window based on the policy identifier, and writes the data to disk. The acquisition thread and the receiving thread are decoupled through a memory queue to avoid network jitter or processing delays causing blockage of the entire sampling channel during the sampling process. Each metric data is written to the sliding window, and a record is added to the monitoring log, marking the writing position, window number, and whether a preset alarm threshold has been triggered.

[0049] In one embodiment, when an organization runs forty policies in parallel on the same server, the administrator sets the sampling period to one second. The sampling thread of the policy management module iterates through the forty policy sampling tasks sequentially every second, with the collection time for each task controlled within milliseconds. Subsequently, the account management module updates the corresponding sliding windows sequentially in a background thread. External observers can see that in the monitoring interface, the four indicator curves for each policy are scrolling at a uniform rhythm, thus providing a complete historical trajectory for subsequent unified scheduling.

[0050] By constructing a data acquisition chain and writing monitoring buffers, the metrics for each policy operation remain continuous and traceable over time, avoiding reliance on sampled values ​​or manual statistics for resource usage assessment. The data acquisition chain is tightly coupled with the monitoring window structure in step one; metric acquisition is written to a designated window, providing stable input for subsequent smoothing calculations and load characterization.

[0051] In addition, processor usage, memory usage, event response time, and queue length represent different stress dimensions of the strategy. Their dimensions and typical value ranges are large. If they are added together, it is easy for the fluctuation of one type of indicator to mask the changes of other indicators. It is necessary to use the smoothing relationship preset in step one to converge the original values ​​in the window into smooth values, and then normalize and weight the combination to construct a load characterization that can reflect the comprehensive situation of each indicator and has stable values.

[0052] At the start of each scheduling cycle, the account management module first retrieves the current smoothed value of each strategy and metric category from the monitoring window (obtained from the smoothing relationship defined in step one). Then, it normalizes the value based on the lower and upper bounds of the metric category to obtain a dimensionless metric value between zero and one. Subsequently, according to the metric weights configured in step one, the four normalized metric categories are linearly combined to obtain the overall load level of the strategy at the current moment.

[0053] In a specific implementation, the following normalization relationship and load composition relationship can be adopted: Among them: number of strategies : Same as step one, representing the total number of strategies, a positive integer used to limit the range of strategy indexes; number of indicator categories. : Indicates the number of monitoring metric categories, which is four, including processor usage, memory usage, event response time, and queue length, and is a positive integer; policy sequence number. : indicates the first This strategy is between 1 and Positive integers between; indicator category number : indicates the first This type of monitoring indicator is between 1 and... Positive integers between; Sampling time sequence number : Represents the sampling time corresponding to the current scheduling period, and is a non-negative integer; smoothing index value : indicates the first The strategy at the sampling time Time The smoothing result of the index, corresponding to the smoothing calculation relationship preset in step one, is a real number; refer to the lower bound. : indicates the first The lower bound of the metric under normal operating conditions can be preset based on historical data or business experience. It is a real number and is applicable to all strategies. Reference upper bound :Should The upper bound of the reference index is a real number, and it has... Used to divide the normalization interval; normalization index value The dimensionless index value obtained after mapping this type of index to a reference interval, if it falls within the interval... Internal; weighting coefficient :Should The weighting coefficient of the class index in the overall load is a non-negative real number, which generally satisfies the following conditions: Overall load level :Should Sampling time of the strategy The overall load level is a non-negative real number; the larger this value, the greater the resource demand of this strategy.

[0054] During the initialization phase, the account management module will use the reference range and weighting coefficients set by the administrator to... , , Store in the parameter table, retrieve at runtime. Substituting the above relationships, normalized metrics and overall load levels can be calculated for each scheduling cycle. If a strategy exhibits an anomaly in these metrics (e.g., exceeding the upper reference bound), the account management module will... Cut off within a reasonable range and record monitoring logs.

[0055] In one instance, when the market suddenly experiences a surge in volume, and the event response time of a certain strategy rapidly increases, even if the processor usage is not yet at its extreme value, its normalized index will be faster than the reference upper bound, approaching one, and occupying a larger proportion of the overall load. Subsequently, more processor cores or memory quotas will be allocated to this strategy.

[0056] By smoothing value normalization and constructing a comprehensive load for multiple indicators, various monitoring indicators are uniformly compressed into a comparable dimensionless space, enabling the account management module to perform calculations based on a single numerical value. The system directly determines the load intensity of different strategies in the current cycle and provides standardized input for subsequent calculations of strategy priority levels and resource quotas. This numerical characterization method preserves the differences between various indicators while avoiding judgment distortions caused by inconsistent units. The obtained comprehensive load level is combined with the strategy priority level established in step one to form a scheduling score for each strategy in the current cycle. Under the constraints of system resource limits and policy resource upper and lower limits, the specific processor quota and memory quota are calculated and then issued to the strategy management module in the form of resource usage licenses, thus forming a closed loop between resource adjustment and process execution.

[0057] For multi-account, multi-sub-strategy, some strategies may have high load but not necessarily the highest business importance. If resources are allocated entirely based on the overall load level, some strategies may not be able to guarantee effective operation at critical moments. Therefore, it is necessary to normalize the priority level in step one and combine it with the overall load level to affect the scheduling score, so that the business judgment in the configuration phase maintains a mathematical form during the runtime.

[0058] At the start of each scheduling cycle, the account management module reads the normalized priority value of each policy from the parameter table and converts it into a priority coefficient. Then, it substitutes the obtained comprehensive load level into the scheduling score calculation relationship to obtain the scheduling score for each policy in the current cycle. Based on the total number of processor cores currently available for each policy, the account management module first reserves the minimum processor requirement for each policy, and then allocates the remaining cores to each policy according to the scheduling score ratio to obtain the processor quota.

[0059] The following relationship can be used to calculate scheduling scores and processor quotas: Among them: number of strategies : Same as before, indicating the total number of strategies; strategy number , : Indicates the specific strategy number, which is between 1 and Positive integers between; overall load level : indicates the first The strategy at the sampling time Overall load level; priority coefficient : indicates the first The priority coefficient of each strategy is derived from the normalized value of the strategy priority level in step one, and is a positive real number; scheduling score : indicates the first The strategy at the sampling time The scheduling score is a positive real number used to measure the relative share of resources that the strategy should obtain in the current cycle; Minimum processor requirements : in the The minimum processor core requirement set during policy configuration is a negative integer; the total number of available processors... This refers to the current processor that can be used by all policies; it is a positive integer and generally does not exceed the total number of processors in the system; the current processor quota. The current processor quota is at the sampling time. For the first The number of processor cores allocated by the strategy is a real number, which can be rounded down before core binding.

[0060] Preferably, the priority coefficient can be directly taken. In the above calculation relationship, the first formula multiplies the overall load level by the priority coefficient, so that even if the overall load levels of two strategies are similar, the strategy with the higher priority level can obtain a higher scheduling score. The second formula first ensures that all strategies obtain their respective minimum processor requirements, so that critical strategies are not compressed to the point of being unable to run due to overall resource shortage; then, it allocates the total amount of remaining available processors according to the scheduling score ratio, so that resource allocation is linked to both load and priority level.

[0061] For example, if an institution is running a set of thirty strategies simultaneously, five of which are market-making strategies, these five strategies have a significantly higher priority than the other strategies. Their market volatility and priority coefficients are also higher, resulting in a higher scheduling score. The account management module allocates processor cores to these strategies according to the second formula, allowing them to provide stable responses during periods of high matching frequency. Some test strategies, however, are allocated only the minimum processor or even suspended.

[0062] By constructing a scheduling score and calculating processor quotas, both policy priority and overall load are incorporated into resource allocation decisions. This ensures that resource allocation follows operational pressure without violating the order of business importance, avoiding the bias caused by simply allocating resources based on load or priority.

[0063] Calculating quotas solely within the account management module without process-level adjustments fails to alter the actual operating conditions of each policy and makes it difficult to quickly suppress or pause high-risk policies in abnormal situations. Therefore, a unified structure is needed to encapsulate resource quotas and operational status recommendations, transmitting them to the policy management module via a control channel for the specific execution of core binding, memory adjustments, and state switching.

[0064] The account management module obtains the processor quota for each policy. Next, the system checks the set of processor cores allowed to be bound to each policy according to the resource mapping table in step one, and selects a specific core number for it within that set, forming a policy-core list mapping. Simultaneously, considering the overall load level, the current memory usage of the policy, and the minimum and maximum memory requirements configured for the policy, the system calculates the memory quota range for the next cycle for each policy, and generates a policy-memory limit mapping accordingly. For policies with consistently low overall load and low priority, the account management module can mark them as restricted in this license, prompting the policy management module to retain only the basic responsiveness of that policy in the next cycle. For policies with consistently high overall load that are difficult to alleviate after multiple scheduling attempts, a temporary pause suggestion can be made, reminding the administrator to intervene.

[0065] Resource usage licenses can be designed as a structured set of instructions, where each instruction corresponds to a policy and includes three core fields: policy identifier, target processor core list, target memory limit, and suggested running state. After generating this set, the account management module sends it line by line through the control channel with the policy management module. Upon receiving the instructions, the policy management module parses each field, calls the operating system interface to unbind the policy process from its original processor cores, and then binds it to the new core set. Simultaneously, it adjusts the policy's internal cache allocation strategy based on the target memory limit, releasing unnecessary cache and increasing the allocation of cache that needs expansion. For policies marked as pause suggestions, the policy management module decides, based on the administrator's automatic control policy, whether to immediately switch to a paused state or first send a confirmation request to the administrator.

[0066] By combining resource usage license issuance with policy operation status adjustments, scheduling results are integrated with the real-time operation status of policy processes. This ensures that quotas are no longer fixed in the management module but are implemented at the process level through a clear control path. The integration of quota adjustments and status switching allows for control of relevant policies when the system faces continuous high loads or abnormal behavior. This can be achieved by reducing quotas, marking restricted operation, or suggesting suspension, forming a top-down control thread and providing a controllable computing environment for subsequent unified risk control.

[0067] Step 3: Low-latency multi-account high-frequency trading execution and feedback control under unified risk control constraints. Starting from the resource usage license calculated and issued in Step 2, the market data selection module, strategy management module and trading management module are driven to work together in a predetermined order in each trading matching cycle, so that multiple accounts and multiple sub-strategies can complete the closed-loop trading process from market data reception, signal output to order sending and feedback on the same server.

[0068] For each trading instrument and sub-strategy, data from multiple market data sources are organized into a time-continuous and clearly sourced market data sequence. Based on this, the best market data is distributed to the strategy process through a shared memory queue, so that the strategy process can complete signal calculation and order generation in an orderly manner under the processor core constraints configured in step two.

[0069] In one embodiment, a server simultaneously deploys futures and stock accounts, each with multiple sub-strategies. After the market opens, the market data selection module receives order book data for the same index from three different market data lines. Upon receiving each data packet, the module immediately checks the order according to the timestamp and sequence number in the packet, discarding invalid data and writing it into an internal candidate queue. Subsequently, the selection logic selects the earliest available data from the candidate queue that does not disrupt the overall time order, copies it to the target market data cache of the corresponding asset, and then writes it to each strategy process subscribed to that asset via a shared memory queue. Throughout this process, the processor core where the strategy process resides is determined by the resource permission in step two. The strategy process reads its own market data queue in a busy-wait manner on its respective core, ensuring that once new market data is written, the strategy thread can immediately detect it in its local buffer and begin subsequent calculations.

[0070] Multi-account, multi-strategy systems often simultaneously access multiple data streams from the exchange's main site, disaster recovery site, and market data service providers. These data streams exhibit varying transmission delays and jitter characteristics during network transmission, and the order of price quotes and transaction data for the same asset may differ, or even overlap briefly. If these data streams are distributed to strategies directly in the order they are received, it can easily create a time reversal phenomenon within the strategies, affecting signal interpretation.

[0071] The market data selection module establishes an independent receiving thread and a line buffer queue for each configured market data line, and a unified candidate buffer for each trading target. After the network connection is established, the receiving thread writes each data packet that passes the basic verification to the corresponding line buffer queue, along with the line number. The selection logic periodically reads the latest unprocessed data from each line buffer queue, sorts multiple candidate data for the same target based on timestamp and sequence number, and discards late data that is explicitly earlier than the already distributed data, according to the requirement of monotonically increasing timestamps. The earliest data that conforms to the time order after sorting is inserted into the candidate buffer for that target. In this way, the candidate buffer always maintains a timeline that does not regress.

[0072] The implementation can be carried out in the following order: First, assign an access address and port to each market data line and complete the connection establishment in step one; then, establish a fixed-capacity candidate buffer for each target. When the candidate buffer for a target is insufficient, the selection logic will wait for the strategy process to consume some data before replenishing it to avoid unbounded expansion. Whenever new data is written to the candidate buffer, the selection logic compares the timestamp with the timestamp of the previous distributed market data. Only if the new data time is not earlier than the time of the previous distributed data is it marked as data that can be distributed to the strategy; otherwise, it is marked as discarded data and recorded in the log.

[0073] By establishing an independent receiving buffer for each market data stream and a candidate buffer for each target, and by strictly reconstructing the order within the buffers based on timestamps and sequence numbers, the market data sequence ultimately pushed to the strategy does not experience backtracking or crossover on the timeline. This ensures that the prerequisite data for factor calculations and signal triggering conditions within the strategy is consistent. Furthermore, the presence of multiple market data streams no longer disrupts the time order but instead provides multiple candidate values ​​at the same moment for subsequent optimization.

[0074] Even after the time sequence has been reconstructed, multiple data sources often still have different arrival delays. If a single fixed source is used as the sole data source, the advantage of faster data arrival from other sources will be lost. However, if time continuity is not considered when choosing a faster source, gaps or duplications may be introduced.

[0075] Therefore, while ensuring that the time series does not go backward, it is necessary to select the data that arrives earlier and passes the verification among all lines for each new time point, and use this to drive the shared memory distribution.

[0076] When processing candidate data in the target buffer, the optimization module not only stores the market data for that target but also records the line number and current statistical latency of each data point. For multiple candidate data points with the same timestamp, the optimization logic compares the recent latency statistics of the lines corresponding to each data point. Without reversing the time series, it selects the one with the lower latency as the target for this distribution, copies its content to the target market data block for the strategy, and triggers a shared memory write operation. The strategy process, on the processor core allocated in step two, continuously polls the corresponding shared memory queue. When it sees a change in the timestamp in the target market data block, it reads the new market data and enters the strategy calculation branch.

[0077] In a generalized implementation, the institution accesses two direct exchange market data streams and one third-party aggregated market data stream. The arrival times of the price quotes for the same asset vary slightly among these three streams. The optimization module calculates the average latency of each stream over a continuous period and assigns higher priority to the direct connection with the lowest latency. When a direct connection experiences short-term fluctuations or a sudden increase in latency, the latency statistics for that line will rise accordingly. The optimization module then automatically selects data from another direct connection or the third-party line for distribution at several subsequent time points without manual intervention.

[0078] By adding line latency statistics to the time-series reconstruction, the optimization module can select the market data with the lowest latency from multiple available lines at each time point and push it to the strategy process. This ensures that the market data received by the strategy maintains temporal continuity while being as close as possible to the earliest arrival time among all lines, balancing continuity and arrival speed. The use of a shared memory distribution link eliminates the need for network protocol stacks during the transmission of market data from the optimization module to the strategy process, thereby reducing additional latency in the transmission path.

[0079] Based on the market data and strategy-generated order requests, and relying on account-level risk control parameters and latency statistics of multiple trading channels, each order undergoes unified risk control verification and channel selection. Orders that pass the verification are sent to the appropriate trading platform for execution, and result matching and strategy status updates are completed in a timely manner after the return of the feedback.

[0080] In one embodiment, a proprietary trading account may have multiple index enhancement strategies linked to it. When market volatility increases, these strategies generate a large number of buy and sell orders almost simultaneously, requesting delivery to the corresponding trading processes via a shared memory queue. Upon receiving the orders, the trading process first invokes account-level risk control logic to check the account balance and position limits. Orders exceeding the position limit are rejected without being sent to the counter. For orders that pass the check, a channel score is calculated based on the average latency and recent success rate of each trading channel within the current time window. The channel with the highest score is selected, and the order is encapsulated into a counter message and sent. After the counter returns a transaction or cancellation report, the trading process writes the report to the shared memory queue of the corresponding strategy process using an internally unified order number. The strategy process then adjusts its own positions and fund records accordingly.

[0081] Traditional multi-strategy systems, which rely solely on risk control within each strategy, are prone to issues such as concentrated risk exposure at the account level. For example, when multiple strategies move in the same direction towards the same asset, the accumulated positions can become excessive, exceeding the account's limits. Furthermore, with multiple trading channels, the latency and stability of different channels cannot be quantified, forcing channel selection based on a fixed priority order. In this system, risk control parameters are initialized in step one, and operational indicators are continuously collected in step two. Upon receiving a strategy order request, the trading process first loads the account's corresponding capital limits, position limits, and single-order limits from the account's risk control parameter table. It then compares the current order's target position and theoretical transaction amount with these limits to determine whether approval is granted. If any limit is breached, the trading process generates a report with a clear reason for rejection and writes it back to the strategy process.

[0082] For orders that pass the account risk control check, the trading process needs to select a trading channel for them. To this end, the trading process maintains a channel latency statistics table, which records the average round-trip latency and the number of anomalies for each channel over a recent period. Based on this, the trading process can... The channel at the current moment The overall delay score is constructed according to the following relationship: Among them, the channel number A positive integer used to identify the first configuration of the server. Single transaction channel; comprehensive latency score The value is a non-negative real number; the smaller the value, the better the latency performance of the channel at the current moment; the current average round-trip latency. A non-negative real number, representing the state at the current time. Within a certain time window at the end, the first Average time from order to return for each channel; Abnormal weighting coefficient This is a non-negative real number used to reflect the amplification of the score when a timeout or connection interruption occurs in this channel; a larger coefficient indicates greater sensitivity to anomalies; Anomaly Intensity Index It is a non-negative real number, representing the number or proportion of times or failures that occur in the channel within the selected time window, and is a measure of stability.

[0083] The trading process can be updated for each channel at fixed time intervals. and For example, by using a sliding window to count the round-trip time and number of failures, the latest data can be used each time a channel is selected. .

[0084] By centralizing account risk control checks within the trading process and using clear comparison rules to determine whether an order should be approved, orders issued by multiple strategies are uniformly controlled in terms of funds, positions, and single-transaction limits, preventing situations where a single strategy is compliant but the overall account risk exceeds the limit. Simultaneously, a comprehensive latency scoring system is used. The trading channels are quantitatively ranked so that subsequent channel selection can be based on evidence-based judgments of current latency and stability performance, rather than relying solely on static priority.

[0085] Furthermore, the orders issued by the strategy vary in terms of price distance from the order book, target position adjustment range, and strategy model type. Some orders need to be executed as soon as possible, while others can tolerate a longer waiting time. If channel selection only considers the channel's latency score without taking into account the urgency of the order, some orders with high timeliness requirements may be assigned to channels with slightly higher latency but greater stability, thus affecting the strategy's effectiveness. Therefore, it is necessary to combine the urgency of the order with the overall channel score to obtain a channel selection decision for each order.

[0086] After an order passes the account risk control check, the trading process will construct an urgency index for the order based on the order type, the distance between the order price and the current market price, the expected position adjustment range, and the urgency level marked by the strategy.

[0087] Then, the urgency index is combined with the calculated channel latency score to generate a comprehensive channel score for each candidate channel for the current entrustment, and the channel with the best score is selected to execute the entrustment.

[0088] For example, it is possible to [do something] on the [number]th [item]. The pen, through risk control delegation, at the current moment Define channel scoring: Among them, the entrustment serial number A positive integer, used to identify the currently processed [number]. Pen commission; channel scoring A non-negative real number, used to measure the performance of a candidate channel in processing the [number]th [channel]. The overall suitability of the pen request; a smaller value indicates a better fit; urgency level is also considered. A non-negative real number, representing the degree of importance attached to the urgency of the task; the higher the urgency, the larger this value can be; Channel delay score. The value is a non-negative real number, indicating that when considering the th , When entrusting the currently selected candidate channel, according to The derived score for the delayed portion; Stability weight A non-negative real number, representing the degree of importance attached to the stability and success rate of candidate channels; channel stability index A non-negative real number, representing the overall performance of the candidate channel within the selected time window, including success rate and rejection rate.

[0089] Channel rating The system can acquire and maintain updates as follows: For each trading channel, the trading process establishes a channel monitoring record, writing the sending time and channel identifier each time an order is sent, and writing the return time and execution result code when receiving a corresponding counter report. Within a preset rolling time window, the system calculates the average round-trip time of all orders for that channel, as well as the ratio of the number of failures (timeouts, rejections, connection anomalies, etc.) to the total number of orders within that window. The average round-trip time and the failure ratio are weighted and summed according to preset weights to obtain the corresponding channel score. A smaller channel score indicates lower latency and fewer failures within the current window. When selecting a channel for a new order, the trading process calculates and compares the channel scores of all available channels, prioritizing the trading channel with the lower score for sending the order.

[0090] Channel delay score The latency is continuously collected during the trading process. Specifically, the trading process establishes an independent channel status record for each trading channel. Each time an order is sent through a trading channel, the sending timestamp of the order is recorded. Upon receiving the corresponding counter feedback, the arrival timestamp of the feedback is recorded, and the difference between the two is taken as the round-trip time of the order on that channel. Within a pre-set rolling time window, the trading process collects the round-trip times of all completed orders on that channel. These round-trip times are then aggregated in chronological order, for example, by calculating the weighted average round-trip time of the most recent orders, or by using a smoothing method with successive updates to obtain the current representative channel latency value. This representative channel latency value is recorded as the channel latency score. The channel latency score is stored in the channel status record and is updated synchronously by the trading process each time a new feedback arrives. When a new order requires selecting a trading channel, the trading process reads the channel latency scores of all available channels, compares the channel latency scores of different channels, and prioritizes sending the order to the channel with the lower channel latency score.

[0091] The transaction process calculates once for each candidate channel. Then, the channel with the lowest score is selected as the final channel, and the order is encapsulated and sent to the corresponding counter connection. Once the counter returns a transaction or cancellation report, the trading process matches the order with the internal unified order number, writes the report content to the shared memory report queue of the corresponding strategy process, and extracts fields such as transaction quantity, transaction amount, and time from order to execution from the report to update the channel delay statistics table and account fund holding records.

[0092] By introducing urgency weights and channel scores, the system combines the order's own attributes with channel latency and stability data to select the most suitable trading channel for each order. This is achieved while maintaining account-level risk control constraints and a unified feedback loop. The rewards received by the strategy process include both the execution results and the underlying feedback on the channel selection behavior, facilitating analysis during subsequent parameter tuning or strategy expansion. Furthermore, the trading process can report some channel selection information and risk control rejection statistics to the account management module for subsequent adjustments to strategy priority levels or modifications to account risk control parameters, achieving a vertical closed loop from the execution layer to management.

[0093] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0094] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0095] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0097] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multi-account high-frequency trading system based on dynamic resource scheduling, characterized in that: include, The account management module configures the processor core and memory limits, sets the priority level and processor core and memory quotas for sub-strategies, starts the trading process and strategy process, establishes a shared memory queue between the trading process and strategy process, and the market data selection module establishes a market data channel. The policy management module periodically collects policy process monitoring indicators and sends them to the account management module. The account management module determines the overall load of sub-policies based on the monitoring indicators and priority levels, and generates resource usage licenses for each sub-policy under the constraints of processor core and memory limits and quotas, and sends them to the policy management module. The market data selection module selects the best market data from multiple sources and provides it to the strategy process. The strategy process then submits order requests to the trading process. The trading process, based on account risk control parameters and capital check orders, sends orders that pass the check to the counter via the selected trading channel with the appropriate delay.

2. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 1, characterized in that: After configuring trading accounts and sub-strategies, the account management module also establishes a fixed-length sliding sampling window for each sub-strategy and each type of monitoring indicator, reserves storage area for each sub-strategy to record the smoothed monitoring indicators, overall load and resource usage permissions, and establishes a mapping table between sub-strategies and processor cores and memory quotas.

3. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 2, characterized in that: The monitoring metrics include processor utilization, memory usage, event response time from receiving market data to issuing orders, and internal event queue length for each strategy process. When calculating the overall load of sub-strategies, the account management module uses pre-configured weights to weight and synthesize various monitoring metrics.

4. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 3, characterized in that: The policy management module collects monitoring metrics from the operating system and policy process according to a preset sampling period. The account management module writes new monitoring values ​​into the corresponding sliding sampling window and removes the oldest monitoring value in each sampling period. The monitoring values ​​in the window are weighted and summed according to the weights corresponding to the sampling order to obtain the smoothed monitoring metrics.

5. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 4, characterized in that: Resource usage licenses include the minimum and maximum number of processor cores and the minimum and maximum memory quota for each sub-policy. When generating resource usage licenses, the account management module first ensures that each sub-policy receives no less than the minimum resource limit. When system resources are insufficient, the sub-policy with the lower priority is marked as restricted or suspended.

6. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 5, characterized in that: The trading process, strategy process, and market data selection module are deployed on the same physical server. The strategy process and the trading process communicate through a pair of shared memory queues to exchange order requests and counter reports. The strategy process also reads market data from the market data selection module through the shared memory queue and polls the shared memory queue in a busy-wait manner on the processor core allocated by the resource usage license.

7. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 6, characterized in that: The market data selection module starts an independent receiving thread for each market data source and performs field integrity and format checks on the received market data. It reorders out-of-order data according to timestamps to maintain the time order of each market data source. After selecting the target market data source from multiple market data sources based on arrival time and delay statistics, it writes it into a shared memory queue.

8. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 7, characterized in that: After receiving the order request written by the strategy process, the trading process generates an internally maintained global number for each order and checks it in conjunction with account funds, positions, and account-level risk control parameters. For orders that fail the check, a reward record containing the rejection reason is written to the shared memory queue. For orders that pass the check, the global number is retained to associate with subsequent counter rewards.

9. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 8, characterized in that: When the trading process sends an order request to different trading channels, it records the sending time and the corresponding channel identifier. When receiving a counter report, it records the report time and calculates the round-trip time for each trading channel. The round-trip time is statistically analyzed into channel delay data according to the time window. The step of selecting a channel based on the channel delay data determines the trading channel with the smaller delay.

10. The multi-account high-frequency trading system based on dynamic resource scheduling according to claim 9, characterized in that: The client sends account-level or strategy-level control instructions to the account management module. The account management module forwards the account-level control instructions to the trading process to control the order placement behavior of the sub-strategies under the corresponding account, and forwards the strategy-level control instructions to the corresponding strategy process to change the strategy's running status and parameters. The changed running status affects the calculation of subsequent resource usage licenses through monitoring indicators.

Images