A method and system for batch calculation of asset depreciation based on distributed load balancing

Abstract

This invention relates to the field of data service computing, and particularly to a method and system for batch calculation of asset depreciation based on distributed load balancing. Addressing the centralized performance bottlenecks, insufficient system elasticity, and rigid core computing logic faced by traditional systems when processing massive amounts of cards, this solution deeply decouples the underlying data from the computation. The method includes calling a distributed database to perform data sharding queries, cutting and encapsulating asset data into computation task messages; asynchronously distributing tasks to idle asset service instances through the load balancing mechanism of a message middleware; dynamically parsing text expressions in application-layer memory using a rule engine to rapidly execute financial depreciation calculations; and finally, asynchronously writing the results back through an anti-replay mechanism to ensure data consistency. This application, through a pipelined architecture of data sharding, message distribution, and in-memory computation, significantly improves concurrent processing efficiency and system disaster recovery stability, and achieves flexible configuration management.

Description

Technical Field

[0001] This invention relates to the field of data service technology, and in particular to a method and system for batch calculation of asset depreciation based on distributed load balancing. Background Technology

[0002] In the financial information management systems of large enterprises, fixed asset depreciation calculation is a core step in the month-end or year-end closing process. As enterprises expand, the number of asset cards grows exponentially, and the massive amount of depreciation accrual poses a significant challenge to the system's processing capacity. However, traditional financial asset management systems have gradually revealed the following serious architectural flaws and technical bottlenecks when handling massive card depreciation transactions: 1. Traditional monolithic systems often employ serial or small-batch cyclic computation patterns. Application servers need to send frequent read and write commands to the database, resulting in massive I / O interactions and network overhead. A single database node can easily reach its physical limits, causing depreciation tasks to take hours or even longer, resulting in extremely low efficiency.

[0003] 2. Due to the deep coupling between computing and storage, single-node servers are prone to memory overflow or database deadlocks due to resource exhaustion during peak task periods. Furthermore, traditional architectures struggle to achieve linear performance improvements by horizontally adding nodes, lacking system elasticity and posing a high risk of single points of failure.

[0004] 3. Traditional systems typically hardcode depreciation algorithms at the system's underlying level. When national tax laws or corporate management policies change, it requires a lengthy process of code refactoring, testing, and downtime deployment, resulting in high system maintenance costs and an inability to respond agilely to business changes.

[0005] Therefore, a new computing architecture is needed that can break through the performance bottleneck of centralized computing, fully schedule distributed cluster computing resources, completely decouple computing and storage, and have a high degree of dynamic parsing capability for business rules. Summary of the Invention

[0006] To address the performance bottlenecks, insufficient flexibility, and high maintenance costs associated with hard-coded depreciation in traditional centralized asset management systems when performing massive asset depreciation calculations, this invention provides a batch asset depreciation calculation method and system based on distributed load balancing. This method achieves the externalization of core computing logic, extreme parallelization of tasks, and dynamic and flexible configuration of business rules.

[0007] A batch calculation method for asset depreciation based on distributed load balancing, characterized by the following steps: S1 calls the distributed database to perform sharded queries, divides the full asset data into multiple logical shards according to the preset asset classification keywords, and encapsulates the asset data in each logical shard and its corresponding computing context into a standard format computing task message. S2 publishes the encapsulated computing task message to the message middleware. Through the load balancing mechanism of the message middleware, the computing task message is asynchronously distributed to multiple asset service instances that are in an idle state. S3, after the asset service instance consumes the computing task message, calls the rule engine in the memory of the asset service instance to dynamically parse the pre-configured depreciation expression, and performs calculations on the asset data in the computing task message according to the depreciation expression to obtain the depreciation result; S4 asynchronously writes the calculated depreciation result back to the distributed database and updates the task status record corresponding to the calculation task message. The state synchronization mechanism and the anti-replay mechanism are used to ensure the eventual consistency and idempotency of data processing.

[0008] Furthermore, in order to better realize the present invention, the preset asset classification keywords include asset identifier hash value, department number or legal entity code; the step of calling the distributed database to perform sharded query in S1 includes interacting with the metadata management module of the distributed database to obtain the real-time data distribution of each storage node and the overall topology of the cluster, and dividing the asset data table into data subsets with independent data boundaries based on the topology, and each data subset constitutes a logical shard that can be independently operated.

