A method, apparatus, device, and storage medium for monitoring securities trading.

Abstract

This application proposes a method, apparatus, device, and storage medium for monitoring securities trading. The monitoring method uses a first-level cache to store real-time market data and corresponding real-time timestamps. Based on the real-time timestamps and real-time market data in the first-level cache, historical data in the second-level cache is updated. The historical data stored in the second-level cache is determined based on a cache invalidation strategy corresponding to a user-defined monitoring indicator. Setting up a multi-level cache structure and adaptively storing historical data based on the set monitoring indicators helps reduce dependence on the database and improve computational efficiency. When a trading instruction is received and the number of monitoring indicators involved in the trading instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the updated historical data in the second-level cache and each monitoring indicator. The monitoring tasks are executed in parallel, and the monitoring result of each monitoring task is determined, which helps reduce cyclomatic complexity and improve monitoring efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for monitoring securities transactions. Background Technology

[0002] With the rapid development of the financial market, especially the widespread application of algorithmic trading and high-frequency trading, the securities market has shown characteristics such as high trading frequency, large data volume, and violent price fluctuations. During peak trading periods, exchanges can generate tens of thousands of market data per second, covering thousands of securities products, and the data update frequency can reach the millisecond level. At present, traditional trading instruction monitoring mainly includes the following two types: (1) Manual monitoring: relying on traders or risk control personnel to observe market dynamics and instruction execution at the terminal. This method is highly subjective, has a slow response, and is difficult to cope with complex and ever-changing market environments. It is easy to cause risk events due to human negligence; (2) Timed batch scanning mechanism: the system polls to obtain market data at fixed intervals (such as every 5 seconds or every 10 seconds) and conducts centralized checks on trading instructions. However, this method has obvious time delays and cannot capture abnormal trading behavior caused by instantaneous price fluctuations in a timely manner. At the same time, the monitoring logic and dependent data are usually located in the database, which consumes a lot of database resources and has low computational efficiency. In addition, monitoring indicators without dependencies are forced to be executed sequentially, resulting in low processing efficiency. Summary of the Invention

[0003] This application provides a method, apparatus, device, and storage medium for monitoring securities transactions to solve at least one problem existing in related technologies. The technical solution is as follows:

[0004] In a first aspect, embodiments of this application provide a method for monitoring securities transactions, including:

[0005] The first-level cache stores real-time market data and its corresponding real-time timestamp.

[0006] Based on the real-time timestamp and real-time market data in the first-level cache, the historical data in the second-level cache is updated. The historical data stored in the second-level cache is determined based on the cache invalidation policy corresponding to the monitoring indicators set by the user.

[0007] When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the historical data in the updated second-level cache and each monitoring indicator.

[0008] The monitoring tasks are executed in parallel to determine the monitoring results of each monitoring task.

[0009] In one implementation, based on the cache invalidation policy corresponding to the monitoring metrics set by the user, the historical data stored in the second-level cache is determined to include:

[0010] Obtain the monitoring metrics set by the user, extract the monitoring duration from the monitoring metrics as the time window length, and generate the corresponding rolling monitoring time window;

[0011] Based on the rolling monitoring time window, a corresponding cache invalidation strategy is generated, which stores the latest market data within the rolling monitoring time window as historical data in the second-level cache, and clears the market data in the second-level cache that is outside the latest rolling monitoring time window.

[0012] In one implementation, updating the historical data in the second-level cache based on the real-time timestamp and the real-time market data in the first-level cache includes:

[0013] Based on the real-time timestamp in the first-level cache, determine the latest rolling monitoring time window, and add the real-time market data in the first-level cache to the tail of the data queue of the rolling monitoring time window in the second-level cache;

[0014] When data addition is detected in the data queue, a cleanup operation is triggered. Starting from the head of the data queue, historical data whose time interval between the timestamp and the real-time timestamp exceeds the length of the time window are deleted, while the latest market data within the rolling monitoring time window is retained, thus completing the update of historical data in the second-level cache.

