An event-driven and multi-layer parallel architecture-based revenue processing method and system

Abstract

The present disclosure provides a kind of income processing method and system based on event-driven and multilayer parallel architecture, the method comprises: receiving and processing multi-source trigger signal, generates the standardized trigger context of income calculation task;According to the standardized trigger context, the income calculation task is split into multiple independent subtasks, encapsulated as a standardized income event message and published;Subscription and processing standardized income event message, split each independent subtask into atomic subtask, execute distributed income calculation, generate customer income raw results;Customer income raw results are converged and persisted to unified income accounting table.The present disclosure effectively solves the bottleneck of traditional system in performance and expansibility through event-driven and parallel computing architecture, and further through the innovative initiative audit repair mechanism, builds endogenous, automated data quality guarantee system, realizes the overall upgrade of reliability, accuracy and operation efficiency of income processing system.

Description

Technical Field

[0001] This disclosure relates to the fields of financial information technology and distributed computing technology, and in particular to a revenue processing method and system based on event-driven and multi-layer parallel architecture. Background Technology

[0002] In wealth management businesses such as wealth management, funds, and trusts offered by banks, fund companies, and fintech platforms, profit calculation and accounting are crucial back-end processing procedures. Current technologies generally employ centralized or serialized batch processing architectures. A typical process is as follows: at the end of the day or a fixed settlement point, the system sequentially completes pre-processing steps such as updating product net asset value, processing all transaction records, and registering customer shares. Then, a unified profit calculation program is initiated, performing accounting based on the outputs of the aforementioned steps and recording the final result in various profit and accounting statements.

[0003] This traditional architecture has gradually revealed the following technical shortcomings when dealing with increasing business volume, product variety, and real-time requirements: 1. High system coupling and rigid resource allocation: The profit calculation logic is deeply embedded in the main clearing process and is highly coupled with modules such as net asset value acquisition, transaction processing, and share registration. Delay in any upstream module will block the overall profit calculation task, forming a system bottleneck, and profit calculation resources cannot be expanded independently.

[0004] 2. Sequential processing leads to extended processing time: Strictly sequential batch processing is required, and the overall processing time equals the sum of the processing times of each step. When dealing with a large number of customers and complex products, the computation window is under heavy pressure, resulting in delayed output and making it difficult to support time-sensitive tasks such as real-time revenue display and dynamic asset analysis.

[0005] 3. Poor scalability and maintainability: When adding new revenue calculation dimensions or integrating new financial products, the core main process needs to be modified and redeployed, resulting in long iteration cycles, complex testing, and the risk of affecting existing business.

[0006] 4. Passive and Lagging Data Quality Assurance: The existing system relies on the accuracy of data at each stage, lacking proactive verification mechanisms across data sources and stages. Auditing methods are mostly post-event offline batch comparisons, which have the following shortcomings: 1) Problems are not detected in a timely manner: Data anomalies are often not discovered until several hours or even a day later; 2) Low efficiency in error localization: It can only detect inconsistencies in results, but it is difficult to quickly locate the source of the problem (transaction flow, net value, share, or calculation logic). 3) The repair process is complex: it requires manual coordination of multiple systems to correct data and re-trigger global or local calculations, which is cumbersome and prone to errors.

[0007] In other areas of fintech, while some solutions (such as CN120975894A) employ distributed acquisition and streaming processing technologies to achieve cross-platform data integration and analysis, these are primarily applied to scenarios such as market analysis and trading signal generation. They fail to address the efficiency, scalability, and data accuracy challenges arising from the tightly coupled, serialized architecture in profit calculation. Especially in high-concurrency distributed environments, ensuring strong consistency and idempotency of profit data, and building a proactive auditing and remediation loop, remains a technological gap.

[0008] Therefore, there is an urgent need in this field for a new revenue processing system and method to address the inherent limitations in coupling, timeliness, and scalability, and to fundamentally change the data quality assurance model that relies on ex-post auditing. Summary of the Invention

[0009] The overall purpose of this disclosure is: This paper presents a revenue processing method and system based on event-driven and multi-layered parallel architecture to address the technical shortcomings of traditional revenue processing architectures, such as high system coupling, prolonged sequential processing time, poor scalability, and passive lag in data quality assurance. By combining event-driven mechanisms, parallel computing, and proactive auditing and remediation, the revenue processing workflow is decoupled, made more efficient, and elastically scalable. An inherent, automated data quality assurance closed loop is also constructed, thereby comprehensively improving the real-time performance, accuracy, and system reliability of revenue processing.

[0010] Therefore, the first aspect of this disclosure provides a method for processing revenue based on an event-driven and multi-layered parallel architecture, which includes the following steps: S1 receives and processes multi-source trigger signals to generate a standardized trigger context for the revenue calculation task; S2, based on the standardized trigger context, splits the revenue calculation task into multiple independent subtasks, encapsulates them into standardized revenue event messages, and publishes them; S3 subscribes to and processes standardized revenue event messages, breaks down each independent subtask into atomic subtasks, performs distributed revenue calculations, and generates the raw revenue results for customers. S4 aggregates and persists the raw results of customer revenue into a unified revenue statement.

[0011] In some embodiments, step S1 specifically includes: S11 receives internal business event signals from internal business monitoring and timed scheduling signals from external scheduling platforms, and performs parsing and standardization conversion to generate internal signal objects; S12, Based on a preset triggering strategy rule base, perform strategy matching on the internal signal object to determine the calculation dimension list; S13, based on the internal signal object, assess the target scope of the triggering impact, where the target scope is the range of customers and products affected by the triggering impact; S14: Construct a standardized triggering context containing a list of target topics, target scope, and calculation dimensions, and deliver it to the event publishing and processing stage.

[0012] In some embodiments, step S2 specifically includes: S21, based on the list of calculation dimensions in the standardized trigger context, the revenue calculation task is split into multiple independent subtasks divided by calculation dimensions, and encapsulated into a standardized revenue event message, wherein the standardized revenue event message includes the target topic, target scope, calculation dimension, and calculation date; S22, route the revenue event message to the corresponding target topic for asynchronous delivery, and persist the event metadata.

[0013] In some embodiments, step S3 specifically includes: S31, Subscribe to and process standardized revenue event messages; S32, for different independent subtasks, each independent subtask is divided into atomic subtasks with customer-product granularity according to the target range in the revenue event message, and the subtasks are sharded and scheduled for parallel execution. S33, Based on the parallel loading of the required data by the atomic subtasks, the loaded data includes customer holding share data, product net value market data, customer transaction flow data and historical return data; S34, based on the loaded data, calls the revenue calculation model corresponding to the current calculation dimension, calculates various revenue indicators in turn, and generates the original customer revenue results.

[0014] In some embodiments, the standardized benefit event message encapsulated in step S2 further includes an event-level idempotent identifier, which is synthesized based on the target topic, target scope, and computational dimension; step S3, before being split into atomic subtasks, further includes: S32a: Based on the event-level idempotency identifier in the revenue event message, query the event processing record table to perform event-level idempotency verification. Only after the verification passes will the process proceed to S32.

