Data service-oriented dynamic charging rule engine implementation method and system

Abstract

The invention relates to the technical field of computer data processing, in particular to a data service-oriented dynamic charging rule engine implementation method and system, and the method comprises the following steps: S1, constructing an orthogonalization charging factor vector space which comprises a static stateless dimension set and a dynamic stateful dimension set, establishing a context mapping table for storing the current value of each dimension in the dynamic stateful dimension set; and S2, receiving original charging data through a preset projection operator, mapping the original charging data into a projection vector on the static stateless dimension set, reading a state value in the context mapping table to generate a state vector, and splicing the projection vector and the state vector to construct a complete input vector. According to the method, network delay and lock competition caused by frequent reading and writing of an external database or a cache when stateful logic such as step pricing is processed in a traditional method are avoided, and stream-oriented computing performance of a pure memory level is achieved.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to a method and system for implementing a dynamic billing rule engine for data services. Background Technology

[0002] With the rapid development of cloud computing, the Internet of Things, and the digital economy, business billing scenarios are becoming increasingly complex, placing extremely high demands on the real-time performance and throughput of billing systems. In the business architectures of telecom operators, cloud service providers, and large SaaS platforms, dynamic billing rule engines undertake core data processing tasks, requiring real-time cost calculation, credit deduction, and access control for massive user resource usage requests.

[0003] Existing mainstream billing system architectures typically employ a design pattern that separates computation and storage. In this pattern, the billing rule engine primarily handles stateless logical operations, while stateful data such as user account balance, monthly cumulative usage, and discount tiers are stored in external relational databases or distributed caching middleware. When the system processes a billing request, the rule engine first queries and reads the user's current state data from the external storage system via a network interface. It then performs logical calculations based on the original data from the request, and subsequently writes the newly generated state data back to the external storage system via the network interface for persistent updates.

[0004] This traditional processing flow has significant technical drawbacks. First, each billing request requires at least two cross-network I / O operations. The physical latency of network communication becomes a hard bottleneck for system response speed, resulting in response times for a single request typically in the tens or even hundreds of milliseconds, making it difficult to meet the millisecond-level real-time control requirements of industrial internet or high-frequency trading scenarios. Second, in high-concurrency business scenarios, to ensure the consistency of state data and prevent data errors caused by multi-threaded concurrent read / write operations, external storage systems usually need to employ row-level locks or distributed lock mechanisms. This lock contention mechanism can lead to severe thread blocking and resource contention under high load, causing the overall system throughput to decrease non-linearly with increasing concurrency, making it difficult to linearly improve processing capacity through simple horizontal scaling. Furthermore, frequent disk read / write operations also place a huge load on the underlying hardware infrastructure, increasing system maintenance costs and instability. Summary of the Invention

[0005] To overcome the above shortcomings, this invention provides a method and system for implementing a dynamic billing rule engine for data services. It aims to improve the existing billing system's network I / O bottlenecks and lock contention caused by frequent interactions with external storage, resulting in high response latency and low throughput under high concurrency, which fails to meet real-time business requirements.

[0006] Firstly, this invention provides the following technical solution: a method for implementing a dynamic billing rule engine for data services. This method constructs an orthogonalized billing factor vector space and combines it with a JIT microkernel execution environment to achieve streaming computation and status feedback of billing logic. The method includes the following steps:

[0007] Construct an orthogonalized billing factor vector space, wherein the vector space is 3D space Define the basis vector set The basis vector set is divided into a static, stateless dimension set. With dynamic stateful dimension sets The system establishes and maintains a memory-resident context mapping table. It is used to store the current value corresponding to each dimension in the dynamic stateful dimension set.

[0008] By using a preset projection operator Receive raw billing data The fields in the original billing data are parsed and mapped to the coordinate axes corresponding to the static stateless dimension set to generate a projection vector. Simultaneously, the system reads the context mapping table. The numerical values ​​are converted into state vectors according to a predetermined order. The system performs a vector concatenation operation, merging the projection vectors with the state vectors to construct a complete input vector. The input vector satisfies the following relation: ,in This indicates a vector concatenation operation.