[0015] In one implementation, the first-level cache is a Redis cache, and the second-level cache is a local cache.

[0016] In one implementation, when a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, generating a monitoring task corresponding to each monitoring indicator based on the updated historical data in the second-level cache and each monitoring indicator includes:

[0017] When a trading instruction is received, all monitoring indicators enabled by the trading instruction are identified. The enabling or disabling of the monitoring indicators is based on dynamic user settings.

[0018] If there are multiple monitoring metrics, call the monitoring interface to determine the enumeration class corresponding to each monitoring metric.

[0019] Based on the computation class associated with each enumeration class and the historical data in the updated second-level cache, a monitoring task corresponding to each monitoring metric is generated.

[0020] In one embodiment, the method further includes:

[0021] Once the monitoring results of each monitoring task are determined, each monitoring result is compared with the monitoring rules of the corresponding monitoring indicators to generate a corresponding comparison result.

[0022] If the comparison result meets the monitoring rules, determine the corresponding target monitoring indicator and the instruction ID of the transaction instruction, and generate alarm information based on the target monitoring indicator and the instruction ID;

[0023] An alarm notification is generated based on the alarm information and the user's personalized alarm settings.

[0024] In one implementation, generating an alarm notification based on the alarm information and the user's personalized alarm settings includes:

[0025] Compare the settings of the personalized alarm with the target monitoring indicators involved in the alarm information;

[0026] When the personalized alarm settings include the target monitoring indicator involved in the alarm information, if there is one target monitoring indicator, the alarm information is used as an alarm notification; if there are multiple target monitoring indicators, the alarm information is aggregated to generate an alarm notification.

[0027] The personalized alarm settings can be customized through a visual configuration page.

[0028] Secondly, embodiments of this application provide a monitoring device for securities trading, comprising:

[0029] The first cache module is used to store real-time market data and corresponding real-time timestamps through the first-level cache.

[0030] The second cache module is used to update the historical data in the second cache according to the real-time timestamp and the real-time market data in the first cache. The historical data stored in the second cache is determined based on the cache invalidation strategy corresponding to the monitoring indicators set by the user.

[0031] The generation module is used to generate a monitoring task corresponding to each monitoring indicator when a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, based on the historical data in the updated second-level cache and each monitoring indicator.

[0032] The monitoring module is used to execute the monitoring tasks in parallel and determine the monitoring results of each monitoring task.

[0033] In one embodiment, the securities trading monitoring device further includes an alarm module, the alarm module being used for:

[0034] Once the monitoring results of each monitoring task are determined, each monitoring result is compared with the monitoring rules of the corresponding monitoring indicators to generate a corresponding comparison result.

[0035] If the comparison result meets the monitoring rules, determine the corresponding target monitoring indicator and the instruction ID of the transaction instruction, and generate alarm information based on the target monitoring indicator and the instruction ID;

[0036] An alarm notification is generated based on the alarm information and the user's personalized alarm settings.

[0037] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory, wherein the memory stores instructions that are loaded and executed by the processor to implement the methods in any of the above-described embodiments.

[0038] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed, implements the methods in any of the above-described embodiments.

[0039] The beneficial effects of the above technical solution include at least the following:

[0040] The first-level cache stores real-time market data and corresponding timestamps. Based on the timestamps and market data in the first-level cache, the historical data in the second-level cache is updated. The historical data stored in the second-level cache is determined based on the cache invalidation policy corresponding to the user-defined monitoring indicators. Setting up a multi-level cache structure and adaptively storing historical data based on the set monitoring indicators helps reduce the dependence on the database and improve computational efficiency. When a trading instruction is received and the number of monitoring indicators involved in the trading instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the updated historical data in the second-level cache and each monitoring indicator. The monitoring tasks are executed in parallel, and the monitoring result of each monitoring task is determined, which helps reduce cyclomatic complexity and improve monitoring efficiency.