[0009] Furthermore, in order to better implement the present invention, in the step of publishing the encapsulated computing task message to the message middleware in S2, an asynchronous non-blocking protocol is used for message persistence delivery; the load balancing mechanism adopts a competitive consumption mode, and multiple asset service instances in the application layer cluster are configured as a unified consumer group, and each asset service instance independently pulls computing task messages according to its own processing capacity.

[0010] Furthermore, to better realize the present invention, the pre-configured depreciation expressions include the straight-line method expression and the unit-of-production method expression; the step in S3 of calling the rule engine to dynamically parse the pre-configured depreciation expressions in the memory of the asset service instance includes mapping and binding the state variables in the calculation context to the parameter nodes of the depreciation expressions, and performing floating-point arithmetic operations in memory by constructing an abstract syntax tree, thus avoiding read and write requests to external databases throughout the calculation process.

[0011] Furthermore, in order to better realize the present invention, the steps in S4 that use state synchronization mechanism and anti-replay mechanism to ensure the eventual consistency and idempotency of data processing include: setting up a task anti-duplicate table in the distributed database; using a globally unique transaction identifier to intercept repeatedly delivered computation task messages; when an exception occurs in the asynchronous write-back of depreciation results, the exponential backoff retry mechanism of the message middleware is triggered; if the maximum retry threshold is reached, the computation task message is transferred to the dead letter queue.

[0012] This application also provides a batch asset depreciation calculation system based on distributed load balancing, including a data sharding and task generation module, a message scheduling and load balancing module, an in-memory computing engine module, and a result processing and state management module. The system is characterized by: the data sharding and task generation module calling a distributed database to perform sharded queries, dividing the full asset data into multiple logical shards according to preset asset classification keywords, and encapsulating the asset data and its corresponding computing context within each logical shard into a standard format computing task message; the message scheduling and load balancing module publishing the encapsulated computing task message to a message middleware, and asynchronously distributing the computing task message to multiple idle asset service instances through the load balancing mechanism of the message middleware; the in-memory computing engine module, after the asset service instance consumes the computing task message, calling a rule engine in the memory of the asset service instance to dynamically parse the pre-configured depreciation expression, and performing calculations on the asset data in the computing task message according to the depreciation expression to obtain the depreciation result; and the result processing and state management module asynchronously writing the calculated depreciation result back to the distributed database and updating the task status record corresponding to the computing task message, using a state synchronization mechanism and an anti-replay mechanism to ensure the eventual consistency and idempotency of data processing.

[0013] Furthermore, to better realize the present invention, the distributed database adopts a purely distributed architecture that separates computation and storage, which includes a structured query statement layer that receives client connections and generates distributed execution plans, storage nodes, and a metadata management node responsible for the storage topology; the data sharding and task generation module generates computation task messages by sending query statements carrying sharding conditions to the structured query statement layer.

[0014] Furthermore, to better realize the present invention, the in-memory computing engine module is configured with a high-performance dynamic parser, which includes a lexical analysis unit, a syntax analysis unit, and an instruction cache pool, for reusing the abstract syntax tree execution plan of the successfully compiled depreciation expression when computing the full asset data.

[0015] This application also provides a computer device, including at least one processor and at least one memory, wherein the memory stores computer instructions, and when the processor executes the computer instructions, it implements the above-described batch calculation method for asset depreciation based on distributed load balancing.

[0016] This application also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the above-described batch calculation method for asset depreciation based on distributed load balancing.

[0017] The beneficial effects of this invention are as follows: This solution achieves a leap forward in computational efficiency, completely breaking through traditional performance bottlenecks. By leveraging the data partitioning capabilities of distributed databases, the massive depreciation task, which originally required locking mechanisms on global tables, is broken down into thousands of independent, micro-computational subtasks with their own data boundaries. These microtasks are executed in full parallelism within the cluster environment, drastically reducing batch processing jobs that previously took hours to the minute level. Furthermore, the overall system's computational throughput and performance show near-perfect linear growth as the scale of the backend computing node cluster expands, providing a solid technical guarantee for large enterprises to handle massive data surges during month-end or annual financial reporting windows.