[0009] The constructed input vector The input vector is passed to a JIT microkernel. The JIT microkernel loads a pre-compiled virtual billing instruction set and performs pure memory computation on the input vector. The virtual billing instruction set is a sequence of binary instructions compiled from a billing rule set. During the compilation phase, the billing rules are mapped to a vector space. Hyperplane or multicellular region The billing logic is transformed into a geometric operation to determine whether the coordinates of the input vector fall within the polytope region. The compiler calculates the memory offset of each billing factor in the input vector and hardcodes the references to the billing factors in the rules into offset-based memory load instructions.

[0010] When the JIT microkernel executes the computation-triggered state change logic, it generates a dimension injection descriptor. The data structure of the dimension injection descriptor is as follows: ,in Identify tenants, Index for the target dimension, This is the calculated new state value. The JIT microkernel feeds back the dimension-injected descriptor to the data acquisition layer.

[0011] The data acquisition layer receives the dimension injection descriptor and updates the context mapping table in real time based on the descriptor. Perform update operation The updated context map is used to construct the input vector for the next time step, allowing the state values ​​to participate in subsequent calculations as dimensions of the input data, thus achieving state-driven dynamic dimension injection.

[0012] Furthermore, the method also includes a double-buffered atomic hot update step: when the rule changes, a new shadow instruction space and a new dimension mapping configuration are constructed in the background memory area; after the new rule is compiled and initialized, an atomic pointer switch is performed using CPU primitives to switch the data flow entry from the currently active JIT microkernel instance to the new JIT microkernel instance; during the switching process, the non-expired context mapping table data in the old instance is migrated and aligned to the projection operator of the new instance.

[0013] Secondly, this invention provides the following technical solution: a dynamic billing rule engine implementation system for data services, comprising:

[0014] The vector space construction and projection module is configured to construct an orthogonalized billing factor vector space containing static stateless dimensions and dynamic stateful dimensions, and maintain a context mapping table. This module includes a projection operator, which receives raw billing data and maps it to a projected vector, reads the context mapping table to generate a state vector, and concatenates the projected vector and the state vector to form a complete input vector.

[0015] The JIT microkernel execution module is configured to load the compiled virtual billing instruction set and receive the input vector. This module performs pure in-memory logical calculations on the input vector without external storage I / O by executing load, compare, calculate, and inject instructions, and outputs billing data based on the calculation results.

[0016] The state feedback closed-loop module is configured to connect the JIT microkernel execution module and the vector space construction and projection module. This module receives the dimension injection descriptor generated by the JIT microkernel execution module during the calculation process, updates the context mapping table in the vector space construction and projection module according to the descriptor, and feeds back the state changes generated by the calculation as the dimension values ​​of the input vector at the next time step.

[0017] The present invention has the following beneficial effects:

[0018] 1. In this invention, by constructing an orthogonalized billing factor vector space and combining it with a state-driven dynamic dimension injection mechanism, the external I / O dependency in state billing calculation is eliminated. The calculated state is fed back in real time using a context mapping table and concatenated into the dimension of the input vector. This ensures that all the data required by the JIT microkernel during execution exists in the continuous memory address of the input vector, thereby avoiding the network latency and lock contention caused by frequent reading and writing to external databases or caches when processing state logic such as tiered pricing in traditional methods. This achieves pure memory-level streaming computing performance.

[0019] 2. In this invention, by adopting a JIT microkernel execution module based on geometric region determination, the invention improves the matching and execution efficiency of complex rule sets, compiles billing rules into hyperplanes or multicellular regions in vector space, and hardcodes variable references into memory offset instructions, so that the rule matching process is transformed into coordinate-based geometric operations, avoiding the computational overhead of symbol lookup, reflection calls, or traversing a huge rule tree during runtime in traditional rule engines, and reducing the consumption of CPU instruction cycles.