[0041] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, these aspects, embodiments, and features will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0042] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0043] Figure 1 This is a flowchart illustrating the steps of a securities trading monitoring method according to an embodiment of this application;

[0044] Figure 2 This is a structural block diagram of a securities trading monitoring device according to an embodiment of this application;

[0045] Figure 3 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0046] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0047] In related technologies, the current monitoring system's timed batch scanning mechanism has the following drawbacks: (1) The system polls for market data at fixed intervals (such as every 5 seconds or every 10 seconds) and performs centralized checks on trading instructions, resulting in significant time delays and poor timeliness; (2) The monitoring logic and dependent data are both located in the database, and storage and computation are not separated. This leads to low computational efficiency, large database resource consumption, and the inability to horizontally expand computing power, which easily creates a performance bottleneck; (3) The monitoring indicators are calculated serially, resulting in low processing efficiency. Since there is no dependency between the indicators, they are forced to be executed sequentially, and the overall processing time increases linearly, making it difficult to meet the millisecond-level response requirements in high-frequency scenarios; (4) Poor scalability, adding new monitoring rules requires modification of the core code;

[0048] (5) The alarm information is severely fragmented, resulting in an "alarm storm" phenomenon that affects the sensitivity of alarm services.

[0049] Therefore, this application addresses the aforementioned deficiencies by providing a securities trading order monitoring method that achieves low-latency response, high-throughput processing, flexible scalability, and accurate alerts, in order to meet the risk control needs of the modern financial trading environment.

[0050] Reference Figure 1 The flowchart illustrates a securities trading monitoring method according to an embodiment of this application. The securities trading monitoring method may include at least steps S100-S400:

[0051] S100 stores real-time market data and corresponding real-time timestamps through the first-level cache.

[0052] S200: Based on the real-time timestamps and real-time market data in the first-level cache, update the historical data in the second-level cache. The historical data stored in the second-level cache is determined based on the cache invalidation policy corresponding to the monitoring indicators set by the user.

[0053] S300: When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the historical data in the updated second-level cache and each monitoring indicator.

[0054] S400: Execute monitoring tasks in parallel and determine the monitoring results of each monitoring task.

[0055] The technical solution of this application embodiment stores real-time market data and corresponding real-time timestamps in a first-level cache. Based on the real-time timestamps and real-time market data in the first-level cache, historical data in the second-level cache is updated. The historical data stored in the second-level cache is determined based on the cache invalidation policy corresponding to the monitoring indicators set by the user. Setting up a multi-level cache structure and adaptively storing historical data based on the set monitoring indicators helps to reduce the dependence on the database and improve computational efficiency. When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the updated historical data in the second-level cache and each monitoring indicator. The monitoring tasks are executed in parallel, and the monitoring result of each monitoring task is determined, which helps to reduce cyclomatic complexity and improve monitoring efficiency.

[0056] This application embodiment constructs a multi-level caching architecture, including a first-level cache and a second-level cache, supporting efficient access to real-time and historical data. The first-level cache is a Redis cache, and the second-level cache is a local cache. For example, if multiple servers are involved, and different servers have different instances (e.g., corresponding to different users), the first-level cache acts as a "broadcasting station." Each instance can obtain real-time information from the first-level cache and then use this information to update historical data in its respective instance's local cache. In this application embodiment, the first-level cache can use a hash table to store the latest market data for each security. Reading and writing only require one hash calculation and one memory access, thus providing at least microsecond-level read / write performance, ensuring fast acquisition of real-time market data and corresponding real-time timestamps even in high-concurrency scenarios.