[0018] By introducing a high-throughput message middleware as a buffer hub between the data provider and the data computation end, this solution completely eliminates the tight coupling between system components. The inherently efficient traffic shaping and asynchronous communication characteristics of message queues enable the smooth transformation of sudden bursts of computational requests into a controllable data flow. More importantly, even in complex network environments where individual computing instances experience hardware failures or memory exhaustion, the system ensures that no obsolete computational task is lost in the failure thanks to message persistence mechanisms, consumer acknowledgment mechanisms, and dead-letter queue management. Surviving healthy nodes can quickly take over abnormally interrupted tasks, greatly improving the system's fault tolerance and availability.

[0019] Traditional database-intensive applications are often hampered by disk I / O bottlenecks, while this solution implements a strategy that shifts the computational load to the application layer. Once the computational task message is consumed, the complex depreciation calculation process is entirely performed within the high-speed memory of the application instance, virtually eliminating multiple dependencies and wait times on the database within the computation loop. Combined with the load balancer's scientific scheduling of cluster nodes, this system maximizes and activates the multi-core CPU computing potential of each application server, transforming the originally heavily I / O-intensive tasks into purely computationally intensive tasks, achieving optimal hardware and software resource allocation.

[0020] By integrating a lightweight rule engine with abstract syntax tree compilation capabilities, this system completely eliminates the outdated practice of hard-coding business logic at the system's underlying level. All accounting policies, calculation formulas, and differentiated depreciation rates are abstracted and transformed into dynamically configurable string expressions. This means that enterprise system administrators or business personnel can directly modify depreciation rules based on external tax law updates or internal management requirements through the system's front-end configuration page, and the modified rules will immediately take effect in the next batch processing. This configuration-instant-effect mechanism eliminates lengthy system downtime updates, code backtesting, and other cumbersome processes, significantly reducing software lifecycle maintenance costs. Attached Figure Description

[0021] Figure 1 This is a flowchart of the calculation method of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different ways.

[0023] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0024] Figure 1 This is a specific embodiment of the present invention, which is a batch calculation method for asset depreciation based on distributed load balancing. The method covers four key technical steps.

[0025] First, the S1 step, asset data sharding, is executed. This step is the foundation for data preparation to achieve large-scale parallel computing. When processing monthly depreciation operations involving tens of millions of fixed asset records for large multinational corporations, using traditional single-point full queries would undoubtedly lead to application-layer memory overflow or directly paralyze the database service. Therefore, this embodiment makes full use of the architectural advantages of distributed databases. Distributed databases are fundamentally different from traditional single-machine databases. They possess a naturally distributed architecture, excellent scalability, and can support elastic scaling of storage and computing resources. The internal architecture of a distributed database encompasses three core components: First, the SQL computation layer, responsible for exposing the standard MySQL network protocol, receiving and parsing client structured queries, and optimizing them into distributed execution plans; second, the metadata management node, acting as the brain of the entire cluster, which monitors the data distribution of each underlying storage node and the overall physical topology of the cluster in real time, and provides global timestamps and distributed transaction allocation; third, the distributed storage nodes, responsible for the persistence of multiple copies of the actual data.

[0026] In S1, the data sharding and task generation module sends query commands to the SQL layer of the distributed database. The metadata management node provides feedback on the current Region distribution of the asset table. Based on this, the system applies preset asset classification keywords for sharding. Classification keywords can be flexibly selected according to business dimensions, such as using the hash value range of asset identifiers, specific department number ranges, or the legal entity code of independently accounted companies. Through this mechanism, the massive asset data table is intelligently and evenly divided into hundreds or even thousands of logical shards. Each logical shard precisely contains a subset of asset records that can be independently computed and are independent of each other; for example, each shard may be set to contain 2000 or 5000 card records. After sharding, the system extracts the data set within each logical shard and extracts the prerequisite parameter variables necessary for financial depreciation calculations. These variables are collectively referred to as the computation context, which includes parameters such as the current accounting period, national macro tax rate parameters, and system environment variables. Subsequently, the system performs high-speed serialization operations on these asset data sets and computation contexts, encapsulating them into standard computation task messages conforming to specific communication protocol specifications, typically in JSON byte stream format.