[0020] 3. In this invention, by implementing a double-buffered atomic hot update and context state migration mechanism, service continuity and data consistency are ensured during the billing rule change process. By utilizing shadow instruction space and CPU primitive-level pointer switching, atomic replacement of old and new rule logic is achieved. Combined with the alignment and migration of state data, this solves the problem of service interruption caused by the need for system shutdown or restart when reloading rules in traditional systems, as well as the problem of billing state loss or corruption that may occur during the instantaneous switching between old and new rules. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the implementation method of the dynamic billing rule engine for data services proposed in this invention.

[0022] Figure 2 This is a schematic diagram of the framework of the dynamic billing rule engine implementation system for data services proposed in this invention. Detailed Implementation

[0023] The technical solutions in 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 some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Example 1

[0025] In a first embodiment of the present invention, the present invention provides a method for implementing a dynamic billing rule engine for data services, such as... Figure 1 As shown, it includes the following steps:

[0026] Step S1: Construct an orthogonalized billing factor vector space. The vector space contains a static set of stateless dimensions and a dynamic set of stateful dimensions. Establish a context mapping table to store the current values ​​of each dimension in the dynamic set of stateful dimensions.

[0027] The dimensions in the orthogonalized billing factor vector space support dynamic expansion;

[0028] When a new billing factor is added to the business, a new coordinate axis is added to the vector space, and the configuration of the projection operator is updated to establish a mapping relationship between the original data fields and the new coordinate axis, without modifying the underlying data storage structure.

[0029] Specifically, in this step, a first initialization is performed in the computer memory. A linear space is used as the orthogonalized billing factor vector space. This vector space is composed of... The system consists of several mutually orthogonal basis vectors, each uniquely representing an independent billing factor. Each billing request or calculation object processed by the system is digitally represented as a coordinate point in this vector space, i.e., a column vector. This column vector Include Each of the following numerical components corresponds to a specific value in a particular billing factor dimension.

[0030] This method will use vector space Each dimension is divided into two logical subsets, each assigned a fixed index range. The first subset is a static, stateless set of dimensions, occupying the initial index range, for example, from 0 to... -1. This type of dimension is used to map physical metrics directly derived from the raw input data, including physical quantities such as the number of CPU cores, memory size, or service duration. The value of this type of dimension is entirely determined by the raw data from the external input during the processing of a single billing request, and does not depend on the historical operating status of the system.

[0031] The second subset is a dynamic set of stateful dimensions, which occupies the subsequent index range, for example, from... Up to N−1. This type of dimension is used to map intermediate or cumulative states generated by the system through calculations, including logical quantities such as the cumulative number of calls in the current month or the current discount level. The values ​​of this type of dimension are maintained internally by the system and change as business operations and rules are triggered.

[0032] The system allocates and maintains an independent context mapping table in memory for each tenant or billing object. This context mapping table is used to persistently store the current values ​​corresponding to each dimension in a dynamically stateful set of dimensions. In the specific implementation, the context mapping table is stored using a compact array structure or a hash table structure. Taking the array structure as an example, this mapping table is represented as a table of length... reduce A floating-point array, the index of the array Corresponding to the global dimension index in the vector space add During system initialization or the initial state of a new tenant's access, all elements in the context mapping table are initialized to zero or a preset default value.

[0033] In addition, the system maintains a global dimension configuration table in memory to record the name, data type, global index position, and default value of each dimension. When business requirements change and new billing factors need to be added, the system adds a new entry to the dimension configuration table and adjusts the total number of dimensions in the vector space. Add one. If the newly added dimension belongs to a dynamic, stateful set of dimensions, the system triggers a memory expansion operation on the context mapping tables of all active tenants, allocating storage space for the new dimension index and initializing it. This process is completed entirely at the in-memory data structure level and does not involve changes to the underlying database table structure.

[0034] Step S2: Receive the original billing data through the preset projection operator, map it to the projection vector on the static stateless dimension set, and read the state value in the context mapping table to generate the state vector. Concatenate the projection vector and the state vector to construct the complete input vector.

[0035] Furthermore, the specific method for constructing the complete input vector in step S2 is as follows:

[0036] S21. Define a projection operator to map heterogeneous raw billing data onto the static, stateless dimension coordinate axis of the orthogonalized billing factor vector space, and automatically fill in default values ​​for missing dimensions.

[0037] S22. Define a vectorization operation to convert the state values ​​of each dimension stored in the context mapping table into a state vector in a predetermined order.

[0038] S23. Perform a vector concatenation operation, taking the projection vector as the low-dimensional part and the state vector as the high-dimensional part, and merge them to generate an input vector, so that all the data sources required for subsequent calculations exist in the memory address of the input vector.

[0039] Specifically, in this step, the system uses a vector space construction and projection module to receive, parse, and vectorize data. This module has built-in projection operators for different data source formats. When the system receives raw billing data from an external source, the projection operator first parses the raw data. Raw billing data typically exists in the form of JSON objects, log strings, or key-value pairs, containing multiple fields. The projection operator identifies the fields in the raw data corresponding to the static stateless dimension set according to preset mapping rules, extracts the values ​​of these fields, and fills them into the corresponding index positions of a temporary vector. For example, if the raw data contains "cpu_cores":4, and the dimension index corresponding to "CPU cores" is 0, the projection operator fills the value 4 into the 0th position of the temporary vector. For fields that exist in the static stateless dimension set but are missing in the raw data, the projection operator automatically fills in the default value of that dimension, thereby generating a projection vector.

[0040] Simultaneously, based on the tenant identifier or object identifier carried in the original billing data, the system retrieves the context mapping table corresponding to the tenant from memory. The system reads all current values ​​of dynamic, stateful dimensions stored in the context mapping table and arranges these values ​​in the order of their indices in the vector space to generate a state vector. This state vector reflects historical information such as the tenant's cumulative usage, credit rating, or preferential status at the current moment.

[0041] Subsequently, the system performs a vector concatenation operation, merging the projection vector and the state vector into a complete input vector. Specifically, the projection vector occupies the low-dimensional index portion of the input vector, i.e., from 0 to... -1; the state vector occupies the high-dimensional index portion of the input vector, i.e. to -1. Through this concatenation operation, the system merges the current request's instantaneous physical data with the tenant's historical state data into the same contiguous block of memory. The constructed input vector... It contains all the variables required for subsequent billing rule calculations, so that no further external data reading or querying operations are needed in the subsequent calculation process.

[0042] Step S3: Pass the constructed input vector into the JIT microkernel. The JIT microkernel performs pure memory computation on the input vector based on the pre-compiled virtual billing instruction set.

[0043] Furthermore, the virtual billing instruction set used in step S3 is a binary instruction sequence generated by compiling the billing rule set;

[0044] During the compilation phase, the compiler calculates the memory offset of each billing factor in the input vector and hardcodes the references to the billing factors in the rules directly into offset-based memory load instructions. The memory load instructions do not perform symbol lookup operations at runtime.

[0045] The virtual billing instruction set includes dimension injection instructions;

[0046] When a dimension injection instruction is executed, it does not directly modify the external database. Instead, it constructs a dimension injection descriptor. The data structure of the dimension injection descriptor includes at least: the target tenant identifier, the target dimension index corresponding to the dynamic stateful dimension set, and the calculated new state value.

[0047] In step S3, the logic for the JIT microkernel to perform calculations is based on geometric region determination;

[0048] The billing rules are compiled and mapped to hyperplanes or multicellular regions in the orthogonalized billing factor vector space;

[0049] The JIT microkernel determines the applicable billing function by calculating the coordinates of the input vector in the vector space and identifying the rule-based multi-cell region it falls into, without traversing the rule tree.

[0050] The opcodes of the virtual billing instruction set must include at least:

[0051] The load instruction is used to read a value from a specified offset of the input vector into a register;

[0052] Comparison instructions are used to compare register values ​​with threshold values.

[0053] Calculation instructions are used to execute arithmetic billing logic;

[0054] Injection instructions are used to trigger the generation of dimension injection descriptors.