[0057] In this embodiment, setting up a first-level cache to obtain real-time market data helps ensure data consistency across instances and avoids direct database overload. Furthermore, when a new instance starts, it can directly pull hot data from this high-speed first-level cache, which is much faster than pulling from the database, enabling rapid scaling. Additionally, a second-level cache further avoids memory waste. For example, if there are three instances, and each only has a single-level cache, each instance would have to cache all data, leading to data duplication. For instance, the latest market data would need to be stored separately, resulting in wasted memory. Therefore, a two-level cache achieves better memory savings.

[0058] In one implementation, a Redis publish / subscribe mechanism is used as an event bus to decouple from the external market data system. When the upstream market data system publishes the latest real-time market data, it will be published through a Redis channel. Then, by subscribing to the corresponding channel, the real-time market data and the corresponding real-time timestamp (all market data includes timestamps) are stored in the first-level cache, triggering the subsequent monitoring process.

[0059] In one implementation, determining the historical data stored in the second-level cache based on the cache invalidation policy corresponding to the user-defined monitoring metrics includes steps S001-S002:

[0060] S001. Obtain the monitoring metrics set by the user, extract the monitoring duration from the monitoring metrics as the time window length, and generate the corresponding rolling monitoring time window.

[0061] Optionally, different users can set corresponding monitoring indicators based on their needs, including but not limited to "maximum price difference in the past N minutes" and "market deviation in the past N minutes." In this case, the monitoring duration N from the monitoring indicator is extracted as the time window length to generate a corresponding rolling monitoring time window. For ease of explanation, for example, if N=5, then the time window length is 5 minutes, and a rolling monitoring time window with a time window length of 5 minutes is generated. It can be understood that since the monitoring indicator can be set as needed, the monitoring duration N can be changed accordingly.

[0062] S002. Based on the rolling monitoring time window, generate a corresponding cache invalidation policy, store the latest market data within the rolling monitoring time window as historical data in the second-level cache, and clear the market data in the second-level cache that is outside the latest rolling monitoring time window.

[0063] Optionally, a corresponding cache invalidation strategy is generated based on the rolling monitoring time window. The goal is to store historical data from the past 5 minutes and delete historical data older than 5 minutes. Specifically, the market data within the latest rolling monitoring time window is stored as historical data in the second-level cache. For example, the market data within the latest 5-minute rolling monitoring time window is stored as historical data in the second-level cache. Market data outside the latest rolling monitoring time window in the second-level cache is cleared, that is, market data older than 5 minutes that is outside the latest rolling monitoring time window is cleared. This retains only the data required for monitoring the current indicator, minimizing the data volume and avoiding the risk of overflow in the second-level cache. It should be noted that the monitoring indicator can be for one or more securities. If a security has different monitoring indicators with different monitoring durations N, or if the monitoring durations N of the monitoring indicators of different securities are different, then the second-level buffer will store historical data corresponding to different monitoring durations N. The principle is the same. For ease of explanation, this embodiment uses one monitoring indicator as an example. Other monitoring indicators are similar and will not be described in detail.

[0064] In one implementation, step S200 includes steps S210-S220:

[0065] S210. Based on the real-time timestamp in the first-level cache, determine the latest rolling monitoring time window and add the real-time market data in the first-level cache to the tail of the data queue of the rolling monitoring time window in the second-level cache.

[0066] Optionally, a corresponding data queue is configured for each rolling monitoring time window. After obtaining the real-time timestamp in the first-level cache, it can be known that the current time has been updated. At this time, the latest rolling monitoring time window is determined, and the real-time market data in the first-level cache is added to the tail of the data queue of the rolling monitoring time window in the second-level cache. The historical market data in the data queue is arranged in chronological order based on the timestamp, with the earliest obtained data at the head and the latest obtained data at the tail.

[0067] S220. When data addition is detected in the data queue, a cleanup operation is triggered. Starting from the head of the data queue, historical data whose time interval between the timestamp and the real-time timestamp exceeds the time window length is deleted. The latest market data within the rolling monitoring time window is retained, and the historical data in the second-level cache is updated.

