An off-site derivative transaction order display method and system based on two-level cache

Abstract

The application discloses a kind of based on two-level cache's off-site derivative transaction order display method and system, it is related to transaction order data processing field.Initialization order data manager, dynamic refresh controller and each order view, and send order change data acquisition request;Get the full order data of target transaction day, build first-level cache;Based on first-level cache, build the second-level cache that meets each order view screening condition, and initialize the flag bit of each second-level cache;In response to order change push message, update first-level cache, and according to the screening condition of each order view determine the second-level cache of order change data attribution, set its flag bit to be updated state;In response to the refresh event triggered when reaching refresh time interval, according to the flag bit of second-level cache, order view is updated.The application is based on two-level cache structure and flag bit mechanism, dynamically calculates view refresh frequency, and realizes the balance of smoothness and real-time.

Description

Technical Field

[0001] This invention relates to the field of transaction order data processing technology, specifically to a method and system for displaying over-the-counter derivatives transaction orders based on a two-level cache. Background Technology

[0002] With the rapid development of my country's over-the-counter (OTC) derivatives market, the trading volume of OTC derivatives, represented by products such as total return swaps and OTC options, has continued to increase. There is a widespread practical need to display, update the status of, and perform interface operations on OTC derivatives trading orders (hereinafter referred to as orders) in front-end application systems.

[0003] Typically, transaction orders are stored in a cache middleware or database of a backend service. After the frontend application system retrieves the order data from the backend service, it is responsible for processing and rendering the order data and displaying it to the user in the form of an order view. In practical application scenarios, users often need to view and process a large number of transaction orders simultaneously. They usually open multiple order views at the same time and set independent order filtering conditions for each order view to quickly locate the order and observe the order status updates under each filtering condition.

[0004] Due to the frequent changes in order status during over-the-counter derivatives trading, the front-end application system needs to receive, parse, and display order update messages pushed by the back-end service on the front-end interface while maintaining low latency. However, with the existence of multiple order views, how to achieve data updates for multiple order views while ensuring smooth interface interaction and ensuring the synchronization of order data across different order views has become a pressing technical problem for the front-end application system. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method and system for displaying over-the-counter derivatives trading orders based on a two-level cache.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] This invention provides a method for displaying over-the-counter derivatives trading orders based on a two-level cache. The method involves deploying a server and a client, with the client deploying an order data manager, a dynamic refresh controller, and at least one order view. The method implements order data display and updating based on the two-level cache through the following steps S1 to S5:

[0008] Step S1: Initialize the order data manager, dynamic refresh controller, and each order view, and send a request to the server to obtain real-time order change data through the order data manager;

[0009] In step S2, in response to the data query request, the server sends all order data for the target trading day to the order data manager, and the order data manager builds a first-level cache, which includes order identifiers, order data, and parent-child relationship mappings between orders.

[0010] Step S3: For each order view, filter out the order data that meets the filtering conditions of the order view from the first-level cache, and build the second-level cache corresponding to the order view. At the same time, initialize the flag of the second-level cache to the pending update state. The second-level cache includes the order view identifier, filtering conditions, flag, and a set of order identifiers belonging to the order view.

[0011] Step S4: In response to the order change push message, the order data manager parses the order change push message, obtains the order change data and updates the first-level cache. Further, based on the filtering conditions of each order view, it determines the second-level cache to which the order change data belongs and sets the flag of the second-level cache to which the order change data belongs to the pending update status.

[0012] Step S5: The dynamic refresh controller collects operating status parameters and calculates the refresh time interval for the order view; in response to the refresh event triggered when the refresh time interval is reached, for each order view, according to the order view... Figure 2 The flag for the first-level cache is used to determine whether to update the order view. If so, based on the order identifier set, the corresponding order data and the parent-child relationships between orders are retrieved from the first-level cache, and the order view is updated. Further updates to the order view are then performed. Figure 2 Set the level cache flag to not updated; otherwise, return directly to step S5.

[0013] Furthermore, the order identifier includes a customer order identifier, an internal order identifier, and an executed order identifier; the order identifier set includes an array of customer order identifiers, an array of internal order identifiers, and an array of executed order identifiers, and each order identifier array includes identifiers for recording customer orders, internal orders, and executed orders belonging to each order view.

[0014] Further, the operation of updating the first-level cache in step S4 is as follows: obtain the order change identifier of the order change data, determine whether there is an order identifier in the first-level cache that is the same as the order change identifier, if so, update the order data corresponding to the order identifier; otherwise, according to the parent-child relationship mapping between orders, filter out the parent order of the order change data from the first-level cache, add the order change data and its change identifier to the first-level cache, and at the same time construct the parent-child relationship mapping.