[0055] Specifically, in this step, the constructed input vector will be... The code is passed to the JIT microkernel execution module. This module runs in a separate memory space and pre-loads a virtual billing instruction set compiled from the billing rule set. Unlike interpreted rule engines that parse rule text line by line, the virtual billing instruction set in this step is a binary instruction sequence containing opcodes for loading, comparing, calculating, jumping, and injecting.

[0056] During instruction execution, the JIT microkernel treats the logical judgments of billing rules as geometric region determinations within a vector space. The triggering condition for each billing rule is pre-compiled as a hyperplane or polytope region in the vector space. The microkernel calculates the input vector by executing instructions. The coordinates of a point relative to these hyperplanes are used to quickly determine whether a vector falls within a specific rule area. For example, by calculating the vector dot product or distance formula, it can be determined whether the current request meets specific tiered pricing ranges or combined discount conditions.

[0057] To achieve relatively high execution efficiency, the compiler calculates all billing factors in the input vector during the compilation phase. The memory offset is used for reference. Therefore, variable references in the virtual billing instruction set are all hard-coded as direct memory access instructions based on the base address and offset. When the microkernel needs to retrieve the value of a billing factor, such as "cumulative number of calls in the current month," it no longer looks up the variable by string name, but directly uses the offset parameter in the instruction to retrieve the value from the input vector. The value is read from the corresponding memory address and loaded into the register.

[0058] The microkernel performs pure in-memory arithmetic and logical operations on the input vector according to the logical order of the instruction sequence, ultimately calculating the billing result for this request. If the calculation logic involves state changes, the microkernel does not directly initiate write operations to external storage, but instead generates corresponding dimension injection descriptors for subsequent feedback processes. The entire calculation process is completed entirely in the CPU's L1 or L2 cache, avoiding the overhead of I / O waits and context switching.

[0059] Step S4: When the JIT microkernel executes the calculation-triggered state change logic, it generates a dimension injection descriptor containing the target dimension index and the new state value, and feeds the dimension injection descriptor back to the data acquisition layer.

[0060] Specifically, in this step, when the JIT microkernel triggers state change logic during the execution of the virtual billing instruction set, the system does not immediately modify any persistently stored data. Instead, it expresses this state change by generating an intermediate descriptor object. Specifically, when a state update instruction in the instruction set is executed, such as when the cumulative call count needs to be increased or the user level needs to be promoted, the microkernel instantiates a dimension injection descriptor in memory.

[0061] The dimension injection descriptor is a structured data object that encapsulates the three essential elements required to define a state change: the target tenant identifier, the target dimension index, and the new state value. The target tenant identifier specifies the billing object to which the state change belongs; the target dimension index is an integer value that directly points to the specific coordinate axis of the dynamically stateful set of dimensions in the orthogonalized billing factor vector space, such as the dimension index representing "cumulative charges for the current month"; and the new state value is the latest numerical result calculated by the microkernel's arithmetic logic unit.

[0062] After generating the dimension injection descriptor, the JIT microkernel places it into a dedicated high-speed feedback channel. This feedback channel connects the microkernel execution environment and the data acquisition layer, typically implemented as a lock-free memory circular buffer or a high-performance message queue. The microkernel is only responsible for writing the descriptor into the channel and then immediately continues processing the next input vector without waiting for the state update to complete. This asynchronous feedback mechanism decouples the complex computational logic from the state maintenance logic, ensuring the high throughput of the microkernel computational pipeline. The dimension injection descriptor, as the sole carrier for the computational layer to convey the intention of state changes to the acquisition layer, ensures that the flow of state data is clear and controllable.

[0063] Step S5: The data acquisition layer updates the context mapping table in real time according to the dimension injection descriptor, so that the input vector constructed in the next moment contains the updated state value, thereby realizing state-driven dynamic dimension injection.

[0064] Furthermore, the process of updating the context mapping table in step S5 is lock-free and asynchronous;

[0065] The context mapping table resides in the memory of the data acquisition layer; the dimension injection descriptor is sent through the feedback channel, and only corrects the context mapping table entries corresponding to that specific tenant.