[0068] Optionally, when data addition is detected in the data queue, a cleanup operation is triggered. The check starts from the head of the data queue to ensure the efficiency of checking and updating, reduce the amount of data processing, and delete historical data whose time interval between the timestamp and the real-time timestamp exceeds the length of the time window. For example, the time interval between the timestamp and the real-time timestamp of each historical data in the data queue is calculated, and historical data with a time interval exceeding 5 minutes is deleted. The latest market data within the rolling monitoring time window (i.e., within 5 minutes) is retained to complete the update of historical data in the second-level cache.

[0069] In one implementation, step S300 includes steps S310-S330:

[0070] S310. When a trading instruction is received, identify all monitoring indicators enabled by the trading instruction.

[0071] Optionally, when new real-time market data is available and the historical data in the second-level cache is updated, the system will immediately query all trading orders for the securities (which may be one or more) corresponding to this data. If a trading order is received (monitored), for example, when a user (such as an investment manager) issues a corresponding trading order, monitoring is required. At this time, all monitoring indicators that are pre-configured and enabled on demand for the corresponding trading order will be identified. It should be noted that users can configure monitoring indicators through the configuration page, for example, by using checkboxes. By enabling or disabling the corresponding monitoring indicators, the system can dynamically determine whether to enable or disable them, which is convenient. For example, when a checkbox is enabled or disabled, the activation status will be updated. Subsequently, when processing market events, the system will automatically skip all monitoring indicator calculation tasks marked as "stopped," thereby achieving dynamic management capabilities without restarting the service.

[0072] S320. If there are multiple monitoring metrics, call the monitoring interface to determine the enumeration class corresponding to each monitoring metric.

[0073] Optionally, each transaction instruction can be assigned to a separate "large" task, with each monitoring indicator involved serving as a "small" monitoring task. If there are multiple monitoring indicators, the system will call the monitoring interface to determine the predefined enumeration class corresponding to each monitoring indicator.

[0074] It is understandable that if there is only one monitoring metric, the corresponding calling steps are the same, and there is only one execution of the monitoring task. Therefore, there is no distinction between serial and parallel execution, so it will not be elaborated further.

[0075] S330. Based on the computation class associated with each enumeration class and the historical data in the updated second-level cache, generate a monitoring task corresponding to each monitoring metric.

[0076] Optionally, based on the calculation class associated with each enumeration class pre-configured in the monitoring interface, the monitoring task corresponding to each monitoring metric is generated using the historical data in the updated second-level cache, and the corresponding calculation is completed through the calculation class when the monitoring task is executed subsequently.

[0077] In one implementation, step S400 specifically involves executing monitoring tasks in parallel. During execution of each monitoring task, calculations are performed using a computational class and corresponding updated historical data in the second-level cache. The calculation result is then used as the corresponding monitoring result, thereby determining the monitoring result for each monitoring task. For example, if the monitoring indicator is "the price fluctuation range of the largest price difference in the past 5 minutes," then the monitoring result is the calculated price fluctuation range of "the largest price difference in the past 5 minutes."

[0078] In this embodiment, since all monitoring tasks are executed in parallel, assuming there are N1 transaction instructions and N2 monitoring indicators for each instruction, the total time for processing the N1 transaction instructions no longer depends on the sequential N1 × N2, but is approximately equal to the time required to process the "most time-consuming" instruction, specifically the monitoring task of the most time-consuming monitoring indicator within a given instruction. Therefore, the overall computational cyclomatic complexity is optimized from O(N1 × N2) to approximately O(N2), significantly reducing cyclomatic complexity. This is particularly beneficial in high-concurrency scenarios, resulting in a substantial increase in throughput and performance.

[0079] In one embodiment, the securities trading monitoring method of this application embodiment may further include steps S510-S530:

[0080] S510. Given the monitoring results of each monitoring task, compare each monitoring result with the monitoring rules of the corresponding monitoring indicators to generate the corresponding comparison results.