[0015] In some embodiments, the raw customer revenue result generated in step S3 includes a customer-level idempotent identifier, which is synthesized based on the target topic, product code, customer number, calculation dimension, and revenue type; before step S4, the following is also included: S4a performs a customer-level idempotency check on the original customer revenue results, and only proceeds to S4 after the check passes.

[0016] In some embodiments, step S4 is followed by: S5, based on the original business data, performs proactive consistency auditing, anomaly location and automatic repair on the persistent final state results of customer revenue, and triggers targeted recalculation to form a quality assurance closed loop.

[0017] The second aspect of this disclosure provides a revenue processing system based on an event-driven and multi-layered parallel architecture, used to implement the aforementioned revenue processing method based on an event-driven and multi-layered parallel architecture, comprising: The revenue triggering module is used to receive and process multi-source triggering signals and generate a standardized triggering context for the revenue calculation task. The revenue event publishing module is used to split the revenue calculation task into multiple independent subtasks based on the standardized trigger context, encapsulate them into standardized revenue event messages, and publish them. The message middleware is used to connect to the revenue event publishing module, receive and distribute revenue event messages; The parallel computing processing module is used to subscribe to and process standardized revenue event messages, break down each independent subtask into atomic subtasks, perform distributed revenue calculations, and generate the raw revenue results for customers. The Results Aggregation and Accounting module is used to aggregate and persist the original customer revenue results to a unified revenue accounting table.

[0018] A third aspect of this disclosure provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method when executing the program.

[0019] The fourth aspect of this disclosure provides a computer-readable storage medium having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method of the claim.

[0020] The beneficial effects of this disclosure are as follows: 1. System Decoupling and Independent Scaling: Through event publishing and message subscription mechanisms, the system achieves complete decoupling of revenue calculation triggering, event production, and multi-dimensional calculation logic. Each calculation module (such as customer share and revenue stream dimensions) can be deployed independently and scaled horizontally. Adding new business types only requires deploying new subscription units, improving system agility and maintainability.

[0021] 2. Significantly improved processing efficiency: Adopting a dynamic computing topology of "one-time release, multi-path parallelism", a single business event can trigger parallel computing in multiple dimensions at the same time, changing sequential waiting to parallel processing, greatly shortening the time from data readiness to result storage, and meeting the needs of high-timeliness business.

[0022] 3. Strong data consistency guarantee: Through a two-layer idempotent control mechanism (event-level and client-level idempotent keys) that runs through event publishing, parallel computing and result aggregation, it ensures that the business calculation results are unique and correct in distributed scenarios such as message duplication and node failure, eliminating the risk of duplication or disorder.

[0023] 4. Proactive Auditing and Closed-Loop Repair: The built-in audit and repair module transforms traditional post-event auditing into proactive online verification. Based on forward deduction and cross-validation of raw data, it intelligently locates the root cause of anomalies and automatically executes repair strategies, forming an automated closed loop of "verification-location-repair-recalculation," significantly improving data accuracy and system autonomy.

[0024] 5. Flexible business orchestration capabilities: The revenue triggering module serves as a unified entry point, supporting timed scheduling and unified reception of multi-source business events, strategy matching, and task orchestration. It flexibly adapts to various scenarios such as end-of-day batch processing and real-time triggering, enhancing process adaptability and manageability.

[0025] In summary, this disclosure not only effectively solves the performance and scalability bottlenecks of traditional systems through event-driven and parallel computing architecture, but also builds an intrinsic and automated data quality assurance system through an innovative proactive audit and repair mechanism, achieving a comprehensive upgrade of the revenue processing system in terms of reliability, accuracy, and operational efficiency. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0027] Figure 1 A flowchart illustrating a revenue processing method based on an event-driven and multi-layered parallel architecture, provided for embodiments of this disclosure; Figure 2 A flowchart illustrating a revenue processing method based on an event-driven and multi-layered parallel architecture, provided in an embodiment of this disclosure; Figure 3 This is an architecture diagram of a revenue processing system based on an event-driven and multi-layered parallel architecture, provided for embodiments of this disclosure.

[0028] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0029] The present disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, not all of them. All other embodiments obtained by those skilled in the art based on the described embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains.

[0030] This disclosure describes a revenue processing method and system based on event-driven and multi-layer parallel architecture. It parallelizes multi-dimensional revenue calculation tasks through an event-driven mechanism and introduces proactive auditing and self-repair mechanisms to achieve efficient, accurate, and scalable customer revenue processing.

[0031] Example 1

[0032] This embodiment provides a revenue processing method based on event-driven and multi-layered parallel architecture, such as... Figure 1-2 As shown, it includes the following steps: S1 receives and processes multi-source trigger signals to generate a standardized trigger context for the revenue calculation task.

[0033] This step serves as the unified decision-making and scheduling entry point for the entire revenue processing workflow. Its core function is to transform discrete and heterogeneous business status change signals into standardized, executable revenue calculation trigger instructions with complete traceability information. This includes: S11 receives internal business event signals from internal business monitoring and timed scheduling signals from external scheduling platforms, and performs parsing and standardization conversion to generate internal signal objects; The system receives raw signals from two types of signal sources in parallel via a highly available service interface or message listener, and temporarily stores them in an internal buffer queue for sequential processing, ensuring that signals are not lost and remain in order under high concurrency scenarios. The raw signals include: 1. Internal Business Event Signals: These originate from the system's embedded data readiness monitor. This monitor listens for changes in the core business database (such as incremental records in the transaction log and net value update status bits in the product market data table), capturing and pushing business processing completion events in real time. The signal body is in JSON format, and the meanings of the core fields are as follows: Signal Type: Fixed to "EVENT", indicating that this is an event generated by a business action.

[0034] Internal business event code (eventCode): Uniquely identifies the specific type of business action. For example, NAV_CONFIRMED indicates that the net asset value per unit of the product has been confirmed and updated; USERSHARE_COMPLETED indicates that changes in customer holdings (subscription, redemption, etc.) have been completed; USERTRANS_COMPLETED indicates that core transaction flows affecting returns (such as dividends) have been generated.

[0035] Asset Type: Major asset classes, such as "FUND" (funds) and "FINANCE" (financial management).

[0036] Product Code: A unique identifier for a financial product.

[0037] Client No.: Uniquely identifies a client. It may be empty in certain events, such as when the product's net asset value is updated.

[0038] Business Date (bizDate): The date the business occurred, in the format "YYYY-MM-DD".

[0039] Batch number (batchId): Identifies a specific batch processing operation.

[0040] Occurrence Time: The specific timestamp of when the event occurred.

[0041] Source System: Refers to the name of the business system that generated this event, used for end-to-end tracing.

[0042] Trace ID (traceId): A full-link tracing identifier used to chain all logs of a single request in a distributed system.