[0027] Next, the system moves to S2, the task distribution step, a crucial step in decoupling the system and improving overall resilience. In this stage, the tens of thousands of standard computation task messages generated through the serialization process are rapidly pushed and published to a high-throughput message middleware deployed in the intranet environment. Mainstream high-concurrency stream processing platforms such as RabbitMQ, Apache Kafka, or RocketMQ can be selected. In this architecture, the message middleware plays a dual role as a high-speed data delivery pipeline and a resilient buffer. The message publishing process fully adopts an asynchronous non-blocking protocol, ensuring that the data extraction program can continuously supply tasks to the middleware using the system's maximum network bandwidth. Subsequently, the load balancing mechanism natively equipped in the message middleware comes into play. In the backend application service cluster, numerous independent asset service instances are deployed. These instances collectively register and form a large unified consumer group. Within this competitive consumption ecosystem, massive amounts of computation task messages are evenly and dynamically distributed to asset service instances that are currently idle or underloaded. Each asset service instance independently sends pull commands to the message middleware to retrieve computing task messages based entirely on the health indicators of its host physical machine or container, such as current CPU utilization and available memory space. This highly decoupled design ensures that no single server will bear a computing load exceeding its physical limits, perfectly achieving traffic smoothing for the surge in month-end closing data; at the same time, this also means that as long as more inexpensive computing resources are continuously invested in the cluster, the system can achieve theoretically unlimited concurrent task processing capabilities.

[0028] The system then enters the core S3 depreciation calculation step, which is the logic behind this technical solution's significant optimization of hardware performance and leap in efficiency. Once an asset service instance successfully consumes a calculation task message from the queue, it immediately performs deserialization within its configured Java Virtual Machine or other runtime memory space. The subsequent core processing completely blocks the expensive I / O operations of re-initiating network queries to the external database for each asset record; instead, it operates entirely within the instance's local high-speed memory. The asset service instance internally integrates a lightweight yet high-performance dynamic rule engine, such as a customized version of the QLExpress engine or the Drools framework. This rule engine possesses extremely powerful dynamic parsing capabilities. Upon receiving a calculation context containing hundreds or thousands of asset information entries, the rule engine immediately begins parsing the pre-configured text-formatted depreciation expressions in the financial system. At this point, the complex depreciation logic is transformed into computer instructions. The parameter assignment, conditional logic branch judgments, and high-precision floating-point arithmetic deductions all reside in the system's L1 / L2 cache and main memory, operating at extremely high speed. This completely memory-based closed-loop execution mode allows extremely complex financial statement calculations to complete a batch of data operations within milliseconds to tens of milliseconds—unthinkable in traditional architectures.

[0029] Finally, the S4 step, result aggregation, is executed to ensure the rigor and security of financial data. After the asset service instance uses the rule engine to calculate the current period depreciation amount, ending accumulated depreciation, impairment provision changes, and latest net asset value for all asset cards within the current logical shard in memory, these massive calculation results must be securely persisted. The instance organizes and merges the scattered results into a high-density result data packet and asynchronously writes it back to the distributed database using batch commit statements. However, in extremely complex distributed network environments, unstable factors such as network fragmentation, routing jitter, or momentary node disconnection are common. To ensure the absolute accuracy of financial accounting data, the system needs to update a dedicated task status record table for monitoring the lifecycle while writing back data. State transitions include: submitted -> in operation -> completed -> failed and awaiting retry. This solution rigorously integrates a state synchronization mechanism and a replay protection mechanism. Since the distributed database natively supports strict ACID transaction characteristics, this is highly suitable for scenarios with strong consistency requirements, such as bank transfers. The system pre-defines a task deduplication table in the database, or utilizes globally unique transaction identifiers carried by asset service instances during computation, such as combining unique transaction IDs generated by the PD Server to establish unique key constraints. In this way, even if the message broker mistakenly delivers the same task repeatedly to different asset service instances due to a lack of response, the underlying optimistic locking or version number verification mechanism of the distributed database can sensitively intercept and reject duplicate write requests, thus flawlessly guaranteeing the eventual consistency and strict idempotency of the entire batch processing computation.

[0030] One of the biggest pain points of traditional financial systems is their rigid calculation logic. Even minor changes to business rules require system redeployment, resulting in high maintenance costs. To completely overcome this problem, this embodiment details how an in-memory computing engine performs extremely fast and accurate depreciation calculations based on dynamic formula configuration.