[0081] Optionally, monitoring rules can also be set by the user on the configuration page as needed, such as "the price fluctuation range of the largest price difference in the past 5 minutes" exceeding z% (z is a custom threshold), and "the market deviation in the past 5 minutes" exceeding x% (x is a custom threshold). Therefore, after determining the monitoring results of each monitoring task, each monitoring result is compared with the monitoring rules of the corresponding monitoring indicator to generate the corresponding comparison results.

[0082] S520. If the comparison result meets the monitoring rules, determine the corresponding target monitoring indicator and the instruction ID of the transaction instruction, and generate alarm information based on the target monitoring indicator and the instruction ID.

[0083] Optionally, if the comparison result meets the monitoring rules, such as the price fluctuation range exceeding z%, then the corresponding target monitoring indicator is determined as "the price fluctuation range of the largest price difference in the past 5 minutes" and the instruction ID of the trading instruction (each trading instruction will be configured with a unique ID by the system. For example, if the trading instruction triggers the target monitoring indicator, the corresponding instruction ID will be determined). Then, an alarm message is generated based on the target monitoring indicator and the instruction ID.

[0084] S530 generates alarm notifications based on alarm information and the user's personalized alarm settings.

[0085] Optionally, the system also provides a visual configuration page for users (investment managers / traders) to set personalized alerts and determine the personalized configuration settings.

[0086] In this embodiment, the settings of the personalized alarm are compared with the target monitoring indicators involved in the alarm information to see if the current personalized alarm settings include the target monitoring indicators involved in the current alarm information. If not, an alarm notification is issued; otherwise, an alarm notification is required. Specifically:

[0087] 1. When the personalized alarm settings include the target monitoring indicator involved in the alarm information, if there is only one target monitoring indicator, the alarm information will be directly used as the alarm notification.

[0088] 2. If there are multiple target monitoring indicators, the alarm information will be aggregated to generate an alarm notification.

[0089] In this embodiment of the application, to avoid alarm storms, alarm information is aggregated when multiple target monitoring indicators are involved. For example, if the target monitoring indicators include monitoring indicator #1 and monitoring indicator #2, the alarm information before aggregation within a certain period of time (e.g., M seconds) may be:

[0090] Alert 1: Securities A violated monitoring indicator #1, involving transaction order ID: 123

[0091] Alert Message 2: Securities B violated monitoring indicator #1, involving transaction order ID: 456

[0092] Alert Message 3: Securities A violated monitoring indicator #2, involving transaction order ID: 123

[0093] Alarm Message 4: Securities B violated monitoring indicator #2, involving transaction instruction ID: 456. After aggregation, for example, if it is the same user, the alarm message becomes: Securities A and Securities B violated monitoring indicators #1 and #2, involving investment instruction IDs: 123 and 456; or, if it is different users, for one user, the alarm message becomes: Securities A violated monitoring indicators #1 and #2, investment instruction ID: 123. That is, alarm messages related to the same transaction instruction ID can be aggregated, or alarm messages related to the same user can be aggregated. The alarm interval M corresponding to the aggregation can also be personalized to avoid repeated pushes of alarms in a short period of time, thus reducing information noise and preventing users from being overwhelmed by repeated or similar alarm messages. Therefore, this application embodiment provides a complete alarm mechanism, supports adaptive alarm content generation, aggregates successive alarm results, generates personalized alarm notifications for each relevant trader, improves the readability and usability of alarm notifications; at the same time, the access control strategy of alarm interval M is introduced to avoid repeated reminders of the same instruction and the same security in a short period of time, which would cause interference.