[0043] In this embodiment, taking a fund with the code "FUND_003473" as an example, after its net asset value is released at the end of the day on February 4, 2026, the monitor will generate the following signal: json { "signalType":"EVENT", "eventCode":"NAV_CONFIRMED", "assetType":"FUND", "productCode":"003473", "clientNo":"", "bizDate":"2026-02-04", "batchId":"BATCH_20260204", "occurTime":"2026-02-0420:55:18", "sourceSystem":"CLEARING_SYSTEM", "traceId":"TRACE_20260204_8899001" } 2. Scheduled Signals: These originate from an integrated distributed task scheduling platform (such as XXL-Job). The platform sends scheduling instructions to the triggering module at preset time intervals (e.g., 23:00 every trading day) to trigger periodic full or incremental revenue calculations. The core fields of these signals are similar to those of event signals, but the signal type is fixed as "SCHEDULE" and typically does not include internal business event codes (eventCode). Example: json { "signalType":"SCHEDULE", "eventCode":"", "assetType":"FINANCE", "productCode":"", "clientNo":"", "bizDate":"2026-02-04", "batchId":"DAILY_BATCH_20260204", "occurTime":"2026-02-0423:00:00", "sourceSystem":"SCHEDULER_SYSTEM", "traceId":"TRACE_20260204_8899089" } Subsequently, the original signals are sequentially retrieved from the buffer queue, parsing and normalization pipeline processing is performed, and a unified internal signal object (InternalSignal) is output.

[0044] 1. Syntax parsing and validation: Perform syntax parsing on the original signal and validate the existence and basic format of the required fields (signalType, assetType, business date, and traceId).

[0045] 2. Semantic Mapping and Filling: The parsed raw signal fields are precisely transformed and enriched at the semantic level according to the system's internally defined business rules and data standards, generating InternalSignal objects that can be directly consumed by the downstream strategy engine. This process is deterministic, based on pre-defined mapping tables and calculation rules. For example, for asset types, asset types (assetType) that may be strings in the signal (such as "FUND") are mapped to enumerated constants defined internally by the system (such as AssetTypeEnum.FUND).

[0046] S12, based on a pre-set trigger strategy rule base, performs strategy matching on internal signal objects to determine the list of calculation dimensions.

[0047] The standardized internal signal object is fed into the rules engine and matched against a pre-defined trigger policy rule base to determine the specific behavior policy (TriggerPolicy) for this trigger. This includes: 1. Rule Base Query: The rule base uses signal features as keys and policy descriptions as values. Key dimensions for matching include: 1) Signal type + asset type + internal business event code (for event signals): For example, the combination key (EVENT, FUND, NAV_CONFIRMED) matches the strategy "simultaneously trigger revenue calculations in both customer share and customer turnover dimensions".

[0048] 2) Signal type + asset type + scheduling batch identifier (for timed signals): For example, the combination key (SCHEDULE, FINANCE, DAILY_BATCH) matches the strategy "triggering daily batch calculation of all dimensions (customer share, customer turnover)".

[0049] 2. Policy Parameter Acquisition: Extract and determine the parameters required for subsequent processing from the matched policies, including: 1) Calculate Dimensions list: Specifies which dimensions' benefits need to be calculated, such as [USER_SHARE] or [USER_SHARE,USER_TRANS].

[0050] 2) Processing Mode: such as "INCREMENTAL" (incremental calculation, based on the latest changes) or "FULL" (full calculation).

[0051] S13, assess the target scope of the triggering impact based on the internal signal object, wherein the target scope is the range of customers and products affected by the triggering impact.

[0052] Based on information such as asset type, product code, and client number in the internal signal object, accurately assess the scope of customers and products affected by this trigger. This includes: 1. Trigger Scope Assessment: Based on the calculation dimension list in step S12 and the asset type (assetType), product code (productCode), and client number (clientNo) information from the internal signal object obtained in step S11, the system status data is queried to precisely define all customers and product combinations that need to be covered in this revenue calculation task. This includes: 1) Product-level trigger assessment: When the internal signal object information indicates a product-level trigger (e.g., signal type "EVENT", asset type "FUND", product code 003473), the system queries the customer product holding relationship table based on product code (003473) to obtain a list of all customers holding this product. The impact scope assessment result is: the set of all customers holding product 003473 {C1, C2, ..., Cn}.

[0053] 2) Customer-level trigger assessment: When the internal signal object information indicates a customer-level trigger (e.g., signal type "EVENT", asset type "FUND", customer number "CUST10001"), the system directly extracts the customer number "CUST10001" and product code "003473". The impact assessment result is: customer CUST10001 and its held product 003473.

[0054] 3) Batch-level trigger assessment: When the trigger policy is indicated as batch-level trigger (usually matched by signal type SCHEDULE), the system does not need to parse the internal signal object, and the impact scope assessment result is: all effective customers and all products they hold.

[0055] S14: Construct a standardized triggering context containing a list of target topics, target scope, and calculation dimensions, and deliver it to the event publishing and processing stage.

[0056] Integrating the outputs of all the preceding steps, a complete, self-contained TriggerContext object is constructed. This object is the final output of the triggering module and the authoritative instruction driving downstream processes. Its structure includes the following core fields: Trigger ID (triggerId): A globally unique identifier, in the format TRIG_EVT_20260204_00089, used for end-to-end tracing.

[0057] Trace ID (traceId): A trace ID inherited from the original signal, ensuring link continuity.

[0058] TriggerType: An enumeration value, such as EVENT_DRIVEN (event-driven) or SCHEDULED (timer-driven), which is directly derived from the signalType.

[0059] Source Event: When the trigger type is EVENT_DRIVEN (event-driven), record detailed information about the original event (internal business event code, event identifier, occurrence time, and source system).

[0060] Asset Type (assetType): Standardized asset type enumeration values.

[0061] Target Topic: The message middleware topic determined by the asset type routing table, such as FUND_PROFIT_TOPIC for FUND assets.

[0062] TargetScope: A structured object describing the triggering scope. Its scope type (scopeType) can be PRODUCT, CLIENT, or BATCH, and it includes the corresponding product code (productCode), client number (clientNo), or batch number (batchId). The content of this field is directly derived from the scope evaluation result of step S13.

[0063] Calculated Dimensions (calcDimensions): An array that explicitly lists the calculated dimensions to be performed, derived from the policy matching results.

[0064] Calculation date (calDate): i.e., business date (bizDate).

[0065] Optionally, it also includes extended parameters (extParams): an extended parameter dictionary used to pass control parameters such as forceRecalc and incremental flags.

[0066] The final output of this step is a TriggerContext object.