[0066] For raw billing data that arrives before the update is complete, continue to use the old context mapping table to construct the input vector.

[0067] Specifically, in this step, the data acquisition layer acts as the receiver of status feedback, monitoring the high-speed feedback channel in real time. When a new dimension injection descriptor is detected, the acquisition layer immediately parses the contents of the descriptor, extracting the target tenant identifier, the target dimension index, and the new status value.

[0068] Based on the parsed tenant identifier, the data acquisition layer quickly locates the corresponding context mapping table for that tenant in memory. Subsequently, the system performs an update operation, directly using the target dimension index in the descriptor as the array index or hash key to replace the old value at the corresponding position in the mapping table with the new state value carried in the descriptor. For example, the value of the dimension "cumulative call count for the current month" in the mapping table is updated from 100 to 101. This update operation is completed instantaneously in memory, ensuring that the context mapping table always holds the latest state snapshot of the tenant.

[0069] The updated context mapping table takes effect immediately and is ready to process the tenant's next billing request. When the next piece of raw billing data arrives and enters step S2, the vector space construction and projection module, while reading the context mapping table, will obtain the newly updated value and concatenate it into the new input vector. In this way, the calculation result of the previous moment is transformed into the input parameters for the calculation of the next moment, forming a closed loop of calculation, feedback, and injection steps. This allows the system to automatically and dynamically inject the latest state information into the calculation process when processing continuous data streams, thereby realizing complex stateful billing logic without relying on an external database for intermediate state transmission.

[0070] It also includes a double-buffered atomic thermal update step:

[0071] When rules change, a new shadow instruction space and a new dimension mapping configuration are built in the background memory area;

[0072] Once the new rule is compiled and initialized, an atomic pointer switch is performed using CPU primitives to switch the data flow entry from the currently active JIT microkernel instance to the new JIT microkernel instance.

[0073] During the switchover, the non-expired context mapping table data in the old instance is migrated and aligned to the projection operator of the new instance.

[0074] Specifically, this embodiment further describes the seamless hot update mechanism when billing rules are changed during system operation. This mechanism adopts a double-buffered architecture to ensure that billing services are not interrupted, data is not lost, and the state remains consistent when rules are upgraded or adjusted.

[0075] First, upon receiving a request to publish a new billing rule, the system does not directly modify the currently serving JIT microkernel instance. Instead, it allocates an independent shadow instruction space in the background memory area. Within this shadow space, the system initiates a compilation process based on the new rule set, generating a new virtual billing instruction set and simultaneously constructing a new dimension mapping configuration that matches the new rule. If the new rule introduces a new billing factor or adjusts the dimension definition, the system will also initialize a corresponding new context structure in the shadow space. At this time, the currently active JIT microkernel instance continues to process incoming data normally, unaffected by the background build process.

[0076] Once the new rules in the shadow instruction space have been compiled and initialized successfully (self-test passed), the system enters the switching phase. This phase utilizes the compare-and-swap atomic operation instructions provided by the CPU to perform a global pointer switch. Specifically, the system maintains a global atomic pointer pointing to the currently active microkernel instance. Through a single CPU primitive instruction, the system instantly modifies the value of this pointer from the address of the old instance to the address of the new instance. Due to the indivisibility of atomic operations, all new billing requests arriving after this point will be immediately routed to the new JIT microkernel instance for processing via the new pointer, while the old instance only needs to process the small number of remaining requests already in the pipeline.

[0077] Simultaneously with the pointer switch, the system initiates a state migration and alignment process. Since the old and new rules may involve the addition, deletion, or modification of dimensions, the system needs to migrate the context mapping table data maintained in the old instance to the new instance. For unchanged dimensions, the system directly performs a memory block copy; for newly added dimensions, the system initializes them with default values; for removed dimensions, the system discards the relevant data. To ensure data consistency, during the migration process, the system acquires spinlocks on the specific tenant contexts involved and completes the data migration and alignment within microseconds, then releases the locks. After the migration is complete, the old microkernel instance and its memory space are marked as reclaimable, and the system releases the resources after all old requests have been processed, thus completing the entire hot update process.