[0094] This application embodiment utilizes a Redis event-driven architecture, a multi-level caching architecture, and an asynchronous parallel computing framework to execute monitoring tasks in parallel, significantly improving the response speed and processing capability of investment transaction instruction monitoring. Simultaneously, the monitoring interface clarifies the specifications of the implementation classes (enumeration classes, calculation classes), specifying what methods should be implemented and what parameters should be passed to those methods. Each implementation class under the interface implements the specific logic for calculating and monitoring corresponding indicators. Therefore, for the development team, different development members can develop monitoring indicators based on the same standardized protocol of the monitoring interface and a robust code framework without encountering significant obstacles. This supports rapid expansion and development of monitoring indicators, and adding new monitoring rules requires no modification to the core code.

[0095] Reference Figure 2 The diagram illustrates a structural block diagram of a securities trading monitoring device according to an embodiment of this application. The device may include:

[0096] The first cache module is used to store real-time market data and corresponding real-time timestamps through the first-level cache.

[0097] The second cache module is used to update the historical data in the second cache based on the real-time timestamps and real-time market data in the first cache. The historical data stored in the second cache is determined based on the cache invalidation strategy corresponding to the monitoring indicators set by the user.

[0098] The generation module is used to generate a monitoring task corresponding to each monitoring indicator when a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, based on the historical data in the updated second-level cache and each monitoring indicator.

[0099] The monitoring module is used to execute monitoring tasks in parallel and determine the monitoring results of each monitoring task.

[0100] In one embodiment, the securities trading monitoring device further includes an alarm module, which is used for:

[0101] Once the monitoring results of each monitoring task are determined, each monitoring result is compared with the monitoring rules of the corresponding monitoring indicators to generate the corresponding comparison results.

[0102] If the comparison result meets the monitoring rules, determine the corresponding target monitoring indicator and the instruction ID of the transaction instruction, and generate alarm information based on the target monitoring indicator and the instruction ID.

[0103] Alarm notifications are generated based on alarm information and the user's personalized alarm settings.

[0104] The functions of each module in the device of this application embodiment can be found in the corresponding description in the above method, and will not be repeated here.

[0105] Reference Figure 3 The diagram illustrates a structural block diagram of an electronic device according to an embodiment of this application. The electronic device includes a memory 310 and a processor 320. The memory 310 stores instructions that can be executed on the processor 320. The processor 320 loads and executes these instructions to implement the securities trading monitoring method described in the above embodiment. The number of memories 310 and processors 320 can be one or more.

[0106] In one embodiment, the electronic device further includes a communication interface 330 for communicating with external devices and exchanging data. If the memory 310, processor 320, and communication interface 330 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0107] Optionally, in a specific implementation, if the memory 310, processor 320 and communication interface 330 are integrated on a single chip, the memory 310, processor 320 and communication interface 330 can communicate with each other through an internal interface.

[0108] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the securities trading monitoring method provided in the above embodiments.

[0109] This application also provides a chip, which includes a processor for calling and executing instructions stored in a memory, causing a communication device on which the chip is installed to perform the method provided in this application.

[0110] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0111] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0112] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0113] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0114] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0115] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0116] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0117] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0118] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0119] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0120] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all 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 method for monitoring securities trading, characterized in that, include: The first-level cache stores real-time market data and its corresponding real-time timestamp. Based on the real-time timestamp and real-time market data in the first-level cache, the historical data in the second-level cache is updated. The historical data stored in the second-level cache is determined based on the cache invalidation policy corresponding to the monitoring indicators set by the user. When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, a monitoring task corresponding to each monitoring indicator is generated based on the historical data in the updated second-level cache and each monitoring indicator. The monitoring tasks are executed in parallel to determine the monitoring results of each monitoring task. When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, generating a monitoring task corresponding to each monitoring indicator based on the updated historical data in the second-level cache and each monitoring indicator includes: When a trading instruction is received, all monitoring indicators enabled by the trading instruction are identified. The enabling or disabling of the monitoring indicators is based on dynamic user settings. If there are multiple monitoring metrics, call the monitoring interface to determine the enumeration class corresponding to each monitoring metric. Based on the computation class associated with each enumeration class and the historical data in the updated second-level cache, a monitoring task corresponding to each monitoring metric is generated.