[0067] In this embodiment, taking the end-of-day batch calculation of financial products as an example, this step will output the following context object: json { "triggerId":"TRIG_FIN_20260204_001", "traceId":"TRACE_20260204_8899089", "triggerType":"SCHEDULED", "assetType":"FINANCE", "targetTopic":"FINANCE_PROFIT_TOPIC", "targetScope":"BATCH", "calcDimensions":["USER_SHARE","USER_TRANS"], " calDate ":"2026-02-04", "sourceDataTime":"2026-02-0423:00:00", "extParams":{ "forceRecalc":false, "recalcReason":" }, "createTime":"2026-02-0423:00:01" } The completed TriggerContext object is asynchronously written to the Trigger Task Log Table for persistence. Then, it is sent to step S2 via non-blocking Remote Procedure Call (RPC) or reliable message delivery, thereby fulfilling the responsibilities of the triggering phase and decoupling scheduling and execution.

[0068] S2, based on the standardized trigger context, splits the revenue calculation task into multiple independent subtasks, encapsulates them into standardized revenue event messages, and publishes them.

[0069] This step is the event publishing and processing phase. It transforms the trigger context (TriggerContext) generated in step S1, which contains scheduling intentions, into a unified, semantically clear, and broadcastable benefit event message (ProfitEventMessage). This message middleware then drives subsequent steps for parallel computation. This includes: S21, based on the list of calculation dimensions in the standardized trigger context, the revenue calculation task is split into multiple independent subtasks divided by calculation dimensions, and encapsulated into a standardized revenue event message. The standardized revenue event message includes the target topic, target scope, calculation dimension, and calculation date.

[0070] Based on the list of computed dimensions in the TriggerContext, a macro-level trigger task is broken down into multiple independent, dimension-based subtasks, and each subtask is encapsulated into a standardized event message.

[0071] 1. Calculation Dimension Splitting: Parse the array of calculation dimensions (calcDimensions). For example, for the list ["USER_SHARE","USER_TRANS"], split the currently triggered task into two independent subtasks, corresponding to the customer share dimension and the customer transaction volume dimension, respectively.

[0072] 2. Profit Event Message Encapsulation: For each sub-task after splitting, encapsulate it according to a unified profit event message model (ProfitEventMessage). The encapsulation process fills in the following core fields for each event: Revenue Event Identifier (eventId): A globally unique identifier is generated for each revenue event, usually by a hash algorithm, and is used for end-to-end technology tracing.

[0073] TraceId: Inherited from the traceId in the trigger context, ensuring continuity throughout the entire chain.

[0074] Asset Type: Inherited from TriggerContext.

[0075] Computational dimension: The computational dimension corresponding to the current subtask, such as USER_SHARE.

[0076] TargetScope: Inherited from the targetScope in the trigger context.

[0077] Calculated Date (calDate): Inherited from the Calculated Date (calDate) in the TriggerContext.

[0078] Target Topic: Inherits from Trigger Context.

[0079] Source information: Records the trigger source, including the trigger ID (triggerId) and the internal business event code (eventCode, if any).

[0080] S22, route the revenue event message to the corresponding target topic for asynchronous delivery, and persist the event metadata.

[0081] By dividing business traffic into different target topics based on asset type, physical isolation and independent elastic scaling are achieved. For example, fund return events are routed to FUND_PROFIT_TOPIC, and wealth management return events are routed to FINANCE_PROFIT_TOPIC.

[0082] After a message is successfully delivered to the message middleware, the event's metadata is immediately written to the event log table for persistence. The recorded information includes at least: the event identifier (eventId), delivery status (e.g., SENT), target topic (targetTopic), associated trigger identifier (triggerId), and creation time. This is used for subsequent auditing, message compensation, and event replay.

[0083] The final output of this step is one or more standardized ProfitEventMessages with persistent metadata, which have been successfully delivered to the corresponding topic in the message middleware.

[0084] In this embodiment, taking the end-of-day batch calculation of wealth management products as an example, this step will generate and deliver the following event messages for the customer share dimension: json { "eventId":"evt_fin_prod_20260204_001", "traceId":"TRACE_20260204_8899089", "assetType":"FINANCE", "dimension":"USER_SHARE", " calDate ":"2026-02-04", "targetTopic":"FINANCE_PROFIT_TOPIC", "targetScope":"BATCH", "source":{ "triggerId":"TRIG_FIN_20260204_001", "eventCode":"", "sourceSystem":"SCHEDULER_SYSTEM" }, "processMode":"INCREMENTAL", "extParams":{ "forceRecalc":false }, "createTime":"2026-02-0423:00:02" } S3 subscribes to and processes standardized revenue event messages, breaks down each independent subtask into atomic subtasks, performs distributed revenue calculations, and generates the raw revenue results for customers.

[0085] The module subscribes to revenue event messages in the message middleware, performs multi-dimensional, distributed revenue calculations, and generates raw customer revenue results to be credited. This module operates on a publish-subscribe model, employs multi-instance deployment, thread pool scheduling, and sharding mechanisms, and supports dynamic scaling based on business load. This step includes the following sub-steps: S31, subscribe to and process standardized revenue event messages.

[0086] S32, for different independent subtasks, each independent subtask is divided into atomic subtasks with customer-product granularity according to the target range in the revenue event message, and then sharded and scheduled for parallel execution.

[0087] For different independent subtasks (i.e., different computational dimensions), based on the target scope in the revenue event message, the macro-level computational task is broken down into atomic subtasks with "customer-product" granularity, and then efficiently distributed and scheduled. This includes: 1. Logical Task Parsing: Parse the revenue event message. For events with a customer share dimension (USER_SHARE) and a scope type (BATCH), it means that the revenue of all products held by all customers needs to be calculated. The system needs to query the customer product holding relationship table to obtain the customer-product list.

[0088] 2. Generate Calculation Units: Based on the customer-product list and calculation dimension information, generate a series of calculation units (CalcUnits). Each calculation unit (CalcUnit) represents a minimum calculation task, with the structure: {customer number (clientNo), product code (productCode), calculation dimension (dimension)}.

[0089] 3. Sharding and Scheduling: Using load balancing algorithms such as consistent hashing, the generated list of computational units (CalcUnits) is sharded and distributed to different compute nodes within the cluster and different thread pools within those nodes. This enables the computational tasks of massive numbers of clients to be executed in true parallel, achieving horizontal scaling.

[0090] S33 loads the required data in parallel based on atomic subtasks. The required data includes customer holdings data, product net asset value data, customer transaction data, and historical return data.

[0091] Before each parallel computational subtask can perform its computation, it needs to load all the necessary business data, including: Based on the client number (clientNo) and product code (productCode) in the calculation unit (CalcUnit), data is concurrently loaded from various business tables, including client holding share data, product net asset value market data, client transaction history data, and historical return data. The loaded data includes at least one of the following: Customer holdings data: Load the customer's current total holdings (tot_vol), holding cost (cost), etc. from the customer holdings table.

[0092] Product net asset value (NAV) market data: Load the current unit NAV of the product from the product market data table.

[0093] Customer transaction data: Loads the cumulative cash inflows and outflows from the start date to the current day, which can be obtained by summarizing historical transaction data or read directly from the cumulative cash flow statement.

[0094] Historical earnings data: Load the cumulative earnings value of the previous day, the daily earnings value within the month, and the monthly earnings value within the year from the corresponding earnings table, which are used to calculate indicators such as daily earnings (cumulative earnings of the current day minus cumulative earnings of the previous day), monthly earnings (cumulative daily earnings), and annual earnings (cumulative monthly earnings).

[0095] Optionally, to ensure the accuracy and integrity of the computational basis, cross-validation can be performed on the loaded data, including: Integrity check: Check whether key fields (such as share, net value) are empty.

[0096] Time consistency check: Ensure that the loaded net asset value date, transaction confirmation date and calculation date match.

[0097] Business logic validation: For example, checking for abnormal situations such as negative share values.

[0098] S34, based on the loaded data, calls the revenue calculation model corresponding to the current calculation dimension, calculates various revenue indicators in turn, and generates the original customer revenue results.

[0099] The system pre-defines corresponding revenue calculation models for different calculation dimensions. Each model encapsulates the calculation logic for all revenue indicators under that dimension to perform at least one specific mathematical calculation. Taking customer share as an example, the mathematical calculation could be: Holding income calculation: Holding income = (Current holding units × Latest unit net value) - Holding cost.

[0100] Return on holding = Holding income / Holding cost

[0101] Taking customer transaction volume as an example, the mathematical calculation can be: Cumulative return calculation: Cumulative return = (Current holdings × Latest unit net value) + Cumulative cash inflow - Cumulative cash outflow.

[0102] Daily earnings = Daily cumulative earnings - Previous day's cumulative earnings.

[0103] Monthly income = ∑ Daily income (within the month).

[0104] Annual income = ∑ Monthly income (within the year).

[0105] Cash inflow refers to the cash received by customers from their investments, including redemption amounts and cash dividends, while cash outflow refers to the cash invested by customers, including subscription amounts.

[0106] 2. Generate raw customer earnings results: After calculation, the raw customer earnings results are generated, including customer number, product code, various earnings amounts, calculation date, earnings event identifier, and tracking identifier.

[0107] The original result of customer revenue is a structured data object, which contains core fields that define the complete semantics of the calculated output, including at least: customer identifier (clientNo), product code (productCode), calculation date (calDate), amount of the corresponding revenue type (such as holding revenue, day revenue, etc.), and revenue event identifier (eventId) and trace identifier (traceId) for end-to-end tracking.

[0108] S4 aggregates and persists the raw results of customer revenue into a unified revenue statement.

[0109] The massive and dispersed raw customer revenue results generated in step S3 are uniformly received, aggregated, and validated using business logic. Finally, they are accurately and consistently written into the corresponding revenue accounting tables in a transactional manner, completing the business loop from calculation to storage. This includes: S41 will group and aggregate the original customer revenue results for the same customer, product, and calculation date, and construct a unified final customer revenue result according to predefined rules.

[0110] Since a customer's final revenue status on a given day is determined by the original revenue results from multiple dimensions such as "customer share" and "customer revenue", it is necessary to merge (aggregate) these original results from different calculation paths for the same customer-product-calculation date to form the final revenue result.

[0111] Specifically, the results are grouped and merged according to (clientNo, productCode, calculation date) to construct a unified ClientProfitFinalizedResult object. Understandably, results within the same group may have different calculation dimensions and benefit types, but they describe different aspects of the same objective fact.

[0112] S42, writes the final state of customer revenue to multiple related revenue accounting tables in a transactional manner.

[0113] The aggregated and finalized customer revenue results are atomically written to multiple related revenue accounting tables using database transactions to ensure data consistency, including: 1. Start a database transaction: Start a database transaction for the final result of a customer-product-calculation date.

[0114] 2. Sequential writes across multiple tables: Executing multiple SQL insert or update operations within the same transaction, for example: Write the holding income and holding rate of return into the holding income table, the total income into the total income table, and the daily income into the daily income table, etc.

[0115] In this embodiment, taking the return of customer "CUST_10001" holding wealth management product "LC_001" on 2026-02-04 as an example, this step will generate the following (or similar) record in the database: The statement of holding income records: json { "caldate":"20260204", "clientno":"CUST_10001", "bankacc":"1505****", "productcode":"LC_001", "currtype":"156", "holdincome": 589.66, "holdincomerate": 0.007657 } Daily revenue statement records: json { "caldate":"20260204", "clientno":"CUST_10001", "bankacc":"1505****", "productcode":"LC_001", "currtype":"156", "dayincome": 2.66 } Through steps S1 to S4 above, this embodiment implements a revenue processing method based on event-driven and parallel computing. This method reconstructs the traditional serial batch processing architecture into an event-driven parallel processing topology: First, based on the list of computational dimensions in the standardized trigger context, the revenue calculation task is split into multiple independent subtasks divided by dimension, and these subtasks are routed to the corresponding message topics for asynchronous delivery according to asset type; subsequently, during processing, each independent subtask is further decomposed into atomic subtasks with "customer-product" granularity, and the parallel execution of massive atomic tasks is achieved through sharding scheduling, thereby significantly improving the system's processing efficiency and resource utilization.

[0116] Example 2

[0117] This embodiment provides another revenue processing method based on event-driven and multi-layer parallel architecture. Based on steps S1-S2 and S4 of embodiment one, an event-level idempotent identifier is further introduced for the revenue event message in step S2.

[0118] The event-level idempotent identifier (idempotentKey) is globally unique and synthesized based on the target topic, target scope, and calculation dimension. It is used to uniquely identify a revenue event scenario and ensure that the revenue result under the same scenario is processed only once.

[0119] Example of generation rule: Event-level idempotent identifier (idempotentKey) = targetTopic (targetTopic) + "_" + targetScope (targetScope) + "_" + calculated dimension (dimension).

[0120] S3 subscribes to and processes standardized revenue event messages. After performing event-level idempotency verification based on the event-level idempotency identifier, it breaks down each independent subtask into atomic subtasks, performs distributed revenue calculations, and generates the original revenue results for customers.

[0121] This step, based on Example 1, adds an event-level idempotency check to ensure that each benefit event message is successfully processed only once. Specifically, it includes the following sub-steps: S31, subscribe to and process standardized revenue event messages.

[0122] S32a: Query the event processing record table based on the event-level idempotency identifier in the revenue event message, perform event-level idempotency verification, and only proceed to S32 after the verification passes.

[0123] After subscribing to and consuming event messages distributed by the message middleware, in order to avoid duplicate calculations caused by message middleware re-delivery, an event-level idempotency check is introduced before starting substantive calculations.

[0124] S32, for different independent subtasks, each independent subtask is divided into atomic subtasks with customer-product granularity according to the target range in the revenue event message, and then sharded and scheduled for parallel execution.

[0125] S33 loads the required data in parallel based on atomic subtasks. The required data includes customer holdings data, product net asset value data, customer transaction data, and historical return data.

[0126] S34, based on the loaded data, calls the revenue calculation model corresponding to the current calculation dimension, calculates various revenue indicators in turn, and generates the original customer revenue results.

[0127] Specifically, step S32a involves querying the event processing record table based on the event-level idempotency identifier in the revenue event message and performing event-level idempotency verification, including: 1. Message deserialization: Deserialize the binary or JSON format message body received from the message middleware into a structured ProfitEventMessage object.

[0128] 2. Idempotent Key Query: Extract the event-level idempotent identifier (idempotentKey) from the message. This identifier is generated in step S21, and its rules ensure its uniqueness within the same business scenario (same topic, product, dimension).

[0129] 3. Idempotency Determination: Using the idempotentKey as the key, query the event processing record table. If a record is found and its status is "Processed Successfully" (PROCESSED_SUCCESS), the event is considered to have been successfully processed. The system will directly discard or acknowledge consumption of this message, without performing further calculations, and return a successful consumption confirmation to the message middleware to prevent duplicate interest calculation.

[0130] 4. Status Marking: If no record is found or the record status is "failed," insert or update a record in the event handling record table, mark the status as "Processing," and record metadata such as the event identifier (eventId). This operation usually needs to be completed within a database transaction to ensure state consistency in concurrent scenarios.

[0131] Example 3

[0132] This embodiment provides another revenue processing method based on event-driven and multi-layer parallel architecture. Based on steps S1-S4 of Embodiment 1 or Embodiment 2, a customer-level idempotent identifier is further introduced into the original customer revenue result in step S3.

[0133] To prevent the same customer, product, dimension, and revenue type from being repeatedly inserted in subsequent accounting processes, a customer-level idempotent identifier (idempotentKey) is generated for the original customer revenue result.

[0134] The customer-level idempotent key is synthesized based on the target topic, product code, customer number, calculation dimension, and revenue type.

[0135] Example of a generation rule: clientIdempotentKey=targetTopic+"_"+productCode+"_"+clientNo+"_"+dimension+"_"+incomeType. IncomeType includes holding income, daily income, etc.

[0136] Before step S4, this embodiment further includes S4a, which performs customer-level idempotency verification on the original customer revenue results, and only proceeds to S4 after the verification passes.

[0137] This step introduces customer-level idempotent controls and multi-dimensional consistency checks to ensure the final accuracy, uniqueness, and non-repudiation of financial data. This includes: S4a1 extracts the customer-level idempotent identifier from the original customer revenue results for deduplication and interception.

[0138] Receive the raw customer revenue result (ClientProfitIntermediateResult) from step S3. To prevent the same revenue data from being recorded repeatedly due to network retransmissions, duplicate submissions by compute nodes, etc., strict customer-level idempotent control, with the customer-product granularity, needs to be performed before data entry. This includes: 1. Extract idempotent key: Extract the client-level idempotent identifier (clientIdempotentKey) from each original result object. Its rules (e.g., FINANCE_LC_001_CUST_10001_USER_SHARE_DAYLY_DAY) uniquely identify "which customer, which product, and which benefit".

[0139] 2. Distributed Idempotent Deduplication: Deduplication is performed based on the client-level idempotent identifier (clientIdempotentKey), including: 1) Fast interception at the caching layer: First, query the distributed cache (such as Redis) to check if a record exists with the clientIdempotentKey as the key. If it exists, it indicates that the result has most likely been processed, so discard the current result and log it.

[0140] 2) Database Layer Final Confirmation: For results that miss the cache, or in scenarios with high reliability requirements, a further query is performed on the final revenue result table (or a dedicated idempotency control table). Unique indexes on fields such as (client_no, prd_code, calcPeriod, dimension, income_type) are used for conflict detection. If a unique key conflict is detected, the result is considered a duplicate and is discarded.