[0031] In the initial stage of system implementation, a complete set of standard variables needs to be preset in the application configuration center. These variables will act as a bridge, connecting the underlying, dry database fields with human-readable financial rules. The table below structurally illustrates the typical variables mapped to the system context in this embodiment and their business meanings:

[0032] In conventional corporate fixed asset management, the straight-line method is the most widely used depreciation algorithm. Its core idea is to determine the latest adjusted accrual base for the asset and then amortize it evenly over the remaining useful months. This can be expressed in a rigorous financial mathematical formula as follows:

[0033] In the dynamic configuration interface of this application, the enterprise financial administrator does not need to write any code. They only need to concatenate the above logic into a text-formatted depreciation expression using built-in variables and save it. ((@beg_cost@+@debit_cost_accum@-@credit_cost_accum@-@salvage_value@)-(@beg_deprn_accum@+@credit_deprn_accum@-@debit_deprn_accum@+(@actual_deprn_accum@) +@doc_deprn@)-(@beg_impairment@+@credit_impairment_accum@-@debit_impairment_accum@-doc_impairment)) / (@deprn_month_total@-(@used_month@-1-@pause_month@)) Similarly, when dealing with heavy-duty assembly line machinery in a specific production workshop, where depreciation is calculated based on machine operating hours, or heavy-duty transport vehicles in a logistics company, where depreciation is calculated based on total vehicle mileage, the asset's value depreciation no longer exhibits a linear relationship with the mere passage of time. In this case, the rules engine will automatically match the workload-based expression configuration for that type of card. The corresponding mathematical logic is:

[0034] The corresponding system configuration string for this logic is simplified to: ((@beg_cost@+@debit_cost_accum@-@credit_cost_accum@-@salvage_value@) / @total_workload@)*@current_period_workload@ The underlying mechanism behind its ultra-fast in-memory computation lies in the high-performance dynamic parser configured in the rule engine. Upon first reading of these string configurations, the engine's built-in lexical and syntax analysis units are activated. It breaks down the lengthy, flat strings into underlying operators and operands, constructing a three-dimensional abstract syntax tree. Within this syntax tree, the computational priorities of addition, subtraction, multiplication, division, and nested parentheses are strictly fixed. When processing massive amounts of fragmented data, the system does not need to repeatedly parse strings. The engine uses the variable values ​​in the table above as actual parameters, precisely mapping and binding them to the leaf nodes of this abstract syntax tree already residing in the memory cache pool. Subsequently, the CPU instruction stream converges rapidly from bottom to top along the syntax tree structure. By reusing compiled instructions and caching techniques, highly accurate floating-point results can be output within microseconds, balancing business flexibility with extreme computational performance.

[0035] In financial-grade back-end applications, the ability to handle catastrophic consequences from hardware failures and network disruptions is a key indicator of system maturity. This solution establishes a comprehensive disaster recovery system at the architectural level.

[0036] First, physical isolation of fault domains is achieved. In traditional architectures, if the application layer crashes due to memory leaks, it is often accompanied by unreleased database deadlocks, leading to a complete shutdown of data center operations. In this solution, a clustered message middleware physically separates the data sharding and task generation module from the in-memory computing engine module. If several asset service instances experience a temporary freeze due to excessively high concurrency, the fault is firmly locked within the application layer, preventing it from propagating back through the network connection pool and polluting the underlying distributed database, thus avoiding a system-wide cascading failure.

[0037] Secondly, absolute non-volatility is guaranteed through delivery and acknowledgment protocols. When a computational task message containing sensitive financial data is delivered from the gateway to the message middleware, the middleware immediately performs a disk flush operation, persisting the message to the disk log. At this point, the task logically acquires the property of indestructibility. Only after an asset service instance has fully completed its entire lifecycle—from deserialization and in-memory rule parsing and calculation to successfully writing the depreciation results to the database—will the instance send a clear acknowledgment message to the middleware via the TCP channel. Only after the message queue receives the ACK will the task be permanently removed from the pending queue.