[0015] Furthermore, the dynamic refresh controller calculates the next refresh interval by collecting data on order changes, the percentage of views to be updated, terminal CPU usage, terminal memory usage, the target transaction period, and user policies within a preset time frame, using the following formula:

[0016] ;

[0017] ;

[0018] in, This is the next refresh interval; This is the original refresh time interval; Minimum refresh interval; This is the maximum refresh interval. For boundary constraint functions; The baseline refresh time interval; Used to identify trading sessions; This is the order change intensity factor; The percentage factor of the view to be updated; CPU utilization factor; This is a memory usage factor; To refresh the stress factor; For user strategy factors; This is the weighting coefficient for the intensity of order changes; The weighting coefficient for the proportion of the view to be updated; This is the CPU utilization weighting coefficient; This is a weighting coefficient for memory usage. To refresh the pressure weighting coefficient; The weighting coefficients affect user strategies.

[0019] Furthermore, the operation of updating the order view in step S5 specifically involves: constructing a hierarchical structure between orders based on the parent-child relationship between them, and further displaying the order update results in a tree structure in the order view.

[0020] Furthermore, after updating the order view in step S5, the method further includes: determining whether the client is in a closed state; if so, ending the display and update of the order view; otherwise, returning to step S4.

[0021] Furthermore, the first-level cache is protected using a read-write lock mechanism;

[0022] Specifically, in response to an order change push message, the update thread acquires a write lock to update the first-level cache; in response to a timed event, the order view refresh thread acquires a read lock to read the first-level cache.

[0023] Another aspect of the present invention provides an OTC derivatives trading order display system based on a two-level cache, used to implement the OTC derivatives trading order display method based on a two-level cache, comprising:

[0024] The order data management module is used to interact with the server, receive order change push messages, and manage cached data;

[0025] The first-level cache module is used to store all order data and the parent-child relationship mapping between orders;

[0026] The second-level cache module is used to build a corresponding second-level cache for each order view. The second-level cache includes the order view identifier, filter conditions, flag bits, and the set of order identifiers corresponding to each order view.

[0027] The dynamic refresh scheduling module is used to calculate the refresh time interval based on the running status parameters, thereby triggering refresh events for each order view;

[0028] The order view module is used to respond to refresh events, read the corresponding flag bit of the second-level cache, and when the flag bit is in the pending update state, obtain the corresponding order data and the parent-child relationship between each order from the first-level cache module, and update the order view.

[0029] The beneficial effects of adopting the above technical solution are as follows:

[0030] (1) This invention achieves data synchronization of each order view by storing and integrating the first-level cache and the second-level cache independently, effectively solving the problem that the order view is refreshed immediately when an order change is received in the prior art, and the frequent refresh of the order view in a short period of time will cause the interface to freeze.

[0031] (2) The present invention adopts a dynamic refresh event mechanism, which comprehensively considers factors such as the number of order change pushes per unit time, the proportion of views to be updated, the terminal CPU usage rate, the terminal memory usage rate, the current transaction period and user strategies, and dynamically adjusts the refresh time interval used for the next round of refresh events of the order view.

[0032] (3) In the refresh event, the order view of the present invention can quickly determine whether there is data update in the order view through the flag of the second-level cache, and can merge multiple data updates between two refresh events into one view refresh, avoiding the lag caused by frequent refresh of the order view in a short period of time, and ensuring the smoothness of client interaction. Attached Figure Description

[0033] Figure 1 This is a structural diagram of the OTC derivatives trading order display method and system based on two-level caching according to the present invention.

[0034] Figure 2 This is a flowchart of a method for displaying over-the-counter derivatives trading orders based on a two-level cache, according to the present invention.

[0035] Figure 3 This is a diagram of the first-level cache structure of the present invention;

[0036] Figure 4 This is a diagram of the secondary cache structure of the present invention. Detailed Implementation

[0037] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings.

[0038] Example 1:

[0039] refer to Figure 1 and Figure 2 A method for displaying over-the-counter derivatives trading orders based on a two-level cache is proposed. This method involves deploying a server and a client, with the client deploying an order data manager, a dynamic refresh controller, and at least one order view. The order data display and update based on the two-level cache are implemented according to the following steps S1 to S5:

[0040] Step S1: Initialize the order data manager, dynamic refresh controller, and each order view, and send a request to the server to obtain real-time order change data through the order data manager;