[0141] 3) Idempotency pass mark: For results that pass idempotency verification, immediately set a short-lived key (key is clientIdempotentKey, value is result digest) in the distributed cache (such as Redis), and mark the result as "to be added to the database" before proceeding to the next step. This operation can effectively handle repeated submissions of the same result within a short period of time.

[0142] S4a2 performs cross-field business logic consistency checks on the original customer revenue results that pass the deduplication check.

[0143] For the original customer revenue results controlled by idempotency, it is not only necessary to verify the data format, but more importantly, to verify the correctness of its internal business logic, ensuring that the revenue data conforms to established financial rules and reconciliation relationships, including: 1. Basic integrity verification: Check whether the core fields such as client number (clientNo), product code (productCode), calculation dimension (dimension), income type (incomeType), and various income amounts in the original customer income results are complete and correctly formatted (e.g., the amount is numeric).

[0144] 2. Cross-field logical consistency verification: This involves executing a series of deterministic mathematical formulas for verification, which is crucial for ensuring the accuracy of financial data. This includes: 1) Cumulative Return Verification Verify that total income equals the current portfolio value plus total cash inflow minus total cash outflow. This verification ensures that the calculation of total income strictly adheres to its definition, fundamentally guaranteeing data accuracy.

[0145] 2) Cash flow balance verification Verify that daily return equals the daily market capitalization change minus the daily net cash flow, cross-checking the match between cash flow data and market capitalization changes. That is, daily return (dayIncome) = (daily cumulative inflow (nowAccInflow) - daily cumulative outflow (nowAccOutflow)) + market capitalization change. This verification can effectively identify missing cash flow records, incorrect net asset value, or calculation logic problems.