2. The method for monitoring securities trading according to claim 1, characterized in that: Based on the cache invalidation policy corresponding to the user-defined monitoring metrics, the historical data stored in the second-level cache includes: Obtain the monitoring metrics set by the user, extract the monitoring duration from the monitoring metrics as the time window length, and generate the corresponding rolling monitoring time window; Based on the rolling monitoring time window, a corresponding cache invalidation strategy is generated, which stores the latest market data within the rolling monitoring time window as historical data in the second-level cache, and clears the market data in the second-level cache that is outside the latest rolling monitoring time window.

3. The method for monitoring securities trading according to claim 2, characterized in that: The step of updating the historical data in the second-level cache based on the real-time timestamp and the real-time market data in the first-level cache includes: Based on the real-time timestamp in the first-level cache, determine the latest rolling monitoring time window, and add the real-time market data in the first-level cache to the tail of the data queue of the rolling monitoring time window in the second-level cache; When data addition is detected in the data queue, a cleanup operation is triggered. Starting from the head of the data queue, historical data whose time interval between the timestamp and the real-time timestamp exceeds the length of the time window are deleted, while the latest market data within the rolling monitoring time window is retained, thus completing the update of historical data in the second-level cache.

4. The method for monitoring securities trading according to claim 1, characterized in that: The first-level cache is a Redis cache, and the second-level cache is a local cache.

5. The method for monitoring securities trading according to any one of claims 1-4, characterized in that: The method further includes: Once the monitoring results of each monitoring task are determined, each monitoring result is compared with the monitoring rules of the corresponding monitoring indicators to generate a corresponding comparison result. If the comparison result meets the monitoring rules, determine the corresponding target monitoring indicator and the instruction ID of the transaction instruction, and generate alarm information based on the target monitoring indicator and the instruction ID; An alarm notification is generated based on the alarm information and the user's personalized alarm settings.

6. The method for monitoring securities trading according to claim 5, characterized in that: The step of generating an alarm notification based on the alarm information and the user's personalized alarm settings includes: Compare the settings of the personalized alarm with the target monitoring indicators involved in the alarm information; When the personalized alarm settings include the target monitoring indicator involved in the alarm information, if there is one target monitoring indicator, the alarm information is used as an alarm notification; if there are multiple target monitoring indicators, the alarm information is aggregated to generate an alarm notification. The personalized alarm settings can be customized through a visual configuration page.

7. A monitoring device for securities trading, characterized in that, include: The first cache module is used to store real-time market data and corresponding real-time timestamps through the first-level cache. The second cache module is used to update the historical data in the second cache according to the real-time timestamp and the real-time market data in the first cache. The historical data stored in the second cache is determined based on the cache invalidation strategy corresponding to the monitoring indicators set by the user. The generation module is used to generate a monitoring task corresponding to each monitoring indicator when a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, based on the historical data in the updated second-level cache and each monitoring indicator. The monitoring module is used to execute the monitoring tasks in parallel and determine the monitoring results of each monitoring task. When a transaction instruction is received and the number of monitoring indicators involved in the transaction instruction is multiple, generating a monitoring task corresponding to each monitoring indicator based on the updated historical data in the second-level cache and each monitoring indicator includes: When a trading instruction is received, all monitoring indicators enabled by the trading instruction are identified. The enabling or disabling of the monitoring indicators is based on dynamic user settings. If there are multiple monitoring metrics, call the monitoring interface to determine the enumeration class corresponding to each monitoring metric. Based on the computation class associated with each enumeration class and the historical data in the updated second-level cache, a monitoring task corresponding to each monitoring metric is generated.

8. An electronic device, characterized in that, include: A processor and a memory, wherein instructions are stored in the memory and loaded and executed by the processor to implement the method as claimed in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program therein, which, when executed, implements the method as described in any one of claims 1-6.

Images