[0041] In step S2, in response to the data query request, the server sends all order data for the target trading day to the order data manager, and the order data manager builds a first-level cache, which includes order identifiers, order data, and parent-child relationship mappings between orders.

[0042] Step S3: For each order view, filter out the order data that meets the filtering conditions of the order view from the first-level cache, and build the second-level cache corresponding to the order view. At the same time, initialize the flag of the second-level cache to the pending update state. The second-level cache includes the order view identifier, filtering conditions, flag, and a set of order identifiers belonging to the order view.

[0043] Step S4: In response to the order change push message, the order data manager parses the order change push message, obtains the order change data and updates the first-level cache. Further, based on the filtering conditions of each order view, it determines the second-level cache to which the order change data belongs and sets the flag of the second-level cache to which the order change data belongs to the pending update status.

[0044] Step S5: The dynamic refresh controller collects operating status parameters and calculates the refresh time interval for the order view; in response to the refresh event triggered when the refresh time interval is reached, for each order view, according to the order view... Figure 2The first-level cache flag determines whether to update the order view. If so, based on the order identifier set, the corresponding order data and the parent-child relationships between orders are retrieved from the first-level cache, and the hierarchical structure between orders is constructed. The order update results are then displayed in a tree structure in the order view, and the order is viewed as a separate item. Figure 2 Set the level cache flag to not updated; otherwise, return directly to step S5.

[0045] Preferably, after updating the order view in step S5, the method further includes: determining whether the client is in a closed state; if so, ending the display and update of the order view; otherwise, returning to step S4.

[0046] In this embodiment, the order data manager is a functional module for data transmission between the client and the server. It can initiate order query requests to the server and receive and parse order change push messages sent by the server, and has the ability to manage cached data. The order view is an interface module in the client that directly interacts with the user. It can display orders in a tree structure and filter and display orders that meet the filter conditions by setting filter conditions. The server is used to provide data sources for the client, can respond to the client's query requests, and can send order change push messages to the client when an order changes.

[0047] Furthermore, orders can be categorized by type into customer orders initiated by the customer, execution orders derived by the trader from customer orders, and internal orders split from customer orders according to the trader's responsibilities. There is a parent-child relationship between these three order types; that is, execution orders do not exist independently but as child orders of customer orders or internal orders, while internal orders are split from customer orders and exist as child orders of customer orders or parent orders of execution orders.

[0048] In this embodiment, the first-level cache is a global singleton order cache in the client, including customer order identifiers, internal order identifiers, executed order identifiers, complete and detailed order data for all orders on the target transaction day, and parent-child relationship mappings between orders. (See reference...) Figure 3The first-level cache contains two hash tables: an order identifier (ID)-order data relationship mapping and an order parent-child relationship mapping. The order identifier (ID)-order data relationship mapping uses the order identifier (ID) as the key and key-value pairs (Map) as the value, recording detailed data for customer orders, internal orders, and executed orders. It can be used to look up order details by order identifier (ID). The order parent-child relationship mapping records the parent-child relationship between orders. The key is the parent order identifier (ID), and the value is the child order identifier (ID). Since one parent order can correspond to multiple child orders, this mapping uses a multi-hash table structure, which can record multiple key-value pairs with the same parent order identifier (ID). It can be used to look up child orders by parent order identifier, and vice versa.

[0049] Furthermore, the operation of updating the first-level cache is as follows: obtain the order change identifier of the order change data, determine whether there is an order identifier in the first-level cache that is the same as the order change identifier, if so, update the order data corresponding to the order identifier in the order identifier (ID)-order data relationship mapping; otherwise, according to the parent-child relationship mapping between orders, filter out the parent order of the order change data from the first-level cache, and add the order change data and its change identifier to the order identifier (ID)-order data relationship mapping and the order parent-child relationship mapping.

[0050] refer to Figure 4 In this embodiment, the second-level cache is generated by the first-level cache based on the filtering conditions of each order view. It does not directly contain the full order data, but only includes the order view identifier, filtering conditions, flag bits, and the set of order identifiers belonging to that order view. Figure 1 One-to-one correspondence; wherein, the order identifier set includes a customer order identifier array, an internal order identifier array, and an execution order identifier array, and each order identifier array includes identifiers used to record customer orders, internal orders, and execution orders belonging to each order view.

[0051] Furthermore, when determining the secondary cache to which the order change data belongs, if the changed order is a new order, its order identifier is updated into the corresponding type of order identifier array, and the flag in the secondary cache is set to pending update; if the changed order is an existing order, the flag is directly set to pending update.