[0146] 3) Validation of cumulative periodic returns For cyclical indicators such as monthly and annual returns, it can be verified during the aggregation phase whether they are equal to the sum of daily returns within the period: monthIncome =ΣdayIncome (current month) yearIncome =ΣmonthIncome (current year) This check ensures the accuracy of the periodic summary.

[0147] 4) Anomaly Handling: If verification fails, the original customer revenue result is considered a "suspicious result." The system will not discard it directly but will transfer it to the "Audit Anomaly Queue," recording the detailed error type and context, and triggering an alarm for subsequent manual or automated audit processes. Original customer revenue results that successfully pass all verifications enter the aggregation stage.

[0148] Example 4

[0149] This embodiment provides another revenue processing method based on event-driven and multi-layered parallel architecture. Building upon embodiments one through three, it further introduces a proactive auditing step. This proactively and periodically performs multi-dimensional consistency audits on the recorded customer revenue results, tracing back to the original business data. It intelligently locates the root cause of data inconsistencies and automatically executes repair actions and targeted recalculations, thereby transforming the traditional "post-event passive audit" into "in-event proactive assurance," achieving long-term stability and 100% accuracy of revenue accounting results. This step is an independent, closed-loop quality control process.

[0150] This embodiment, following step S4, further includes S5, which, based on the original business data, performs proactive consistency auditing, anomaly location and automatic repair on the persisted final customer revenue results, and triggers targeted recalculation to form a quality assurance closed loop. Specifically, it includes the following sub-steps: S51 triggers an audit task based on the audit strategy and retrieves original customer transaction data, customer holding data, product market data, and historical return data within the specified audit scope.

[0151] The pre-set audit trigger point in this step will be automatically activated, and all the original business data required for the audit will be retrieved, including: 1. Audit Trigger: Automatically triggered based on pre-configured audit policies. The most common trigger policy is end-of-day audit, which is triggered uniformly by the scheduling system or internal timer after the settlement of daily transactions involving wealth management, funds, etc. It can also support targeted audit triggers based on products or customer scope.

[0152] 2. Determine the audit scope: Analyze the audit trigger instructions to determine the asset types, product range, customer range, and calculation date for this audit (e.g., 2026-02-04).

[0153] 3. Multi-source data retrieval: Based on the defined audit scope, the following core raw data will be retrieved concurrently from persistent storage as audit benchmarks, including customer holdings data, product market data, customer transaction data, and historical return data.

