A financial product index calculation method and device and related product
By introducing a dual message queue architecture into the financial product analysis system, tasks are split into parent tasks and child tasks, which are then processed in parallel. This solves the problems of low computational efficiency and deadlock risk in existing technologies, and achieves efficient resource utilization and high-concurrency response.
Patent Information
- Application Number
- CN202610252434.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-03
- Publication Date
- 2026-06-23
AI Technical Summary
Existing financial product analysis systems suffer from low computational efficiency, task blocking and deadlock risks, and insufficient resource utilization when performing large-scale batch computation tasks. In particular, under a single message queue architecture, it is impossible to effectively distinguish between parent and child tasks, leading to an imbalance in resource allocation.
A dual message queue architecture is adopted, which encapsulates the financial product indicator calculation requests into parent tasks and child tasks, which are processed by different computing nodes. The first and second message queues are physically isolated to achieve parallel processing and resource optimization of parent and child tasks, avoiding the risk of deadlock.
It significantly improves the efficiency of calculating indicators for large batches of financial products and the utilization rate of system resources, ensuring high concurrency processing capabilities and the accuracy of calculation results.
Smart Images
Figure CN122264939A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and related products for calculating financial product indicators. Background Technology
[0002] In the field of financial product analysis, in-depth analysis of financial products is a core prerequisite for investors to make rational investment decisions. Multi-dimensional indicator systems constructed through financial engineering algorithms, such as yield, volatility, and Sharpe ratio, can accurately characterize the return characteristics and risk levels of financial products. Therefore, efficient calculation of financial product indicators has become one of the core customer service capabilities of financial institutions. In practical applications, users frequently need to perform batch indicator calculations on thousands or even tens of thousands of similar financial products and complete in-depth analyses such as sorting and horizontal comparisons based on the calculation results. Such requests involve a large amount of computation, placing higher demands on the system's concurrent processing capabilities and computational efficiency.
[0003] Currently, mainstream financial product analysis systems generally employ an asynchronous task scheduling scheme based on Celery (a distributed task queue framework) to handle batch computation requests. Its core implementation logic is as follows: user requests are encapsulated as tasks and passed to a single message queue. Worker processes (task worker processes) retrieve tasks from this queue through polling and execute them. The computation results are stored in backend storage, and finally, the requesting client retrieves the results and completes the response. However, this scheme has significant drawbacks when handling large-scale batch computation tasks for financial products: (1) Low computational efficiency: In the single message queue mode, a single interface request corresponds to a single task. In order to perform calculations on multiple products in a single interface, the calculation can only be performed in a single task, which seriously slows down the calculation speed. (2) Risk of task blocking and deadlock: If multi-product computing tasks are split into multiple sub-tasks and sent to the same queue again, the parent task and the sub-tasks will be stored together. Since the Worker process does not distinguish between task types, all Workers may be occupied by the parent task, which will cause the sub-tasks to be unable to be scheduled and executed, resulting in system deadlock; (3) Insufficient scalability and resource utilization: The single queue mode lacks dynamic resource allocation capability and cannot flexibly adjust the Worker resource allocation ratio according to the task type, resulting in unbalanced system resource configuration and low utilization.
[0004] Therefore, how to effectively avoid deadlock risks, improve computing efficiency, and optimize resource allocation in large-scale financial product indicator batch calculation scenarios has become an urgent technical problem to be solved. Summary of the Invention
[0005] In view of the above problems, this application is made to provide a method, apparatus, and related products for calculating financial product indicators that overcome or at least partially solve the above problems. The technical solution is as follows: Firstly, a method for calculating financial product indicators is provided, the method comprising: The system receives a financial product indicator calculation request initiated by a user, the request including a target product set and indicator calculation parameters; the target product set contains at least one financial product. If the target product set contains at least two financial products, the financial product indicator calculation request is encapsulated as a parent task and the parent task is sent to the first message queue. The first type of computing node obtains the parent task from the first message queue, parses the target product set, splits the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and sends the at least two sub-tasks to the second message queue. The second type of computing node obtains any subtask from the second message queue, performs index calculation on the financial product corresponding to the subtask based on the index calculation parameters, obtains the calculation result of the subtask, and stores the calculation result in the result storage layer. The first type of computing node monitors the result storage layer. When it is determined that the calculation results of all subtasks associated with the parent task have been stored, it performs a summary process on all the calculation results to obtain the summary result of the parent task, and stores the summary result in the result storage layer. The summary result is obtained from the result storage layer and returned to the user client that initiated the financial product indicator calculation request.
[0006] In one possible implementation, the method further includes: If the target product set contains only one financial product, the financial product indicator calculation request is directly encapsulated as a subtask and sent to the second message queue.
[0007] In one possible implementation, the first type of computing node retrieves the parent task from the first message queue, parses the target product set, and splits the parent task into at least two sub-tasks, including: Parse the parent task and read the target product set; For each financial product in the target product set, a corresponding subtask is generated. The subtask includes the financial product identifier and the indicator calculation parameters. Assign a subtask identifier to each subtask, and establish and store the mapping relationship between the parent task and the subtask identifier.
[0008] In one possible implementation, the second type of computing node retrieves any subtask from the second message queue, performs indicator calculations on the financial product corresponding to the subtask based on the indicator calculation parameters, and obtains the calculation result of the subtask, including: Parse the subtask to obtain the financial product identifier and the indicator calculation parameters contained in the subtask; Based on the financial product identifier, obtain the product data of the target financial product; Based on the indicator calculation parameters and the product data, a preset indicator calculation algorithm is invoked to obtain the calculation result.
[0009] In one possible implementation, the first type of computing node monitors the result storage layer. When it is determined that the computation results of all subtasks associated with the parent task have been stored, it performs a summary processing on all the computation results to obtain the summary result of the parent task, including: Based on the mapping relationship, determine the identifiers of all child tasks associated with the parent task; The corresponding calculation result is extracted from the result storage layer by polling according to the subtask identifier; When the calculation results of all subtasks associated with the parent task are extracted, an aggregation operation is performed on the extracted calculation results based on a preset aggregation rule to generate the aggregated result containing financial product indicator values and analysis conclusions.
[0010] In one possible implementation, the first message queue and the second message queue are physically isolated, the first type of computing node subscribes only to the first message queue, and the second type of computing node subscribes only to the second message queue.
[0011] Secondly, a financial product indicator calculation device is provided, the device comprising: The request receiving unit is used to receive a financial product indicator calculation request initiated by the user terminal. The financial product indicator calculation request includes a target product set and indicator calculation parameters. The target product set contains at least one financial product. The request encapsulation unit is used to encapsulate the financial product indicator calculation request into a parent task if the target product set contains at least two financial products, and send the parent task to the first message queue. The task splitting unit is used by the first type of computing node to obtain the parent task from the first message queue, parse the target product set, split the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and send the at least two sub-tasks to the second message queue. The parallel computing unit is used by the second type of computing node to obtain any subtask from the second message queue, perform indicator calculation on the financial product corresponding to the subtask based on the indicator calculation parameters, obtain the calculation result of the subtask, and store the calculation result in the result storage layer. The result aggregation unit is used by the first type of computing node to monitor the result storage layer. When it is determined that the calculation results of all subtasks associated with the parent task have been stored, the unit aggregates all the calculation results to obtain the aggregated result of the parent task and stores the aggregated result in the result storage layer. The result return unit is used to retrieve the summary result from the result storage layer and return the summary result to the user terminal that initiated the financial product indicator calculation request.
[0012] Thirdly, an electronic device is provided, comprising a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the financial product indicator calculation method described in any of the preceding claims.
[0013] Fourthly, a storage medium is provided that stores a computer program, wherein the computer program is configured to execute the financial product indicator calculation method described in any of the preceding claims when running.
[0014] Fifthly, a computer program product is provided, including a computer program configured to execute the financial product indicator calculation method described in any of the preceding claims when running.
[0015] Using the above technical solutions, the financial product indicator calculation method, apparatus, and related products provided in this application embodiment include: receiving a financial product indicator calculation request; if the request involves at least two financial products, encapsulating it into a parent task and sending it to a first message queue; a first type of computing node obtaining the parent task from the first message queue, splitting it into at least two sub-tasks and sending them to a second message queue; a second type of computing node obtaining the sub-tasks from the second message queue and performing indicator calculation based on indicator calculation parameters; the first type of computing node monitoring the result storage layer, and after storing the calculation results of all related sub-tasks, performing summary processing to obtain a summary result and storing it; and returning the summary result to the user terminal. This application embodiment achieves physical isolation and parallel processing of parent and sub-tasks through dual message queues, effectively avoiding task blocking and deadlock risks, and significantly improving the efficiency of large-scale financial product indicator calculation and system resource utilization. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.
[0017] Figure 1 A flowchart illustrating the financial product indicator calculation method provided in this application embodiment is shown; Figure 2 A flowchart illustrating the financial product indicator calculation method provided in a specific embodiment of this application is shown; Figure 3 A structural diagram of the financial product index calculation device provided in an embodiment of this application is shown; Figure 4 A structural diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation
[0018] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.
[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."
[0020] Through analysis, the inventors discovered that existing asynchronous task scheduling architectures based on a single message queue have inherent design flaws in financial product indicator calculation scenarios. User-initiated batch calculation requests naturally possess a task hierarchy: one batch request corresponds to one parent task, which can be further broken down into multiple subtasks for single-product calculations, and the completion of the parent task strongly depends on the execution results of all subtasks. However, under a single message queue architecture, parent and subtasks are stored indiscriminately in the same queue, the task scheduler cannot distinguish task types, and worker processes indiscriminately extract tasks using a first-in-first-out approach.
[0021] This architectural design leads to two core problems: First, once a parent task is retrieved by a Worker, that Worker enters a circular computation mode, unable to release resources to process other tasks, resulting in low computational efficiency. Second, if batch requests are split into subtasks and re-queued, due to the coexistence of parent and child tasks, all Workers may be occupied by the parent task for an extended period, preventing the subtasks from being scheduled and resulting in a deadlock. Furthermore, the single-queue architecture severs the dependencies and scheduling logic between tasks—although the system is aware of the parent-child dependencies in the business logic, it completely ignores these dependencies at the resource scheduling level, treating different types of tasks equally. This fundamentally leads to resource contention and deadlock risks.
[0022] Furthermore, the existing architecture's resource allocation mechanism is disconnected from task types. Parent tasks primarily handle decomposition logic, requiring little computation but potentially triggering frequently; child tasks handle specific metric calculations, requiring significant computation but capable of parallel processing. The two types of tasks have drastically different computational resource requirements, but the single-queue architecture cannot specifically configure worker resources, resulting in limited system scalability and unbalanced resource utilization.
[0023] Therefore, the core issue is: how to achieve storage isolation and scheduling separation between parent and child tasks at the task scheduling architecture level, so that the system can identify task types and perform differentiated scheduling accordingly, while supporting independent resource configuration for different types of tasks, thereby fundamentally avoiding deadlock risks, improving computing efficiency and optimizing resource utilization. This points to the direction of technological breakthroughs for subsequent solutions.
[0024] To address the aforementioned technical problems, embodiments of this application provide a method for calculating financial product indicators, such as... Figure 1 As shown, the calculation method for this financial product indicator may include the following steps S101 to S106: Step S101: Receive a financial product indicator calculation request initiated by the user terminal. The financial product indicator calculation request includes a target product set and indicator calculation parameters; the target product set contains at least one financial product.
[0025] In one possible implementation, the aforementioned financial product indicator calculation request can be a Hypertext Transfer Protocol request initiated by a user when accessing the financial product analysis system through a browser.
[0026] In one possible implementation, the aforementioned target product set is used to indicate the financial products for which indicator calculation is required. It may include the identifier of a single financial product or a list of identifiers of multiple financial products. The aforementioned indicator calculation parameters are used to define the specific content and method of the calculation, and may include indicator type, calculation time range, calculation method, etc.
[0027] In one possible implementation, upon receiving the request, the request is first parsed and verified, for example, by checking whether the financial products in the target product set exist and whether the indicator calculation parameters are valid.
[0028] In one example, a user accesses a fund analysis page through a browser, selects 10 funds under the "CSI 300 Index Funds" category, chooses to calculate "one-year return" and "Sharpe ratio," sets the calculation method to "return values and sort," and then clicks the "Start Calculation" button. At this point, the user's client generates a financial product indicator calculation request containing the identifiers of these 10 funds, with the indicator types being "return" and "Sharpe ratio," the time range being "one year," and the calculation method being "value + sort," and sends it to the server. The server receives the request and prepares for subsequent processing.
[0029] Step S102: If the target product set contains at least two financial products, encapsulate the financial product indicator calculation request into a parent task and send the parent task to the first message queue.
[0030] In one possible implementation, the aforementioned parent task can be understood as a task unit obtained by encapsulating batch computation requests.
[0031] In one example, suppose a user-initiated request to calculate a financial product indicator targets three funds: "Product A", "Product B", and "Product C". The indicator calculation parameter is "calculate the return over the past year". Therefore, the request is encapsulated into a parent task. This parent task contains information such as the parent task identifier "task_001", the product set list ["Product A", "Product B", "Product C"], the indicator type "return", and the calculation time range "past year". Then, the parent task is sent to the first message queue to wait for processing.
[0032] In step S103, the first type of computing node obtains the parent task from the first message queue, parses the target product set, splits the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and sends the at least two sub-tasks to the second message queue.
[0033] In one possible implementation, the first type of computing node retrieves the parent task from the first message queue as follows: the first type of computing node listens to the first message queue in real time, and when it detects that there is a parent task to be processed in the first message queue, it retrieves the parent task through a blocking pop operation or a polling method using Redis (a memory data storage system). The data structure of the parent task includes at least a task identifier, a set of target products, and indicator calculation parameters.
[0034] In one possible implementation, when the first type of computing node sends at least two generated subtasks to the second message queue, it can use a batch sending method to improve efficiency. For example, the list containing at least two subtasks can be serialized into a single message and pushed into the second message queue all at once, or they can be sent one by one.
[0035] In step S104, the second type of computing node obtains any subtask from the second message queue, performs index calculation on the financial product corresponding to the subtask based on the index calculation parameters, obtains the calculation result of the subtask, and stores the calculation result in the result storage layer.
[0036] In one possible implementation, the second type of computing node listens to the second message queue in real time. When a subtask is detected to arrive, it extracts a subtask from the head of the queue for consumption. The specific format of the subtask can be a JSON (a data structure) string or a serialized object, which at least includes fields such as task identifier, product identifier, and computing parameters.
[0037] Step S105: First type of computing node monitoring result storage layer: When it is determined that the computing results of all subtasks associated with the parent task have been stored, all computing results are summarized to obtain the summary result of the parent task, and the summary result is stored in the result storage layer.
[0038] Step S106: Obtain the summary result from the result storage layer and return the summary result to the user terminal that initiated the financial product indicator calculation request.
[0039] In one possible implementation, after the result storage layer has finished storing the summary results of the parent task, it actively sends a notification message to the user interaction layer. After receiving the notification message, the user interaction layer retrieves the summary results of the parent task from the result storage layer.
[0040] In another possible implementation, the obtained summary results of the parent task are formatted according to the return format specified by the user when initiating the financial product indicator calculation request, and formatted result data is generated.
[0041] In one possible implementation, the return format includes at least one of a chart-based display format, a JSON data format, or a text format.
[0042] In one example, a user initiates a Sharpe ratio calculation request for 100 fund products through a browser, specifying that the returned format is a chart-based analysis report. After the system completes the calculation, the user interaction layer retrieves the parent task summary result, which contains the Sharpe ratio values and sorting results of the 100 funds, from the result storage layer. It then generates a line chart and a sorted table in a chart-based format and returns the generated chart-based analysis report to the user's browser for rendering and display.
[0043] This embodiment receives a request to calculate financial product indicators. If the request involves at least two financial products, it is encapsulated as a parent task and sent to the first message queue. A first type of computing node retrieves the parent task from the first message queue, splits it into at least two sub-tasks, and sends them to the second message queue. A second type of computing node retrieves the sub-tasks from the second message queue and performs indicator calculations based on the indicator calculation parameters. The first type of computing node monitors the result storage layer; after storing the calculation results of all related sub-tasks, it performs summary processing to obtain a summary result and stores it. The summary result is then returned to the user. There can be multiple first and second type computing nodes, for example, each with hundreds of nodes; this embodiment does not impose such limitations. This embodiment achieves physical isolation and parallel processing of parent and sub-tasks through dual message queues, effectively avoiding task blocking and deadlock risks, and significantly improving the efficiency of large-scale financial product indicator calculations and system resource utilization.
[0044] This application provides a possible implementation method for calculating the above-mentioned financial product indicators, which may specifically include the following step A1: Step A1: If the target product set contains only one financial product, the financial product indicator calculation request is directly encapsulated as a subtask and the subtask is sent to the second message queue.
[0045] This embodiment analyzes the target product set in the financial product indicator calculation request and dynamically selects the task encapsulation type based on the number of products. This differentiated processing mechanism enables the system to clearly separate single-point calculation from batch calculation, providing an accurate task classification basis for subsequent dual-queue parallel scheduling. It effectively avoids the risk of resource contention and deadlock caused by mixed tasks in a single queue, while ensuring that large-scale batch calculation tasks can be reasonably divided into independent sub-tasks for parallel execution, significantly improving the utilization rate of computing resources and overall processing efficiency.
[0046] This application embodiment provides a possible implementation method. In step S103 above, the first type of computing node obtains the parent task from the first message queue, parses the target product set, and splits the parent task into at least two sub-tasks. Specifically, it may include the following steps B1 to B3: Step B1: Parse the parent task and read the target product set; Step B2: For each financial product in the target product set, generate a corresponding subtask. The subtask includes the financial product identifier and indicator calculation parameters. Step B3: Assign a subtask identifier to each subtask, and establish and store the mapping relationship between the parent task and the subtask identifier.
[0047] This embodiment decomposes the originally serially processed batch computing tasks into a large number of independent subtasks that can be executed in parallel by task splitting. At the same time, it utilizes the physical isolation feature of dual queues to ensure that the parent task and the subtasks are processed by different types of computing nodes, avoiding the deadlock risk that may be caused by task mixing in the single queue mode. This greatly improves the concurrent processing capability and system resource utilization efficiency, and provides a reliable technical guarantee for the real-time analysis of massive product data.
[0048] This application embodiment provides a possible implementation method. In step S104 above, the second type of computing node obtains any subtask from the second message queue, performs indicator calculation on the financial product corresponding to the subtask based on the indicator calculation parameters, and obtains the calculation result of the subtask. Specifically, it may include the following steps C1 to C3: Step C1: Parse the subtask to obtain the financial product identifier and indicator calculation parameters contained in the subtask; Step C2: Obtain product data for the target financial product based on the financial product identifier; Step C3: Based on the indicator calculation parameters and product data, call the preset indicator calculation algorithm to obtain the calculation result.
[0049] This embodiment accurately locates the target product and obtains its underlying product data by parsing the financial product identifier and indicator calculation parameters in the subtasks. Then, it calculates the indicator value according to a preset indicator calculation algorithm. This preset algorithm can be understood as a mathematical function model used in financial engineering to measure the return and risk characteristics of a product. For example, a return rate algorithm reflects profitability by calculating the percentage increase in net asset value over a specified time interval, a volatility algorithm measures price volatility risk by statistically analyzing the standard deviation of historical returns, and a Sharpe ratio algorithm assesses risk-adjusted returns by dividing excess returns by volatility. This embodiment does not impose any limitations on this approach. By refining the calculation task to the single-product dimension and using independent subtasks for parallel processing, this embodiment can fully utilize distributed computing resources, significantly improving the calculation efficiency of large-scale financial product indicators. Simultaneously, based on a standardized calculation process, it ensures the consistency and accuracy of the indicator calculation results, providing a reliable data foundation for subsequent aggregation processing and effectively supporting the high-concurrency response requirements of financial product indicator analysis scenarios.
[0050] This application embodiment provides a possible implementation method. In step S105 above, the first type of computing node monitoring result storage layer, when it is determined that the computing results of all sub-tasks associated with the parent task have been stored, performs summary processing on all computing results to obtain the summary result of the parent task. Specifically, it may include the following steps D1 to D3: Step D1: Based on the mapping relationship, determine the identifiers of all child tasks associated with the parent task; Step D2: Extract the corresponding calculation results from the result storage layer based on the subtask identifier using a polling method. Step D3: When the calculation results of all subtasks associated with the parent task have been extracted, perform aggregation operations on the extracted calculation results based on preset aggregation rules to generate a summary result containing financial product indicator values and analysis conclusions.
[0051] In this embodiment, the preset aggregation rules can be understood as statistical analysis methods determined based on parameters in the user's request. For example, these methods might calculate the ranking order, arithmetic mean, weighted average, or extreme values of multiple financial product indicator values to generate comparative conclusions or statistical indicators that meet the user's analytical needs. Through this aggregation processing mechanism, this embodiment can integrate the scattered calculation results of individual product indicators into batch analysis results with decision-making reference value, ensuring that the calculation results accurately match the user's needs.
[0052] This application provides a possible implementation method in which the first message queue and the second message queue are physically isolated, the first type of computing node subscribes only to the first message queue, and the second type of computing node subscribes only to the second message queue.
[0053] The above introduces Figure 1 The embodiments shown have various implementation methods for each step. The following will further explain the financial product indicator calculation method of this application embodiment through specific embodiments.
[0054] like Figure 2 As shown, this specific embodiment uses the interval yield calculation function of 100 financial products as a background to demonstrate how to use a dual message queue architecture to split the batch calculation task into sub-tasks for parallel processing, so as to solve the problem of low efficiency of traditional single-process loop calculation.
[0055] I. Operating Environment Configuration 1. Python software environment Programming language: Python 3.8; Task scheduling framework: Celery 5.3.0b2; Message middleware and caching: Redis 4.5.4; Numerical computation library: NumPy 1.24.4; 2. Hardware Configuration Server architecture: X86_64; Operating system: Kylin V10; Central Processing Unit: 16 cores, clock speed 2.6GHz; Memory: 64GB; 3. Queue architecture deployment User interaction layer: used to receive user requests and render summary results; The task processing layer contains two message queues for calculating and processing financial product indicators. First message queue (parent queue): Dedicated to storing parent tasks, and subscribed to only by first-class compute nodes (DispatcherWorker); Second message queue (sub-queue): Dedicated to storing subtasks, and subscribed to only by multiple second-class compute nodes (Calculator Workers); Results storage layer: Based on the Redis Hash structure, it is used to store the calculation results of subtasks and the summary results of parent tasks.
[0056] II. Specific Implementation Process 1. Receive and encapsulate user requests The user initiates a request to calculate financial product metrics, with the following parameters: (1) Target product set: includes 100 financial products; (2) Calculation parameters of the indicator: calculate the interval rate of return, with time ranges of one year, two years, three years, four years and five years respectively; (3) Calculation method: Return the yield values of each product and the overall summary results; After parsing the request, the system determines that the target product set contains 100 financial products, and therefore generates a parent task with the task identifier parent_task_001, which contains a list of target product sets and indicator calculation parameters; the parent task is then sent to the first message queue.
[0057] 2. Parent task splitting and child task distribution The first type of compute node subscribes to the first message queue, obtains the parent task parent_task_001, and then executes the splitting logic: Parse the parent task and read the target product set; for each financial product in the set, generate a corresponding subtask, which includes the financial product identifier and interval yield calculation parameters; assign a unique subtask identifier to each subtask (e.g., child_task_001 to child_task_100), establish and store the mapping relationship between the parent task identifier and the subtask identifier; send 100 subtasks in batch to the second message queue.
[0058] 3. Parallel computation of subtasks The second type of computing node subscribes to the second message queue, and after obtaining any subtask, executes the metric calculation: Parse the subtask to obtain the financial product identifier and interval yield calculation parameters; based on the financial product identifier, retrieve the market data of the product within the corresponding time range from the product database; call the preset interval yield calculation algorithm to obtain the calculation result of the product; store the subtask calculation result in the result storage layer, with the result stored using the subtask identifier as the key.
[0059] 4. Summary of parent task results The first type of computing nodes, based on the mapping relationship, determine all subtask identifiers associated with the parent task parent_task_001, and retrieve the corresponding computing results from the result storage layer through a round-robin method: After the calculation results of all 100 sub-tasks have been extracted, the results are aggregated based on preset aggregation rules (such as calculating the average rate of return, sorting, etc.); the parent task summary result containing the rate of return of each product and the analysis conclusions is generated and stored in the result storage layer.
[0060] 5. Results returned The user interaction layer monitors the result storage layer in real time. When it detects that the summary result of the parent task parent_task_001 has been generated, it returns the result to the user client that initiated the request in the format specified by the user, thus completing the entire calculation process.
[0061] III. Performance Comparison Experiment Under the above operating environment, the performance of the dual message queue architecture calculation method and the traditional single-process loop calculation method were compared. The running time and performance improvement percentage of the two methods under different yield calculation intervals were statistically analyzed. The results are shown in Table 1.
[0062] Table 1 - Experimental Results Data
[0063] This specific embodiment successfully achieves efficient parallel computation of large-scale financial product indicators by dividing tasks through physically isolated first and second message queues and dedicated computing nodes, thus solving the problems of low computational efficiency and task blocking risks in existing technologies.
[0064] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.
[0065] Based on the financial product indicator calculation methods provided in the above embodiments, and based on the same inventive concept, this application also provides a financial product indicator calculation device.
[0066] Figure 3 This is a structural diagram of the financial product indicator calculation device provided in the embodiments of this application. Figure 3 As shown, the financial product indicator calculation device may specifically include a request receiving unit 210, a request encapsulation unit 220, a task splitting unit 230, a parallel computing unit 240, a result summarization unit 250, and a result return unit 260.
[0067] The request receiving unit 210 is used to receive a financial product indicator calculation request initiated by the user terminal. The financial product indicator calculation request includes a target product set and indicator calculation parameters; the target product set contains at least one financial product. The request encapsulation unit 220 is used to encapsulate the financial product indicator calculation request into a parent task if the target product set contains at least two financial products, and send the parent task to the first message queue. The task splitting unit 230 is used by the first type of computing node to obtain the parent task from the first message queue, parse the target product set, split the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and send the at least two sub-tasks to the second message queue. Parallel computing unit 240 is used for the second type of computing node to obtain any subtask from the second message queue, perform indicator calculation on the financial product corresponding to the subtask based on the indicator calculation parameters, obtain the calculation result of the subtask, and store the calculation result in the result storage layer. The result aggregation unit 250 is used for the first type of computing node monitoring result storage layer. When it is determined that the calculation results of all sub-tasks associated with the parent task have been stored, the calculation results are aggregated to obtain the aggregated result of the parent task, and the aggregated result is stored in the result storage layer. Result return unit 260 is used to retrieve the summary result from the result storage layer and return the summary result to the user terminal that initiated the financial product indicator calculation request.
[0068] This application embodiment provides a possible implementation, wherein the request encapsulation unit 220 is further configured to: If the target product set contains only one financial product, the financial product indicator calculation request is directly encapsulated as a subtask and sent to the second message queue.
[0069] This application embodiment provides a possible implementation, wherein the task splitting unit 230 is further configured to: Analyze the parent task and read the target product set; For each financial product in the target product set, a corresponding subtask is generated. The subtask includes the financial product identifier and indicator calculation parameters. Assign a subtask identifier to each subtask, and establish and store the mapping relationship between the parent task and the subtask identifier.
[0070] This application embodiment provides a possible implementation, wherein the parallel computing unit 240 is further configured to: Parse the subtasks to obtain the financial product identifiers and indicator calculation parameters contained in the subtasks; Obtain product data for the target financial product based on the financial product identifier; Based on the indicator calculation parameters and product data, the preset indicator calculation algorithm is invoked to obtain the calculation results.
[0071] This application embodiment provides a possible implementation, wherein the result summarization unit 250 is further configured to: Based on the mapping relationship, determine the identifiers of all child tasks associated with the parent task; By polling, the corresponding calculation results are extracted from the result storage layer based on the subtask identifier; When the calculation results of all subtasks associated with the parent task are extracted, an aggregation operation is performed on the extracted calculation results based on the preset aggregation rules to generate a summary result containing financial product indicator values and analysis conclusions.
[0072] Based on the same inventive concept, this application also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the financial product indicator calculation method of any of the above embodiments.
[0073] In an exemplary embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4 The illustrated electronic device 300 includes a processor 301 and a memory 303. The processor 301 and the memory 303 are connected, for example, via a bus 302. Optionally, the electronic device 300 may also include a transceiver 304. It should be noted that in practical applications, the transceiver 304 is not limited to one type, and the structure of this electronic device 300 does not constitute a limitation on the embodiments of this application.
[0074] Processor 301 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 301 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.
[0075] Bus 302 may include a pathway for transmitting information between the aforementioned components. Bus 302 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 302 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 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.
[0076] The memory 303 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.
[0077] The memory 303 stores computer program code that executes the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the computer program code stored in the memory 303 to implement the content shown in the foregoing method embodiments.
[0078] Among them, electronic devices include, but are not limited to: mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0079] Based on the same inventive concept, this application also provides a storage medium storing a computer program, wherein the computer program is configured to execute the financial product indicator calculation method of any of the above embodiments when running.
[0080] Based on the same inventive concept, this application also provides a computer program product, including a computer program configured to execute the financial product indicator calculation method of any of the above embodiments when running.
[0081] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.
[0082] Those skilled in the art will understand that the technical solution of this application, or all or part of it, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0083] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.
[0084] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.
Claims
1. A method for calculating financial product indicators, characterized in that, The method includes: The system receives a financial product indicator calculation request initiated by a user, the request including a target product set and indicator calculation parameters; the target product set contains at least one financial product. If the target product set contains at least two financial products, the financial product indicator calculation request is encapsulated as a parent task, and the parent task is sent to the first message queue. The first type of computing node obtains the parent task from the first message queue, parses the target product set, splits the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and sends the at least two sub-tasks to the second message queue. The second type of computing node obtains any subtask from the second message queue, performs index calculation on the financial product corresponding to the subtask based on the index calculation parameters, obtains the calculation result of the subtask, and stores the calculation result in the result storage layer. The first type of computing node monitors the result storage layer. When it is determined that the calculation results of all subtasks associated with the parent task have been stored, it performs a summary process on all the calculation results to obtain the summary result of the parent task, and stores the summary result in the result storage layer. The summary result is obtained from the result storage layer and returned to the user terminal that initiated the financial product indicator calculation request.
2. The method according to claim 1, characterized in that, The method further includes: If the target product set contains only one financial product, the financial product indicator calculation request is directly encapsulated as a subtask and sent to the second message queue.
3. The method according to claim 2, characterized in that, The first type of computing node retrieves the parent task from the first message queue, parses the target product set, and splits the parent task into at least two sub-tasks, including: Parse the parent task and read the target product set; For each financial product in the target product set, a corresponding subtask is generated. The subtask includes the financial product identifier and the indicator calculation parameters. Assign a subtask identifier to each subtask, and establish and store the mapping relationship between the parent task and the subtask identifier.
4. The method according to claim 3, characterized in that, The second type of computing node retrieves any subtask from the second message queue, performs indicator calculations on the financial product corresponding to the subtask based on the indicator calculation parameters, and obtains the calculation result of the subtask, including: Parse the subtask to obtain the financial product identifier and the indicator calculation parameters contained in the subtask; Based on the financial product identifier, obtain the product data of the target financial product; Based on the indicator calculation parameters and the product data, a preset indicator calculation algorithm is invoked to obtain the calculation result.
5. The method according to claim 3, characterized in that, The first type of computing node monitors the result storage layer. When it determines that the computation results of all subtasks associated with the parent task have been stored, it performs a summary process on all the computation results to obtain the summary result of the parent task, including: Based on the mapping relationship, determine the identifiers of all child tasks associated with the parent task; The corresponding calculation result is extracted from the result storage layer by polling according to the subtask identifier; When the calculation results of all subtasks associated with the parent task are extracted, an aggregation operation is performed on the extracted calculation results based on a preset aggregation rule to generate the aggregated result containing financial product indicator values and analysis conclusions.
6. The method according to claim 1, characterized in that, The first message queue and the second message queue are physically isolated. The first type of computing node subscribes only to the first message queue, and the second type of computing node subscribes only to the second message queue.
7. A financial product indicator calculation device, characterized in that, The device includes: The request receiving unit is used to receive a financial product indicator calculation request initiated by the user terminal. The financial product indicator calculation request includes a target product set and indicator calculation parameters. The target product set contains at least one financial product. The request encapsulation unit is used to encapsulate the financial product indicator calculation request into a parent task if the target product set contains at least two financial products, and send the parent task to the first message queue. The task splitting unit is used by the first type of computing node to obtain the parent task from the first message queue, parse the target product set, split the parent task into at least two sub-tasks, each sub-task corresponding to a financial product in the target product set, and send the at least two sub-tasks to the second message queue. The parallel computing unit is used by the second type of computing node to obtain any subtask from the second message queue, perform indicator calculation on the financial product corresponding to the subtask based on the indicator calculation parameters, obtain the calculation result of the subtask, and store the calculation result in the result storage layer. The result aggregation unit is used by the first type of computing node to monitor the result storage layer. When it is determined that the calculation results of all subtasks associated with the parent task have been stored, the unit aggregates all the calculation results to obtain the aggregated result of the parent task and stores the aggregated result in the result storage layer. The result return unit is used to retrieve the summary result from the result storage layer and return the summary result to the user terminal that initiated the financial product indicator calculation request.
8. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the financial product indicator calculation method according to any one of claims 1 to 6.
9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the financial product indicator calculation method according to any one of claims 1 to 6 when it runs.
10. A computer program product, comprising a computer program, characterized in that, The computer program is configured to execute the financial product indicator calculation method according to any one of claims 1 to 6 at runtime.