[0052] In this embodiment, the client only performs an order query once during initialization or after reconnecting to the server. Order updates are implemented entirely through order change push messages, reducing the traffic pressure on the server from frequent queries. When the server sends an order change push to the client, the order data manager parses and updates the two-level cache. Each order view quickly identifies whether there are data updates for orders under its own level through a flag in the second-level cache. When an order view is updated, it first retrieves the order identifier belonging to that order view from the second-level cache, and then queries the full order data corresponding to the order identifier from the first-level cache. Since the second-level cache itself only stores the order index, the complete order data displayed in the order view all come from the global singleton first-level cache, ensuring data consistency when the same order appears in multiple order views simultaneously.

[0053] Furthermore, the dynamic refresh controller collects data on order changes, the percentage of views to be updated, terminal CPU utilization, terminal memory utilization, the target transaction period, and user policies within a preset time period. Specifically, the order change volume and the percentage of views to be updated reflect the real-time requirements of current order display; the terminal CPU utilization and terminal memory utilization reflect the resource pressure on the client; the target transaction period determines the baseline refresh rhythm for different scenarios; and the user policy reflects the user's preference for real-time priority, smoothness priority, or a balanced mode. The next refresh interval is calculated using the following formula:

[0054] ;

[0055] ;

[0056] in, This is the next refresh interval, i.e., the actual time interval used by the dynamic refresh controller; This is the original refresh time interval; This is the minimum refresh interval, used to avoid refreshing too frequently; This is the maximum refresh interval, used to avoid excessively slow refresh rates; For boundary constraint functions, the variables Limited to the range Inside; The baseline refresh time interval changes with the trading session identifier; It serves as a marker for trading periods, categorized into active trading periods, regular trading periods, and inactive trading periods. This is the order change intensity factor, representing the number of order changes per unit time. This is the percentage factor of the view to be updated, indicating the proportion of the number of order views to be updated to the total number of order views. CPU utilization factor; This is a memory usage factor; The refresh pressure factor is derived from the unprocessed update backlog, the time taken in the previous refresh round, or a combination thereof. This is a user strategy factor used to indicate the direction of user action strategy intervention; This is the weighting coefficient for the intensity of order changes; The weighting coefficient for the proportion of the view to be updated; This is the CPU utilization weighting coefficient; This is a weighting coefficient for memory usage. To refresh the pressure weighting coefficient; The weighting coefficients affect user strategies.

[0057] Preferably, when the user adopts a real-time priority strategy, the user strategy factor... This is used to shorten the refresh interval; when the user adopts the balanced mode, the user policy factor... When users adopt a fluency-first strategy, the user strategy factor... This is used to relax the refresh interval.

[0058] Furthermore, considering that different dimensional indicators need to be used in the calculation, the order change intensity factor, the percentage of views to be updated factor, the CPU utilization factor, the memory utilization factor, and the refresh pressure factor can be normalized before being substituted into the above formula.

[0059] Furthermore, the first-level cache is protected using a read-write lock mechanism;

[0060] Specifically, in response to an order change push message, the update thread acquires a write lock to update the first-level cache; in response to a timed event, the order view refresh thread acquires a read lock to read the first-level cache.

[0061] Example 2:

[0062] Another aspect of the present invention provides an OTC derivatives trading order display system based on a two-level cache, used to implement the OTC derivatives trading order display method based on a two-level cache, comprising:

[0063] The order data management module is used to interact with the server, receive order change push messages, and manage cached data;

[0064] The first-level cache module is used to store all order data and the parent-child relationship mapping between orders;

[0065] The second-level cache module is used to build a corresponding second-level cache for each order view. The second-level cache includes the order view identifier, filter conditions, flag bits, and the set of order identifiers corresponding to each order view.

[0066] The dynamic refresh scheduling module is used to calculate the refresh time interval based on the running status parameters, thereby triggering refresh events for each order view;

[0067] The order view module is used to respond to refresh events, read the corresponding flag bit of the second-level cache, and when the flag bit is in the pending update state, obtain the corresponding order data and the parent-child relationship between each order from the first-level cache module, and update the order view.