[0038] If an asset service instance experiences a physical power outage or forced process termination while processing a task, and the message middleware fails to receive an ACK message, the middleware's rescheduling mechanism intervenes after triggering a set timeout threshold. This immediately strips the failed instance of its access to the message and re-marks the computation task message as pending consumption. Subsequently, using a round-robin or weighted algorithm, the task is quickly moved and delivered to another healthy heartbeat node in the cluster for execution. To address poisonous messages caused by dirty data, such as division by zero or invalid fields, leading to continuous exceptions, this solution employs an exponential backoff retry mechanism. When the number of repeated failures of the same task reaches a preset maximum retry threshold, such as 5 retries, the system no longer endlessly consumes computing power. Instead, it removes the abnormal task, transfers it to a dedicated dead-letter queue, and triggers an alarm system to notify operations personnel for manual investigation.

[0039] Based on the above method, this embodiment constructs a practically deployable batch asset depreciation calculation system, which includes four highly collaborative core functional modules from top to bottom.

[0040] Data Sharding and Task Generation Module: This module is closely integrated with the underlying distributed database's data access gateway. Its responsibility is to request the partition topology status from the metadata node upon receiving a global bus command from the company's CFO to "execute month-end depreciation accrual." Using a consistent hashing algorithm or a pre-defined data slicing strategy, it quickly isolates independent data domains. Based on this, it extracts card data and environment status via high-speed parallel I / O streams, completing the encapsulation of thousands of task units within milliseconds.

[0041] The message scheduling and load balancing module is typically deployed independently on the core switch as a multi-node cluster. It doesn't concern itself with complex financial business logic, focusing instead on maintaining extremely high-throughput byte stream network transmission. It provides multi-channel Topic subscription and Queue routing management capabilities, utilizing scientific load balancing algorithms to transform sudden data surges at the front end into a smooth and controllable trickle, continuously delivering data to the backend computing node cluster. It is the absolute central hub for the entire system to handle transient peak loads.

[0042] The in-memory computing engine module, as a stateless core component in a distributed microservice cluster, is packaged and encapsulated within each lightweight asset service instance. It's not just a computing executor, but also a business rule base. In addition to the dynamic rule parsing and execution detailed above, this module also integrates various financial special case processing subroutines. Its operation requires no long-lived connections, fully utilizing the physical law that modern server memory bandwidth far exceeds disk bandwidth, making it the ultimate means of handling computationally intensive tasks.

[0043] Result Processing and State Management Module: This module serves as a bridge between the computation engine layer and the persistent storage layer, internally encapsulating a complex data access object layer and a distributed transaction coordinator. It is responsible for receiving raw financial statement data from various independent computation threads and submitting update instruction sets to the distributed database using a pre-compiled batch processing mode. Furthermore, it bears the heavy responsibility of maintaining the global task state machine, driving the steady progression of each small, segmented task from initialization to completion, and providing a final layer of protection against replay attacks in the event of abnormal network fluctuations.

[0044] Supported by this architecture, the system overturns the traditional processing approach, using the advanced concept of breaking down data and pushing it to computing power, perfectly solving many of the persistent problems of financial systems in the era of data explosion.

[0045] The computer devices mentioned in the embodiments of this application include hardware architectures such as multi-core processors, large-capacity high-speed memory, and network bus interfaces, as well as computer-readable storage media, including non-volatile media such as optical discs, flash memory, and solid-state drives, all of which have the complete ability to store and execute the instructions of the aforementioned software modules.