[0154] S52, based on the pulled raw data, performs parallel audits of share changes between flow data and share data, cash flow consistency, historical revenue data consistency, and recalculated theoretical revenue and actual revenue consistency.

[0155] Based on the retrieved raw data, a series of deterministic cross-validation rules are executed to proactively identify data inconsistencies. The audit process does not rely on pre-calculated revenue results, but rather derives them forward from the raw data, including: 1. Transaction Flow-Share Consistency Audit: For each customer-product pair, obtain its initial share on the calculation date (which can be obtained by querying the share snapshot of the previous day), and summarize all transaction flows (such as subscriptions, redemptions, and dividend reinvestment) that affect the customer's share of the product within the calculation date.

[0156] Calculate the calculated share amount: Calculated daily closing share amount = Initial share amount + Σ Confirmed subscription share amount (cfmvol) - Σ Confirmed redemption share amount (cfmvol) + Other share adjustment items. Compare the calculated daily closing share amount with the actual daily closing share amount (totvol) retrieved from the customer share table on the calculation date.

[0157] If there is a significant difference between the derived and actual values ​​of the marked share for a customer-product pair, the anomaly type is "Share Inconsistency Anomaly".

[0158] 2. Cash Flow Consistency Audit: For each customer-product pair, obtain its initial cumulative cash inflows and cumulative cash outflows on the calculation date (obtainable from the cumulative cash flow statement or historical summary data), and summarize all transaction flows affecting cash flow within the current calculation date, including subscription amount, redemption amount, cash dividend amount, etc. Perform cash flow derivation calculation: Derived daily cumulative cash inflow = previous day's cumulative cash inflow + daily redemption amount + daily cash dividend amount; Derived daily cumulative cash outflow = previous day's cumulative cash outflow + daily subscription amount.

[0159] The derived cumulative cash inflows and outflows for the day are compared with the actual values ​​retrieved from the cumulative cash flow statement. If the difference exceeds a preset threshold, the anomaly type is marked as "cash flow inconsistency anomaly".

[0160] 3. Historical Revenue Data Consistency Audit: For each customer-product pair, obtain an audited snapshot of historical revenue data (including daily and monthly revenue), and compare the audited historical revenue data snapshot with the actual values ​​for the calculation date pulled from the customer's historical revenue data. If the difference exceeds a preset threshold, the anomaly type is marked as "Historical Revenue Data Inconsistency Anomaly".

[0161] 4. Audit of consistency in return calculation: For each customer-product pair, using the original data such as the derived share on the audit date (calculation date), the unit net value in the product market, the holding cost in the share snapshot, and the audited historical return data snapshot, various return calculation formulas are re-executed to calculate the theoretical return value.

[0162] Taking the calculation of holding income as an example, the theoretical holding income = (current holding shares × latest unit net value) - holding cost.

[0163] The calculated theoretical holding income is compared with the holding income (holdincome) recorded on the corresponding date in the holding income table.

[0164] If a customer-product pair is marked with a discrepancy between the theoretical and actual revenue that exceeds a reasonable margin of error, the anomaly type is "Revenue Calculation Anomaly".

[0165] S53, locate the root cause of the anomaly based on the type of anomaly found in the audit, and execute the matching automated data repair action.

[0166] Root cause analysis is performed on the anomalies detected in step S52, and corresponding data repair actions are automatically executed based on a predefined repair strategy library, including: 1. Root cause identification: Based on the exception type and context information, the rule engine is invoked for intelligent judgment. If the error message is "Share Inconsistency Anomaly," it indicates an error in the share registration source data (usually a problem with the registration system). If the error message is "Cash Flow Inconsistency Anomaly," it indicates an error in the transaction flow data or an error in the cumulative cash flow summary (such as incorrect records of subscription, redemption, or dividend amounts).

[0167] If the error message is "Inconsistent historical earnings data", it indicates an error in the extraction or modification of historical earnings data (such as omissions or duplicates when extracting data from the historical earnings table).

[0168] If the error message is "Revenue calculation error", it indicates an error in the revenue calculation process (which may be caused by a bug in the parallel computing module or a data loading error).

[0169] 2. Perform automated remediation: Based on the identified root cause, match and execute corresponding remediation actions from the remediation strategy library, including: 1) Share Correction: For inconsistencies in shares, the share values ​​derived from the transaction history and which are logically correct will be updated to a temporary "Correct Share Reference Table", or a share correction request will be initiated to the share registration system.

[0170] 2) Cash flow correction: For inconsistencies in cash flow, the correct cumulative cash inflow / outflow values ​​derived from the transaction log will be updated to the temporary "Correct Cash Flow Reference Table", or a data correction request will be initiated to the transaction log system.

[0171] 3) Historical data repair: For inconsistent historical revenue data, the erroneous records are marked as "invalid" and the correct values ​​are restored from the audited snapshot.

[0172] 4) Profit Correction: For errors in the calculation process, the relevant profit records are directly marked as "invalid".

[0173] All repair operations are logged in detail, including the exception ID, repair action, value before repair, value after repair, and operation time.

[0174] S54, based on the repair results, automatically builds and triggers a targeted recalculation trigger context for the affected customer and product range, so as to drive the system to recalculate the specific range.

[0175] In cases where abnormal earnings are caused by data errors (transaction logs, market data, share volume, historical data) or calculation errors, the audit and repair module will automatically trigger a precise earnings recalculation process targeting only the affected area. This ensures that the final result is consistent with the correct business logic, including: 1. Generate recalculation trigger context: Based on the repair results and the list of affected customers and products, automatically construct one or more recalculation trigger contexts. This context is constructed similarly to S1, but has the following characteristics: targetScope is precise down to the specific affected customers and products.

[0176] The dimension (calculated dimension) is determined based on the type of exception (e.g., if the share is incorrect, the USER_SHARE dimension may need to be recalculated).

[0177] In extParams (extended parameters), set forceRecalc (force recalc) to true and specify recalcReason (the reason for recalc is "audit repair").

[0178] 2. Drive the standard recalculation process: The generated recalculation trigger context is used as input and resubmitted to the revenue event publishing module (i.e., the input for step S2). The system will then use this as a starting point to completely re-execute the subsequent standard process of event publishing (step S2) → parallel computing (step S3) → result aggregation and accounting (step S4).

[0179] 3. Closed-loop verification: After the recalculation process is completed, a targeted small-scale audit can be triggered again to verify whether the newly generated revenue data after the repair has passed the consistency check, thus forming a complete "audit discovery → location and repair → recalculation update → verification closed loop".

[0180] In this embodiment, taking the wealth management product "LC_001" and customer "CUST_10001" as an example, assuming that in the end-of-day audit on February 4, 2026, step S52, "Transaction Flow-Share Consistency Audit," discovers that the customer's derived share value (calculated based on the subscription transaction flow) is 10,000 units, but the share table only records 8,000 units, indicating a "share inconsistency anomaly." Step S53 identifies the error as an error in the share registration source data and records the correct share as 10,000 units in the temporary table. Subsequently, step S54 generates a recalculation event for {Asset: "FINANCE", Product: "LC_001", Customer: "CUST_10001", Date: "2026-02-04"}, driving the system to recalculate the return for this customer and this product only on this day. The new calculation is based on the correct share (10,000 units), ultimately generating the correct holding return, daily return, etc., and updating the accounting table, covering the erroneous return data caused by the previous share error.