[0078] Example 2:

[0079] In high-concurrency billing scenarios for cloud computing resources, traditional billing systems rely on external databases or distributed caches to store and retrieve user status data such as accumulated usage and credit limits. In high-throughput environments handling tens of thousands of requests per second, frequent network I / O operations and database lock contention result in system response latency exceeding 100 milliseconds, failing to meet the requirements for real-time billing and control. To address these issues, this invention provides a dynamic billing rule engine implementation system for data services, with the following structure: Figure 2 As shown. The specific implementation process of this system is as follows:

[0080] This system runs in the memory space of a computer device and mainly includes a vector space construction and projection module, a JIT microkernel execution module, and a state feedback closed-loop module. The modules interact with each other via a memory bus or a high-speed shared memory region, forming a closed-loop processing architecture without external I / O dependencies.

[0081] First, the vector space construction and projection module, serving as the entry point for data inflow, is configured with a dimension definition unit and a context storage unit. The dimension definition unit divides memory into a static stateless dimension region and a dynamic stateful dimension region, corresponding to the original data fields and the system's internal state, respectively. The context storage unit maintains a context mapping table for each tenant using contiguous memory address blocks. When the original billing data arrives, the projection operator within this module parses the data packet, extracts the physical index values ​​to fill the static dimension region, and directly reads the current state values ​​from the context storage unit to fill the dynamic dimension region. A memory copy operation then concatenates the two into an input vector conforming to a predefined format.

[0082] Secondly, the JIT microkernel execution module is connected to the vector space construction and projection module, receiving the constructed input vector. This module is an independently running computation engine, loaded with a binary virtual billing instruction set generated by the compiler. This module does not contain any read / write interfaces for external storage devices, only instructions for loading memory data, performing arithmetic operations, logical comparisons, and bit manipulations. During execution, this module treats the input vector as a coordinate point in a multi-dimensional geometric space, determining the positional relationship between this coordinate point and the hyperplane region defined by pre-defined billing rules through the executed instructions. The calculated billing results are directly output to the downstream settlement system, while the calculated state change data is encapsulated as a dimension injection descriptor.

[0083] Finally, the state feedback closed-loop module connects the output of the JIT microkernel execution module to the storage of the vector space construction and projection module. This module is configured with a feedback channel based on a memory circular buffer and a state update controller. The dimension injection descriptor generated by the JIT microkernel is written to the feedback channel. The state update controller reads the descriptor from the channel and parses the target tenant identifier, target dimension index, and new state value. Subsequently, the state update controller directly locates the corresponding address of the context storage unit in the vector space construction and projection module through memory addressing and overwrites the old state value with the new state value.

[0084] Through the collaborative work of the above modules, the system transforms the traditional database read, calculation, and write processes into a pure in-memory vector construction, geometric calculation, and state injection loop, eliminating network communication and disk I / O overhead and ensuring that the system processing latency remains stable within milliseconds even when state data changes frequently.

[0085] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for implementing a dynamic billing rule engine for data services, characterized in that, Includes the following steps: Step S1: Construct an orthogonalized billing factor vector space, which includes a static stateless dimension set and a dynamic stateful dimension set, and establish a context mapping table for storing the current values ​​of each dimension in the dynamic stateful dimension set. Step S2: Receive the original billing data through the preset projection operator, map it to the projection vector on the static stateless dimension set, and read the state value in the context mapping table to generate a state vector. Concatenate the projection vector with the state vector to construct a complete input vector. Step S3: The constructed input vector is passed into the JIT microkernel, which performs pure memory computation on the input vector based on a pre-compiled virtual billing instruction set; Step S4: When the JIT microkernel executes the calculation-triggered state change logic, it generates a dimension injection descriptor containing the target dimension index and the new state value, and feeds the dimension injection descriptor back to the data acquisition layer. Step S5: The data acquisition layer updates the context mapping table in real time according to the dimension injection descriptor, so that the input vector constructed in the next moment contains the updated state value, thereby realizing state-driven dynamic dimension injection.

2. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, The specific method for constructing the complete input vector in step S2 is as follows: S21. Define a projection operator to map the heterogeneous original billing data onto the static stateless dimension coordinate axis of the orthogonalized billing factor vector space, and automatically fill in the default value for missing dimensions. S22. Define a vectorization operation to convert the state values ​​of each dimension stored in the context mapping table into state vectors in a predetermined order. S23. Perform a vector concatenation operation, taking the projection vector as the low-dimensional part and the state vector as the high-dimensional part, and merge them to generate the input vector, so that all data sources required for subsequent calculations exist in the memory address of the input vector.

3. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, The virtual billing instruction set used in step S3 is a binary instruction sequence generated by compiling a billing rule set. During the compilation phase, the compiler calculates the memory offset of each billing factor in the input vector and hardcodes the references to the billing factors in the rules directly into offset-based memory load instructions, which do not perform symbol lookup operations at runtime.

4. The method for implementing a dynamic billing rule engine for data services according to claim 3, characterized in that, The virtual billing instruction set includes dimension injection instructions; When the dimension injection instruction is executed, it does not directly modify the external database, but instead constructs the dimension injection descriptor. The data structure of the dimension injection descriptor includes at least: the target tenant identifier, the target dimension index corresponding to the dynamic stateful dimension set, and the calculated new state value.

5. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, In step S3, the logic for the JIT microkernel to perform calculations is based on geometric region determination. The billing rules are compiled and mapped to hyperplanes or multicellular regions in the orthogonalized billing factor vector space; The JIT microkernel calculates the coordinates of the input vector in the vector space, determines the rule-based multi-cell region into which it falls, and thus determines the applicable billing function without traversing the rule tree.

6. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, The process of updating the context mapping table in step S5 is lock-free and asynchronous; The context mapping table resides in the memory of the data acquisition layer; the dimension injection descriptor is sent through the feedback channel and only corrects the context mapping table entries corresponding to the specific tenant. For raw billing data that arrives before the update is complete, continue to use the old context mapping table to construct the input vector.

7. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, It also includes a double-buffered atomic thermal update step: When rules change, a new shadow instruction space and a new dimension mapping configuration are built in the background memory area; Once the new rule is compiled and initialized, an atomic pointer switch is performed using CPU primitives to switch the data flow entry from the currently active JIT microkernel instance to the new JIT microkernel instance. During the switchover, the non-expired context mapping table data in the old instance is migrated and aligned to the projection operator of the new instance.

8. The method for implementing a dynamic billing rule engine for data services according to claim 3, characterized in that, The opcodes of the virtual billing instruction set include at least: A load instruction is used to read a value from the input vector at a specified offset into a register; Comparison instructions are used to compare register values ​​with threshold values. Calculation instructions are used to execute arithmetic billing logic; The injection instruction is used to trigger the generation of the dimension injection descriptor.

9. The method for implementing a dynamic billing rule engine for data services according to claim 1, characterized in that, The dimensions in the orthogonalized billing factor vector space support dynamic expansion; When a new billing factor is added to the service, a new coordinate axis is added to the vector space, and the configuration of the projection operator is updated to establish a mapping relationship between the original data fields and the new coordinate axis, without modifying the underlying data storage structure.

10. A dynamic billing rule engine implementation system for data services, characterized in that: The system for implementing a dynamic billing rule engine for data services according to any one of claims 1-9, the system comprising: The vector space construction and projection module is used to construct an orthogonalized billing factor vector space containing static stateless dimensions and dynamic stateful dimensions, maintain a context mapping table, and concatenate the original billing data and the context mapping table data into an input vector. The JIT microkernel execution module is used to load the compiled virtual billing instruction set and perform pure memory logic calculations on the input vector without I / O. The state feedback closed-loop module is used to receive the dimension injection descriptor generated during the execution of the JIT microkernel, and update the context mapping table in the vector space construction and projection module accordingly, so as to realize the dynamic injection of the calculation state into the input dimension.

Images