[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Any other modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention, as long as they do not depart from the spirit and scope of the technical solutions of the present invention, should be covered within the scope of the claims of the present invention.

Claims

1. A batch calculation method for asset depreciation based on distributed load balancing, characterized in that, Includes the following steps: S1 calls the distributed database to perform sharded queries, divides the full asset data into multiple logical shards according to the preset asset classification keywords, and encapsulates the asset data in each logical shard and its corresponding computing context into a standard format computing task message. S2 publishes the encapsulated computing task message to the message middleware. Through the load balancing mechanism of the message middleware, the computing task message is asynchronously distributed to multiple asset service instances that are in an idle state. S3, after the asset service instance consumes the computing task message, calls the rule engine in the memory of the asset service instance to dynamically parse the pre-configured depreciation expression, and performs calculations on the asset data in the computing task message according to the depreciation expression to obtain the depreciation result; S4 asynchronously writes the calculated depreciation result back to the distributed database and updates the task status record corresponding to the calculation task message. The state synchronization mechanism and the anti-replay mechanism are used to ensure the eventual consistency and idempotency of data processing.

2. The asset depreciation batch calculation method based on distributed load balancing according to claim 1, characterized in that: The preset asset classification keywords include asset identifier hash value, department number or legal entity code; the step of calling the distributed database to perform sharded query in S1 includes interacting with the metadata management module of the distributed database to obtain the real-time data distribution of each storage node and the overall topology of the cluster, and dividing the asset data table into data subsets with independent data boundaries based on the topology, with each data subset constituting a logical shard that can be independently computed.

3. The asset depreciation batch calculation method based on distributed load balancing according to claim 1, characterized in that: In step S2, where the encapsulated computing task message is published to the message middleware, an asynchronous non-blocking protocol is used for persistent message delivery. The load balancing mechanism adopts a competitive consumption model. Multiple asset service instances in the application layer cluster are configured as a unified consumer group, and each asset service instance independently pulls computing task messages according to its own processing capacity.

4. The asset depreciation batch calculation method based on distributed load balancing according to claim 1, characterized in that: The pre-configured depreciation expressions include the straight-line method expression and the unit-of-production method expression; the step in S3 of calling the rule engine to dynamically parse the pre-configured depreciation expressions in the memory of the asset service instance includes mapping and binding the state variables in the calculation context to the parameter nodes of the depreciation expressions, and performing floating-point arithmetic operations in memory by constructing an abstract syntax tree, avoiding read and write requests to external databases throughout the calculation process.

5. The asset depreciation batch calculation method based on distributed load balancing according to claim 1, characterized in that: The steps in S4 that utilize state synchronization and anti-replay mechanisms to ensure the eventual consistency and idempotency of data processing include setting up a task anti-duplicate table in the distributed database and using a globally unique transaction identifier to intercept repeatedly delivered computation task messages. When an exception occurs during the asynchronous write-back of depreciation results, the exponential backoff retry mechanism of the message middleware is triggered. If the maximum retry threshold is reached, the computation task message is transferred to the dead letter queue.

6. A batch asset depreciation calculation system based on distributed load balancing, comprising a data sharding and task generation module, a message scheduling and load balancing module, a memory computing engine module, and a result processing and status management module, characterized in that: The data sharding and task generation module calls the distributed database to perform sharding queries, divides the full asset data into multiple logical shards according to the preset asset classification keywords, and encapsulates the asset data in each logical shard and its corresponding computing context into a standard format computing task message. The message scheduling and load balancing module publishes the encapsulated computing task message to the message middleware, and asynchronously distributes the computing task message to multiple asset service instances that are in an idle state through the load balancing mechanism of the message middleware. After the asset service instance consumes the computing task message, the memory computing engine module calls the rule engine in the memory of the asset service instance to dynamically parse the pre-configured depreciation expression, and performs calculations on the asset data in the computing task message according to the depreciation expression to obtain the depreciation result. The result processing and status management module asynchronously writes the calculated depreciation results back to the distributed database and updates the task status record corresponding to the calculation task message. It uses a status synchronization mechanism and an anti-replay mechanism to ensure the eventual consistency and idempotency of data processing.

7. The asset depreciation batch calculation system based on distributed load balancing according to claim 6, characterized in that: The distributed database adopts a pure distributed architecture that separates computing and storage, including a structured query statement layer that receives client connections and generates distributed execution plans, storage nodes, and metadata management nodes responsible for the storage topology. The data sharding and task generation module generates computation task messages by sending query statements carrying sharding conditions to the structured query statement layer.

8. The asset depreciation batch calculation system based on distributed load balancing according to claim 6, characterized in that: The in-memory computing engine module is equipped with a high-performance dynamic parser, which includes a lexical analysis unit, a syntax analysis unit, and an instruction cache pool. This parser is used to reuse the abstract syntax tree execution plan of the successfully compiled depreciation expression when computing the full asset data.

9. A computer device, characterized in that, It includes at least one processor and at least one memory, wherein the memory stores computer instructions, and when the processor executes the computer instructions, it implements the asset depreciation batch calculation method based on distributed load balancing as described in any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that, It stores computer instructions, which, when executed by a processor, implement the batch calculation method for asset depreciation based on distributed load balancing as described in any one of claims 1 to 5.

Images