[0181] Example 5

[0182] like Figure 3 As shown, this embodiment provides a revenue processing system based on event-driven and multi-layer parallel architecture, used to implement any of the above revenue processing methods based on event-driven and multi-layer parallel architecture.

[0183] The system is a physical and logical implementation of a revenue processing method based on event-driven and multi-layered parallel architecture. Through modular and loosely coupled architecture design, it decomposes the revenue processing flow into a series of professional components that can be deployed independently, scaled elastically, and work collaboratively, together forming an efficient, reliable, and self-healing distributed processing system.

[0184] The system mainly includes the following core modules, which communicate with each other through standardized data interfaces and message protocols to form a complete processing chain: The revenue triggering module 101 is used to receive and process multi-source triggering signals and generate a standardized triggering context for the revenue calculation task.

[0185] The revenue event publishing module 102 is used to split the revenue calculation task into multiple independent subtasks according to the standardized trigger context, encapsulate them into standardized revenue event messages, and publish them.

[0186] The message middleware 103 is used to connect to the revenue event publishing module 102 and to receive and distribute revenue event messages.

[0187] The parallel computing processing module 104 is used to subscribe to and process standardized revenue event messages, break down each independent subtask into atomic subtasks, perform distributed revenue calculations, and generate the original revenue results for customers.

[0188] The Results Aggregation and Accounting Module 105 is used to aggregate and persist the original results of customer revenue to a unified revenue accounting table.

[0189] Optionally, the system further includes: The audit and repair module 106 is used after module 105 is executed to perform proactive consistency audit, anomaly location and automatic repair on the persisted customer revenue final state results based on the original business data, and trigger targeted recalculation to form a quality assurance closed loop.

[0190] In summary, this embodiment of the system, through the organic collaboration of the aforementioned professional modules, engineered the concept of dynamic parallel processing based on revenue events, achieving decoupling of the processing flow, elastic scaling of computing resources, a significant improvement in processing timeliness, and proactive closed-loop management of data quality.

[0191] Example 6

[0192] This embodiment proposes an electronic device, including: Memory, used to store computer programs; A processor is used to execute a program stored in memory to implement the steps of any of the above embodiments of the revenue processing method based on event-driven and multi-layered parallel architecture.

[0193] For details on the specific implementation of each step and related explanations, please refer to any of the aforementioned examples of revenue processing methods based on event-driven and multi-layered parallel architectures; they will not be elaborated upon here.

[0194] The memory of the electronic device mentioned in this embodiment may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0195] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0196] Example 7

[0197] This embodiment also proposes a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of any of the above embodiments of the revenue processing method based on event-driven and multi-layered parallel architecture. For specific implementation details and explanations of each step, please refer to the aforementioned embodiment of the revenue processing method based on event-driven and multi-layered parallel architecture; further elaboration is not provided here.

[0198] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A revenue processing method based on event-driven and multi-layer parallel architecture, characterized in that, Includes the following steps: S1 receives and processes multi-source trigger signals to generate a standardized trigger context for the revenue calculation task; S2, based on the standardized trigger context, splits the revenue calculation task into multiple independent subtasks, encapsulates them into standardized revenue event messages, and publishes them; S3 subscribes to and processes standardized revenue event messages, breaks down each independent subtask into atomic subtasks, performs distributed revenue calculations, and generates the raw revenue results for customers. S4 aggregates and persists the raw results of customer revenue into a unified revenue statement.

2. The method according to claim 1, characterized in that, Step S1 specifically includes: S11 receives internal business event signals from internal business monitoring and timed scheduling signals from external scheduling platforms, and performs parsing and standardization conversion to generate internal signal objects; S12, Based on a preset triggering strategy rule base, perform strategy matching on the internal signal object to determine the calculation dimension list; S13, based on the internal signal object, assess the target scope of the triggering impact, where the target scope is the range of customers and products affected by the triggering impact; S14: Construct a standardized triggering context containing a list of target topics, target scope, and calculation dimensions, and deliver it to the event publishing and processing stage.

3. The method according to claim 1, characterized in that, Step S2 specifically includes: S21, based on the list of calculation dimensions in the standardized trigger context, the revenue calculation task is split into multiple independent subtasks divided by calculation dimensions, and encapsulated into a standardized revenue event message, wherein the standardized revenue event message includes the target topic, target scope, calculation dimension, and calculation date; S22, route the revenue event message to the corresponding target topic for asynchronous delivery, and persist the event metadata.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: S31, Subscribe to and process standardized revenue event messages; S32, for different independent subtasks, each independent subtask is divided into atomic subtasks with customer-product granularity according to the target range in the revenue event message, and the subtasks are sharded and scheduled for parallel execution. S33, Based on the parallel loading of atomic subtasks, the required data is loaded, including customer holding share data, product net value market data, customer transaction flow data and historical return data; S34, based on the loaded data, calls the revenue calculation model corresponding to the current calculation dimension, calculates various revenue indicators in turn, and generates the original customer revenue results.

5. The method according to claim 4, characterized in that, The standardized benefit event message encapsulated in step S2 also includes an event-level idempotent identifier, which is synthesized based on the target topic, target scope, and computational dimension; step S3, before splitting into atomic subtasks, also includes: S32a: Based on the event-level idempotency identifier in the revenue event message, query the event processing record table to perform event-level idempotency verification, and only proceed to S32 after the verification passes.

6. The method according to any one of claims 1 to 5, characterized in that, The raw customer revenue result generated in step S3 includes a customer-level idempotent identifier, which is synthesized based on the target topic, product code, customer number, calculation dimension, and revenue type. Step S4 is preceded by: S4a performs a customer-level idempotency check on the original customer revenue results, and only proceeds to S4 after the check passes.

7. The method according to any one of claims 1 to 6, characterized in that, Step S4 is followed by: S5, based on the original business data, performs proactive consistency auditing, anomaly location and automatic repair on the persistent final state results of customer revenue, and triggers targeted recalculation to form a quality assurance closed loop.

8. A revenue processing system based on event-driven and multi-layered parallel architecture, used to implement the method according to any one of claims 1 to 7, characterized in that, include: The revenue triggering module is used to receive and process multi-source triggering signals and generate a standardized triggering context for the revenue calculation task. The revenue event publishing module is used to split the revenue calculation task into multiple independent subtasks based on the standardized trigger context, encapsulate them into standardized revenue event messages, and publish them. The message middleware is used to connect to the revenue event publishing module, receive and distribute revenue event messages; The parallel computing processing module is used to subscribe to and process standardized revenue event messages, break down each independent subtask into atomic subtasks, perform distributed revenue calculations, and generate the raw revenue results for customers. The Results Aggregation and Accounting module is used to aggregate and persist the original customer revenue results to a unified revenue accounting table.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method described in any one of claims 1 to 7.

Images