[0068] The above description is merely a preferred embodiment of the present invention and does not constitute any limitation on the present invention. Any simple modifications, alterations, or equivalent structural changes made to the above embodiments based on the technical essence of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for displaying over-the-counter derivatives trading orders based on a two-level cache, characterized in that, Deploy the server and client, and deploy the order data manager, dynamic refresh controller, and at least one order view on the client. Implement order data display and updates based on two-level caching according to steps S1 to S5 as follows: Step S1: Initialize the order data manager, dynamic refresh controller, and each order view, and send a request to the server to obtain real-time order change data through the order data manager; In step S2, in response to the data query request, the server sends all order data for the target trading day to the order data manager, and the order data manager builds a first-level cache, which includes order identifiers, order data, and parent-child relationship mappings between orders. Step S3: For each order view, filter out the order data that meets the filtering conditions of the order view from the first-level cache, and build the second-level cache corresponding to the order view. At the same time, initialize the flag of the second-level cache to the pending update state. The second-level cache includes the order view identifier, filtering conditions, flag, and a set of order identifiers belonging to the order view. Step S4: In response to the order change push message, the order data manager parses the order change push message, obtains the order change data and updates the first-level cache. Further, based on the filtering conditions of each order view, it determines the second-level cache to which the order change data belongs and sets the flag of the second-level cache to which the order change data belongs to the pending update status. Step S5: The dynamic refresh controller collects the running status parameters and calculates the refresh time interval of the order view; In response to the refresh event triggered when the refresh interval is reached, for each order view, it is determined whether to update the order view based on the flag of the second-level cache of the order view. If yes, the corresponding order data and the parent-child relationship between each order are obtained from the first-level cache based on the order identifier set, and the order view is updated. The flag of the second-level cache of the order view is further set to not updated; otherwise, the process returns directly to step S5.

2. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, The order identifiers include customer order identifiers, internal order identifiers, and executed order identifiers; the order identifier set includes an array of customer order identifiers, an array of internal order identifiers, and an array of executed order identifiers, and each order identifier array includes identifiers for recording customer orders, internal orders, and executed orders belonging to each order view.

3. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, The operation of updating the first-level cache in step S4 is as follows: obtain the order change identifier of the order change data, determine whether there is an order identifier in the first-level cache that is the same as the order change identifier, and if so, update the order data corresponding to the order identifier. Otherwise, based on the parent-child relationship mapping between orders, the parent order of the order change data is selected from the first-level cache, and the order change data and its change identifier are added to the first-level cache, while the parent-child relationship mapping is constructed.

4. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, The dynamic refresh controller calculates the next refresh interval by collecting data on order changes, the percentage of views to be updated, terminal CPU usage, terminal memory usage, target transaction period, and user policies within a preset time frame, using the following formula: ； ； in, This is the next refresh interval; This is the original refresh time interval; Minimum refresh interval; This is the maximum refresh interval. For boundary constraint functions; The baseline refresh time interval; Used to identify trading sessions; This is the order change intensity factor; The percentage factor of the view to be updated; CPU utilization factor; This is a memory usage factor; To refresh the stress factor; For user strategy factors; This is the weighting coefficient for the intensity of order changes; The weighting coefficient for the proportion of the view to be updated; This is the CPU utilization weighting coefficient; This is a weighting coefficient for memory usage. To refresh the pressure weighting coefficient; The weighting coefficients affect user strategies.

5. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, The operation of updating the order view in step S5 is as follows: based on the parent-child relationship between each order, a hierarchical structure between each order is constructed, and the order update results are further displayed in the order view in a tree structure.

6. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, After updating the order view in step S5, the method further includes: determining whether the client is in a closed state; if so, ending the display and update of the order view; otherwise, returning to step S4.

7. The method for displaying over-the-counter derivatives trading orders based on a two-level cache according to claim 1, characterized in that, The first-level cache is protected by a read-write lock mechanism; Specifically, in response to an order change push message, the update thread acquires a write lock to update the first-level cache; in response to a timed event, the order view refresh thread acquires a read lock to read the first-level cache.

8. A two-level caching-based OTC derivatives trading order display system, used to implement the two-level caching-based OTC derivatives trading order display method according to any one of claims 1-7, characterized in that, include: The order data management module is used to interact with the server, receive order change push messages, and manage cached data; The first-level cache module is used to store all order data and the parent-child relationship mapping between orders; The second-level cache module is used to build a corresponding second-level cache for each order view. The second-level cache includes the order view identifier, filter conditions, flag bits, and the set of order identifiers corresponding to each order view. The dynamic refresh scheduling module is used to calculate the refresh time interval based on the running status parameters, thereby triggering refresh events for each order view; The order view module is used to respond to refresh events, read the corresponding flag bit of the second-level cache, and when the flag bit is in the pending update state, obtain the corresponding order data and the parent-child relationship between each order from the first-level cache module, and update the order view.

Images