A method, system, device and storage medium for uniform charging of digital resources

Abstract

A unified charging method, system, device and storage medium for digital resources relate to the technical field of digital resource charging. A plurality of event consumption data describing resource consumption is obtained from a multi-modal resource adaptation layer, and the plurality of event consumption data is aggregated into single heterogeneous metering data based on a preset aggregation strategy. The original consumption value in the heterogeneous metering data is converted into a standardized metering index and a standardized value corresponding to the standardized metering index, thereby obtaining normalized metering data. The normalized metering data is processed by a multi-stage pipeline charging engine to generate a discounted charging item. The discounted charging item is processed in the account processing stage of the multi-stage pipeline charging engine, the account information is processed according to the final fee after discount, a transaction flow record recording the current fee expenditure is generated, and the transaction flow record is stored in the account database. The implementation of the technical solution provided reduces the database write pressure.

Description

Technical Field

[0001] This application relates to the field of digital resource billing technology, specifically to a unified billing method, system, device, and storage medium for digital resources. Background Technology

[0002] With the rapid development of cloud computing, big data, and artificial intelligence technologies, the digital economy has become a core engine of global economic growth. Businesses and individuals are increasingly demanding digital resources such as computing, storage, networks, and various APIs, and the forms and usage patterns of these resources are becoming more diverse and complex than ever before.

[0003] Existing automated billing systems typically consist of separate metering and billing modules. The metering module is responsible for periodically collecting usage logs or metric data from various resources and aggregating this raw data. The billing module, on the other hand, initiates batch processing tasks at fixed time intervals (such as hourly or daily) to retrieve the aggregated metering data, calculates fees according to a pre-set price list, and finally generates a bill and deducts payment from the user's account.

[0004] However, the existing technical architecture based on fixed-cycle batch processing is limited and lacks flexibility in handling the diverse digital resource consumption scenarios we face today. This architecture presents a significant challenge, especially for scenarios generating high-frequency, low-value events such as API calls, Content Delivery Network (CDN) traffic, and serverless computing. Performing complete billing and accounting processing for every single raw consumption event would generate massive database write and computation requests, easily impacting the performance bottleneck of the billing system and potentially causing system crashes. Summary of the Invention

[0005] This application provides a unified billing method, system, device, and storage medium for digital resources. This method solves the system performance bottleneck problem in the face of high-frequency, low-value consumption events in the prior art and reduces the database write pressure.

[0006] Firstly, this application provides a unified billing method for digital resources. The method includes: obtaining multiple event consumption data describing resource consumption from a multimodal resource adaptation layer; aggregating the multiple event consumption data into a single heterogeneous metering data based on a preset aggregation strategy; identifying the resource types contained in the heterogeneous metering data; querying preset resource indicator mapping rules according to the resource types; converting the original consumption values ​​in the heterogeneous metering data into standardized metering indicators and standardized values ​​corresponding to the standardized metering indicators according to the obtained preset resource indicator mapping rules, thereby generating normalized metering data containing tenant information, standardized metering indicators, and standardized values; obtaining the user status corresponding to the tenant information; and... The status includes at least the pricing plan, discount rules, and account information. The normalized metering data is processed by a multi-level pipeline billing engine. Based on the pricing plan and standardized metering indicators, the standardized values ​​are converted into pre-discount costs, resulting in approved billing items. These approved billing items are then processed in the discount processing stage of the multi-level pipeline billing engine. Based on the discount rules, the pre-discount costs are processed to obtain the final discounted cost, generating discounted billing items. Finally, these discounted billing items are processed in the accounting stage of the multi-level pipeline billing engine. Based on the final discounted cost, the account information is accounted for, generating a transaction record recording this expense, which is then stored in the accounting database.

[0007] By adopting the above technical solution, event consumption data is acquired at the multimodal resource adaptation layer, and a preset aggregation strategy is used to aggregate the event consumption data into heterogeneous metering data, effectively solving the system performance bottleneck problem in the face of high-frequency, low-value consumption events in existing technologies. By identifying the resource types in the heterogeneous metering data and applying preset resource indicator mapping rules, the original consumption values ​​are converted into standardized metering indicators and standardized values, thereby generating normalized metering data and realizing unified processing of different types of digital resources. After obtaining the user status corresponding to the tenant, a multi-level pipeline billing engine is used to sequentially perform batch pricing, discount processing, and accounting processing, converting the standardized values ​​into pre-discount fees, then obtaining the final post-discount fees, and finally completing the accounting processing and generating transaction records stored in the accounting database. This breaks through the limitations of the traditional fixed-cycle batch processing mode, significantly improves system processing efficiency, and reduces database write pressure. At the same time, the standardized processing method can flexibly cope with the billing needs of various new digital resources, not only solving the performance problem of existing technologies when processing high-frequency events, but also ensuring billing accuracy and improving user experience through a unified billing process.

[0008] Optionally, based on a preset aggregation strategy, multiple event consumption data are aggregated into a single heterogeneous metering data. Specifically, this includes: obtaining target event consumption data from multiple event consumption data and estimating the cost per event from the target event consumption data; determining whether the event source type of the target event consumption data is high-frequency and whether the cost per event is less than a preset cost; when the event source type of the target event consumption data is high-frequency and the cost per event is less than the preset cost, temporarily storing the target event consumption data in a high-speed memory buffer, and grouping the multiple target event consumption data in the memory buffer according to preset aggregation dimensions, including rent. User information, resource identifiers, and original units of measurement; retrieve the target group from multiple groups cached in memory, and retrieve the initial temporary storage time point of the first event consumption data in the target group; when the difference between the initial temporary storage time point and the current time point reaches the preset time window length, accumulate the original consumption values ​​corresponding to all event consumption data in the target group to obtain the total consumption value; generate heterogeneous metering data based on the total consumption value, the aggregation dimension of the target group, and the current flush timestamp; when the event source type of the target event consumption data is not a high-frequency type, or the cost of a single event is greater than or equal to the preset cost, the target event consumption data is used as heterogeneous metering data.

[0009] By adopting the above technical solution, the target event consumption data is analyzed to determine the event source type and estimate the cost of a single event, thus achieving intelligent identification and triage of high-frequency, low-value events. For high-frequency event consumption data with a single event cost less than the preset cost, it is temporarily stored in a high-speed memory buffer and grouped based on preset aggregation dimensions such as tenant information, resource identifier, and original unit of measurement. This processing mechanism significantly reduces the number of database writes. By tracking the initial temporary storage time of the first event consumption data in the target group, when the difference from the current time reaches the preset time window length, the original consumption values ​​of all event consumption data in the group are automatically accumulated to obtain the total consumption value. This total consumption value is then combined with the aggregation dimensions and the current flush timestamp to generate heterogeneous metering data. For non-high-frequency event consumption data or event consumption data with high single event costs, it is directly processed as heterogeneous metering data. This approach ensures real-time processing capability for high-value events while improving the processing efficiency of high-frequency, low-value events through batch aggregation processing, effectively balancing resource utilization and real-time processing requirements, and reducing system load.

[0010] Optionally, the resource type is streaming resource. Multiple event consumption data describing resource consumption are obtained from the multimodal resource adaptation layer. Specifically, this includes: receiving a user's resource access request; extracting estimated consumption parameters from the access request; estimating the estimated cost based on the pricing plan; querying the available balance of the account information in real time; determining whether the available balance is greater than or equal to the estimated cost; if the available balance is less than the estimated cost, rejecting the access request and returning an insufficient balance prompt to the user; if the available balance is greater than or equal to the estimated cost, freezing funds equal to the estimated cost in the account information and allowing the access request to proceed until the access request is completed; then obtaining the streaming resource consumption data and using the consumption data as event consumption data.

[0011] By adopting the above technical solution, when a user requests access to streaming resources, the system extracts estimated consumption parameters and combines them with the pricing plan to estimate costs. It also checks the available account balance in real time for comparison, effectively preventing billing risks due to insufficient balance before resource usage. When the available balance is insufficient, the access request is promptly rejected and a prompt is returned, avoiding invalid resource consumption due to user funding issues. When the available balance is sufficient, funds equal to the estimated cost are pre-frozen, ensuring cost guarantees during resource usage without excessively freezing user funds and impacting other business operations. After the access request is completed, the actual streaming resource consumption data is obtained as event consumption data. This combination of estimation and pre-freezing not only improves the security of streaming resource billing but also reduces service interruptions due to insufficient balance, ensuring the controllability and accuracy of the billing process.

[0012] Optionally, after inputting the discounted billing item into the multi-level pipeline billing engine, the account information is processed according to the final cost after the discount. Specifically, this includes: releasing funds frozen in the account information equal to the estimated cost, and deducting the amount from the account information according to the final cost after the discount.

[0013] By adopting the above technical solution, the frozen funds in the account information equal to the estimated cost are first released, and then the actual payment is deducted based on the final discounted cost. This achieves accurate settlement of fees for streaming resource usage. The step-by-step processing ensures that users only pay for the resources actually consumed, avoiding overcharging or undercharging due to discrepancies between estimated and actual costs. Simultaneously, the timely release of frozen funds improves the efficiency of user fund utilization and reduces the time funds are tied up.

[0014] Optionally, the method further includes: upon receiving a refund instruction, extracting the refund instruction to obtain the refund tenant, original transaction serial number, refund amount, refund type, and refund initiator; if the refund initiator's identity verification is successful, querying the corresponding original transaction serial number in the accounting database; when the refund type is a prepaid model, obtaining the final cost and billing unit price after historical discounts from the original transaction serial number, where the billing unit price is the resource catalog unit price at the current moment; obtaining the actual usage time of the refund initiator since the purchase time, multiplying the actual usage time by the billing unit price to obtain the cost; subtracting the cost from the final cost after historical discounts to obtain the first refund amount, wherein when the first refund amount is positive, confirming that the first refund amount is valid. Effective refund amount; when the refund type is a postpaid model, obtain the final fee after historical discounts from the original transaction record; determine whether the refund amount is less than or equal to the final fee after historical discounts; when the refund amount is less than or equal to the final fee after historical discounts, determine the refund amount as the second refund amount; when the first refund amount or the second refund amount is greater than 0, use the first refund amount or the second refund amount as the target refund amount, and refund the target refund amount based on the payment ratio to obtain the refund result; generate a refund transaction record based on the target refund amount and the refund result, and store the refund transaction record in the accounting database. The refund transaction record includes the refund transaction number, refund tenant, target refund amount, refund type, and associated original transaction number.

[0015] By employing the aforementioned technical solution, the refund instruction is parsed to obtain information on the refund tenant, original transaction serial number, refund amount, refund type, and refund initiator. Identity verification is used to ensure the security of the refund operation. Different refund calculation methods are applied to prepaid and postpaid models: For the prepaid model, the cost is calculated by obtaining the final cost after historical discounts and the current billing price, combined with the actual usage time, and the difference between the two is used to obtain the first refund amount, ensuring that the refund amount is reasonable and does not exceed the historical payment amount; for the postpaid model, the second refund amount is determined directly by comparing the refund amount with the final cost after historical discounts. The valid first or second refund amount is used as the target refund amount, and the refund operation is executed based on the payment ratio, generating a complete refund transaction record and storing it in the accounting database. This not only ensures the accuracy and reasonableness of the refund process but also guarantees the traceability of the refund operation through complete transaction records, effectively balancing user rights and platform interests.

[0016] Optionally, a refund can be processed based on the payment ratio to obtain the refund result. Specifically, this includes: obtaining multiple payment methods and their corresponding payment amounts from the original transaction records; dividing the multiple payment amounts by the final fee after historical discounts to obtain multiple payment ratios, with each ratio corresponding to a payment method; multiplying the target refund amount by each payment ratio to obtain multiple payment refund amounts; returning each payment refund amount to the original payment channel for the corresponding payment method and recording the initial refund result for each original payment channel; if the payment method is an account balance, adding the payment refund amount to the refund tenant's account balance; if the payment method is a voucher, returning the voucher amount of the payment refund amount to the refund tenant's account; if the payment method is a third-party payment, calling the corresponding payment gateway interface to execute the payment refund amount; and summarizing the initial refund results from all original payment channels to generate the final refund result.

[0017] By adopting the above technical solution, multiple payment methods and corresponding payment amounts are obtained from the original transaction records. The payment percentage is calculated by determining the proportion of each payment method to the final fee after historical discounts. The target refund amount is then allocated according to these payment percentages, ensuring the fairness and accuracy of refund amounts for each payment method. Differentiated refund processing strategies are adopted for different payment methods. The multi-channel collaborative refund processing mechanism not only ensures the accuracy and completeness of the refund process but also improves the automation of the refund operation. At the same time, the return of funds to the original payment method ensures the compliance of the fund flow and optimizes the user's refund experience.

[0018] Optionally, the method further includes: receiving an upgrade instruction for a specific resource under a prepaid model, the upgrade instruction containing target configuration information; calculating the upgrade surcharge for the specific resource in the remaining service period based on the target configuration information, the current configuration information of the specific resource, and the pricing plan; freezing target funds equal to the upgrade surcharge in the account information and executing the upgrade operation; obtaining the execution result of the upgrade operation; when the execution result is a successful upgrade, deducting the frozen target funds to complete the payment of the upgrade fee and updating the configuration information of the specific resource to the target configuration information; when the execution result is a failed upgrade, unfreezing the target funds and rolling back the configuration status of the specific resource to the state before the upgrade.

[0019] By adopting the above technical solution, upon receiving an upgrade instruction, the system accurately calculates the upgrade difference fee for the remaining service period based on the target configuration information, the current configuration information of specific resources, and the pricing plan. An equivalent amount of the target funds is then pre-frozen in the account information. This pre-freezing mechanism effectively prevents financial risks during the upgrade process. When executing the upgrade operation, the subsequent processing is determined by judging the execution result. This process of freezing first, then executing, and deciding whether to deduct or unfreeze based on the result not only ensures the security and reliability of resource configuration adjustments but also improves the automation level of the upgrade operation and optimizes the user experience.

[0020] A second aspect of this application provides a unified billing system for digital resources. The system includes an acquisition unit, a processing unit, and an uploading unit. The acquisition unit acquires multiple event consumption data describing resource consumption from a multimodal resource adaptation layer, and aggregates these multiple event consumption data into a single heterogeneous metering data based on a preset aggregation strategy. The processing unit identifies the resource types contained in the heterogeneous metering data, queries preset resource indicator mapping rules according to the resource types, and converts the original consumption values ​​in the heterogeneous metering data into standardized metering indicators and standardized values ​​corresponding to the standardized metering indicators, thereby generating normalized metering data containing tenant information, standardized metering indicators, and standardized values. The system also acquires the user status corresponding to the tenant information and uses... The account status includes at least the pricing plan, discount rules, and account information. The normalized metering data is processed by a multi-level pipeline billing engine. Based on the pricing plan and standardized metering indicators, the standardized values ​​are converted into pre-discount costs, resulting in approved billing items. These approved billing items are then processed in the discount processing stage of the multi-level pipeline billing engine. Based on the discount rules, the pre-discount costs are processed to obtain the final discounted cost, generating discounted billing items. The uploading unit then processes these discounted billing items in the accounting processing stage of the multi-level pipeline billing engine. The discounted billing items are input into the multi-level pipeline billing engine, and the account information is processed according to the final discounted cost, generating a transaction record recording this expense. This transaction record is then stored in the accounting database.

[0021] In a third aspect of this application, an electronic device is provided, comprising a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory, causing the electronic device to perform the method as described in any of the above-described embodiments of this application.

[0022] In a fourth aspect, this application provides a computer-readable storage medium storing instructions that, when executed, perform any of the methods described above in this application.

[0023] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. Event consumption data is acquired at the multimodal resource adaptation layer, and a pre-defined aggregation strategy is used to aggregate the event consumption data into heterogeneous metering data, effectively solving the system performance bottleneck problem in existing technologies when dealing with high-frequency, low-value consumption events. By identifying the resource types in the heterogeneous metering data and applying pre-defined resource indicator mapping rules, the original consumption values ​​are converted into standardized metering indicators and standardized values, thereby generating normalized metering data and achieving unified processing of different types of digital resources. After obtaining the user status corresponding to the tenant, a multi-level pipeline billing engine is used to sequentially perform batch pricing, discount processing, and accounting processing, converting standardized values ​​into pre-discount costs, then obtaining the final post-discount costs, and finally completing the accounting processing and generating transaction records stored in the accounting database. This breaks through the limitations of the traditional fixed-cycle batch processing mode, significantly improving system processing efficiency and reducing database write pressure. At the same time, the standardized processing method can flexibly cope with the billing needs of various new digital resources, not only solving the performance problem of existing technologies when processing high-frequency events, but also ensuring billing accuracy and improving user experience through a unified billing process. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the first process of a unified billing method for digital resources provided in an embodiment of this application; Figure 2 This is a schematic diagram of the system framework for a unified billing method for digital resources provided in an embodiment of this application; Figure 3 This is a timing diagram illustrating a unified billing method for digital resources provided in an embodiment of this application; Figure 4 This is a schematic diagram of the second process of a unified billing method for digital resources provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0025] Explanation of reference numerals in the attached drawings: 500, electronic device; 501, processor; 502, memory; 503, user interface; 504, network interface; 505, communication bus. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0027] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0028] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0029] Therefore, addressing the performance bottlenecks in existing technologies when dealing with high-frequency, low-value consumption events is a pressing issue. This application provides a unified billing method for digital resources, applicable to a billing platform. Figure 1 This is a first flowchart illustrating a unified billing method for digital resources provided in an embodiment of this application. (Refer to...) Figure 1 The method includes the following steps S101-S107.

[0030] S101: Obtain multiple event consumption data describing resource consumption from the multimodal resource adaptation layer, and aggregate the multiple event consumption data into a single heterogeneous metering data based on a preset aggregation strategy.

[0031] In S101 above, the multimodal resource adaptation layer uses four types of adapters to achieve unified access and metering data collection for different types of digital resources. The IaaS adapter is responsible for connecting to infrastructure platforms such as OpenStack / K8s, and by monitoring the lifecycle events of resources such as virtual machines and disks, it transforms resource state changes into unified event consumption data. The streaming metering gateway intercepts API requests from OpenAI / LLM services in real time, meters token usage, and generates corresponding event consumption data. The storage telemetry probe periodically collects capacity snapshots and traffic logs from Ceph / S3 storage systems, transforming storage resource usage into event consumption data. The function compute gateway collects memory usage and execution time of Serverless functions, generating millisecond-level event consumption data. The event consumption data collected by these adapters is processed according to preset aggregation strategies. For example, for high-frequency token billing scenarios, multiple API calls within one minute are aggregated into a single heterogeneous metering data, while for storage resources, capacity usage data is aggregated at the hourly level. This unified access and intelligent aggregation mechanism effectively handles massive amounts of metering data generated by different resource types, reducing database write pressure while maintaining data accuracy and traceability. For example... Figure 2 As shown, raw consumption data of different resource usage scenarios are obtained from multiple resource adaptation layers. This raw consumption data from different sources is then aggregated into metering data, which is then converted into a unified metering unit to normalize resource usage. Next, tenant pricing plans, discount plans, and account information are obtained from the user center. A multi-level pipeline billing engine is then used to perform batch pricing, discount processing, and accounting processing on the unified metering unit, subsequently recording the complete billing process and results. Refund processing includes refund application, verification, calculation, and execution; fund processing includes financial operations such as freezing, unfreezing, and deductions.

[0032] In addition, the resource type is streaming resource. Multiple event consumption data describing resource consumption are obtained from the multimodal resource adaptation layer. Specifically, this includes: receiving a user's resource access request, extracting estimated consumption parameters from the access request, and estimating the estimated cost based on the pricing plan; querying the available balance of the account information in real time to determine whether the available balance is greater than or equal to the estimated cost; if the available balance is less than the estimated cost, the access request is rejected and a insufficient balance prompt is returned to the user; if the available balance is greater than or equal to the estimated cost, funds equal to the estimated cost are frozen in the account information, and the access request is allowed to be executed until the access request is completed. After that, the consumption data of the streaming resource is obtained and used as event consumption data.

[0033] Specifically, in scenarios involving streaming resources, taking large model API calls as an example, when a user initiates an access request to the Gxx-4 inference interface, the streaming metering gateway first extracts estimated consumption parameters such as max_tokens from the access request. Based on the currently effective pricing plan (e.g., input_tokens at a unit price of 0.01 yuan / 1K, completion_tokens at a unit price of 0.03 yuan / 1K), these estimated consumption parameters are calculated. For example, if the user sets max_tokens to 2000, it is estimated that this call may generate a maximum input of 1000 tokens and a maximum output of 2000 tokens, and the estimated cost is calculated to be 0.07 yuan (0.01×1+0.03×2=0.07 yuan).

[0034] Subsequently, the available balance in the user's account information is queried in real time through the Redis cache, and atomic operations are used to ensure concurrency safety. When the available balance is found to be less than 0.07 yuan, the access request is immediately rejected and a message "Insufficient account balance, please recharge and try again" is returned. This pre-check mechanism avoids invalid resource consumption due to insufficient balance. If the available balance is sufficient (e.g., the current balance is 10 yuan), 0.07 yuan of estimated fees is immediately frozen in the account information through a distributed lock mechanism to reserve sufficient funds for subsequent deductions. After successfully freezing the funds, the access request is allowed to proceed, and the large model begins streaming inference calculations. During the request execution process, the streaming metering gateway monitors the number of input and output tokens in real time. After the request is completed, the actual consumption data is obtained (e.g., actual input 800 tokens, output 1500 tokens), and this precise usage data is used as event consumption data. This two-stage processing mechanism based on estimation and actual settlement ensures both the operational security of the system and the accuracy of billing. At the same time, the pre-freezing mechanism effectively prevents the risk of asset loss and improves the reliability and efficiency of the entire streaming resource billing process.

[0035] Finally, the previously frozen estimated fee of 0.07 yuan can be released. Based on the actual number of tokens consumed (800 + 1500 = 2300 tokens), the actual fee of 0.053 yuan (0.01 × 0.8 + 0.03 × 1.5 = 0.053 yuan) is calculated, and the final deduction is executed. This settlement method, which is accurate to the final actual usage, ensures that users only pay for the resources actually consumed, improving the fairness of billing and the user experience.

[0036] Furthermore, based on a preset aggregation strategy, multiple event consumption data are aggregated into a single heterogeneous metering data. Specifically, this includes: obtaining target event consumption data from multiple event consumption data and estimating the cost per event from the target event consumption data; determining whether the event source type of the target event consumption data is a high-frequency type and whether the cost per event is less than a preset cost; when the event source type of the target event consumption data is a high-frequency type and the cost per event is less than the preset cost, the target event consumption data is temporarily stored in a high-speed memory buffer, and the multiple target event consumption data in the memory buffer are grouped according to preset aggregation dimensions, including rent. User information, resource identifiers, and original units of measurement; retrieve the target group from multiple groups cached in memory, and retrieve the initial temporary storage time point of the first event consumption data in the target group; when the difference between the initial temporary storage time point and the current time point reaches the preset time window length, accumulate the original consumption values ​​corresponding to all event consumption data in the target group to obtain the total consumption value; generate heterogeneous metering data based on the total consumption value, the aggregation dimension of the target group, and the current flush timestamp; when the event source type of the target event consumption data is not a high-frequency type, or the cost of a single event is greater than or equal to the preset cost, the target event consumption data is used as heterogeneous metering data.

[0037] Specifically, in large-scale token billing scenarios, multiple event consumption data are retrieved in batches from the Redis queue, such as 1000 API call records generated within the last second. For each record, the actual token consumption and unit price information are extracted to calculate the cost per event. For example, if a call consumes 300 tokens as input and 500 tokens as output, the cost per event is calculated to be 0.018 yuan (0.01 × 0.3 + 0.03 × 0.5 = 0.018 yuan). The source type and fee standard of the event are then determined. For high-frequency events like Gxx-4 API calls, when the cost per event is lower than the preset threshold of 0.05 yuan, a micro-batch processing mechanism can be initiated.

[0038] Redis is used as a high-speed in-memory buffer, employing a hash structure to store these low-value, high-frequency events. Grouping is done using a composite key: tenant ID, resource type (e.g., gpt-4-api), and unit of measurement (tokens). For example, all Gxx-4 calls by user A are organized and stored using the key pattern "userA:gpt4:tokens". When new event consumption data arrives, it is added to the corresponding group using the Redis HSET command, and the initial staging timestamp is recorded on the first write. The time windows of each group are continuously monitored. When the difference between the initial staging time and the current time of a group (e.g., user A's GPT-4 calls) reaches a preset 60 seconds, aggregation processing for that group is triggered. During processing, the HGETALL command retrieves all event records within the group, and the token consumption values ​​are accumulated. For example, if user A consumed a total of 15,000 input tokens and 25,000 output tokens within 60 seconds. Based on the accumulated total consumption value (40,000 tokens), combined with the aggregation dimension information of the group (user A, Gxx-4 API, tokens) and the current flush timestamp, a heterogeneous metering data is generated, containing complete metering information and aggregated statistical results. This heterogeneous metering data will serve as the basis for subsequent billing.

[0039] Furthermore, for events that do not meet the conditions for micro-batch processing, such as large-scale inference requests with a single cost of 0.05 yuan or more, or non-high-frequency resource operations (such as virtual machine creation), they are directly treated as independent heterogeneous metering data and no aggregation operation is performed. This differentiated processing strategy ensures the real-time nature of important events, while significantly reducing database write pressure through micro-batch aggregation.

[0040] S102: Identify the resource types contained in the heterogeneous metering data, and query the preset resource indicator mapping rules according to the resource types.

[0041] In S102 above, when processing heterogeneous metering data, resource type identifiers are extracted from the metering data. For example, for metering data generated by large model API calls, the resource type is "Gxx4-API"; for metering data generated by virtual machine instances, the resource type is "ECS-Instance"; and for metering data generated by object storage, the resource type is "Object-Storage".

[0042] Based on the identified resource type, the corresponding preset resource indicator mapping rules are queried from the resource indicator mapping table in the unified product center. For the Gxx4-API type, the mapping rules define the measurement units and billing standards corresponding to the input tokens and output tokens, respectively; for the ECS-Instance type, the mapping rules include the correspondence between basic resource indicators such as CPU cores and memory size and billing specifications; for the Object-Storage type, the mapping rules include measurement methods for multi-dimensional indicators such as storage capacity, access frequency, and data traffic. Through this unified resource indicator mapping mechanism, the raw measurement data of different types of resources can be transformed into standardized billing indicators, providing a unified data foundation for subsequent cost accounting. This implementation method not only solves the problem of inconsistent measurement standards for heterogeneous resources.

[0043] S103: Based on the preset resource index mapping rules, the original consumption values ​​in the heterogeneous metering data are converted into standardized metering indicators and the standardized values ​​corresponding to the standardized metering indicators, thereby generating normalized metering data containing tenant information, standardized metering indicators and standardized values.

[0044] In S103 above, when converting heterogeneous metering data, a standardized conversion operation is performed based on preset resource indicator mapping rules. For example, in a large model API call scenario, when heterogeneous metering data containing tenant A's cumulative consumption of 15,000 input tokens and output of 25,000 tokens within 60 seconds is received, the tokens are converted into a standardized metering indicator "NMU" (Normalized Metering Unit) according to the mapping rules.

[0045] During the specific conversion process, according to preset conversion rules, input tokens are converted into 15 input NMU units at a ratio of 1000:1, and output tokens are converted into 50 output NMU units at a ratio of 500:1. This ultimately generates normalized metering data containing tenant A's identifier, two standardized metering metrics, "INPUT_NMU" and "OUTPUT_NMU," and the corresponding standardized values ​​of 15 and 50. For object storage scenarios, the original storage amount of "1GB × 1 hour" is converted into one storage NMU unit according to preset rules. For virtual machine scenarios, the resource usage of "4 cores 8GB × 1 hour" is converted into 12 compute NMU units (4 cores × 2 + 8GB × 0.5). Through this unified normalization conversion mechanism, standardized expressions of different types of resource consumption are achieved, laying the foundation for subsequent unified billing processing. This approach not only solves the problem of inconsistent measurement units for heterogeneous resources, but also achieves unified measurement of multi-dimensional resource usage through a standardized NMU system, improving the universality and scalability of the billing system. It also provides a unified measurement benchmark for resource cost accounting in hybrid billing scenarios.

[0046] In one possible implementation, in scenarios with fewer resource types, a corresponding preset metering template can be set in advance for each resource type. Subsequently, the corresponding preset metering template can be matched according to the tags of each data type, and the heterogeneous metering data corresponding to each resource type can be mapped to the preset metering template to obtain unified metering data.

[0047] S104: Obtain the user status corresponding to the tenant information. The user status includes at least the pricing plan, discount rules, and account information.

[0048] In S104 above, when processing normalized metering data, complete user status information is queried from the unified user center using the tenant identifier. Taking tenant A as an example, the pricing plan applicable to tenant A is obtained, including the standard pricing of basic resources (e.g., input NMU unit price of 0.01 yuan, output NMU unit price of 0.03 yuan) and tiered pricing rules (e.g., the unit price is reduced by 20% after the monthly cumulative NMU exceeds 10,000 units).

[0049] Simultaneously, the system queries tenant A's discount rules, including enterprise customer discounts (such as a uniform 10% discount), marketing activity discounts (such as a 15% discount for new users in their first month), and voucher discounts (such as deductible amounts), among other multi-dimensional preferential policies. It also obtains tenant account information in real time, including payment ability indicators such as cash balance, voucher balance, and credit limit, as well as risk control indicators such as historical arrears and credit rating. This multi-dimensional user status acquisition mechanism provides a complete basis for pricing and discounts in subsequent cost calculations, while real-time account status checks ensure the security of the billing process.

[0050] S105: The normalized metering data is processed through a multi-level pipeline billing engine. Based on the pricing plan and standardized metering indicators, the standardized values ​​are converted into pre-discount costs to obtain the approved billing items.

[0051] In S105 above, during the cost accounting stage, the multi-level pipeline billing engine performs batch pricing conversion on the normalized metering data according to a standardized processing flow. Taking tenant A's large model call as an example, after receiving normalized metering data containing 15 input NMUs and 50 output NMUs, it first enters the batch pricing stage. Based on tenant A's current applicable pricing plan, the unit price of the input NMU is determined to be 0.01 yuan, and the unit price of the output NMU is determined to be 0.03 yuan.

[0052] The billing engine uses a high-precision calculation engine (maintaining 4-6 decimal places of precision) to multiply the standardized value by the corresponding unit price, resulting in an input NMU cost of 0.15 yuan (15 × 0.01) and an output NMU cost of 1.50 yuan (50 × 0.03), totaling 1.65 yuan before the discount. For scenarios involving tiered pricing, the engine queries the tenant's cumulative usage in real time to determine the applicable price tier. For example, if a tenant's cumulative NMU usage exceeds 10,000 units in a month, the engine automatically calculates the cost based on the unit price after a 20% price reduction. The billing engine encapsulates the calculated cost amount, along with billing cycle, resource type, and metering metrics, into a pre-approved billing item. This standardized pricing process achieves unified pricing for different types of resources, ensuring the accuracy and consistency of the billing process.

[0053] S106: Enables the pre-priced billing items to be processed in the discount processing stage of the multi-level pipeline billing engine, processes the pre-discount fees based on the discount rules, obtains the final discounted fees, and generates the discounted billing items.

[0054] In the above S106, during the discount processing stage, after the multi-level pipeline billing engine receives the approved billing items, it executes a multi-level discount calculation process.

[0055] Taking tenant A's large model call as an example, after obtaining the approved billing item with a pre-discount fee of 1.65 yuan, it enters the dynamic processing pipeline of the discount engine. Multiple discount rules are applied sequentially according to a preset priority order: first, a 10% discount for enterprise customers is applied, adjusting the fee to 1.485 yuan; then, a 15% discount for new users' first month is added, further reducing the fee to 1.26225 yuan; finally, it checks if there are applicable vouchers. If a 5 yuan general voucher is available in the tenant's account and the current fee meets the usage conditions, the actual deduction amount is calculated according to the voucher's usage rules (such as proportional deduction). During each level of discount processing, high-precision calculations ensure the amount is accurate to four decimal places. After processing all discount rules, a discounted billing item containing the original amount, discount information at each level, and the final payable amount is generated. This multi-level pipeline discount processing mechanism not only enables precise calculation of complex preferential policies but also ensures the configurability of discount rules and the transparency of the processing through pipelined processing. This approach flexibly supports various marketing strategies while guaranteeing the accuracy and traceability of cost calculations, significantly improving the business adaptability and user satisfaction of the billing system.

[0056] S107: Enables discounted billing items to be processed in the billing stage of the multi-level pipeline billing engine, processes account information based on the final discounted cost, generates transaction logs recording the current expense, and stores the transaction logs in the billing database.

[0057] In S107 above, during the final settlement stage, the multi-level pipeline billing engine executes the accounting process for the discounted billing items. Taking tenant A's large model call as an example, after obtaining the discounted billing item with a final cost of 1.26225 yuan, it first locks the tenant's account information through a distributed lock mechanism to ensure concurrency safety. It then prioritizes checking the voucher balance in the tenant's account; if a voucher meets the usage conditions, it deducts the voucher amount first; the remaining cost is deducted from the cash balance. During the deduction process, atomic operations ensure the consistency of accounting processing, while generating a complete transaction log record containing complete information such as transaction time, transaction type, resource information, original amount, discount information, and payment details. Figure 2As shown, in addition to aggregating multiple event consumption data according to a preset aggregation strategy, single event consumption data can also be aggregated into target heterogeneous measurement data. Referring to the above processing of heterogeneous measurement data, the target heterogeneous measurement data is then processed. After obtaining the corresponding expenditure transaction records, the expenditure transaction records within a preset period are temporarily cached in memory. After the preset period is reached, the cached expenditure transaction records in memory are uploaded to the financial database. Whether to aggregate multiple event consumption data within the preset period in the early stage or aggregate transaction records of a single event consumption data later can be chosen based on the actual situation; no further restrictions are imposed here.

[0058] Furthermore, after inputting the discounted billing item into the multi-level pipeline billing engine, the account information is processed according to the final discounted cost. This includes: releasing funds frozen in the account information equal to the estimated cost, and deducting the amount from the account information based on the final discounted cost. Specifically, during the billing process, the multi-level pipeline billing engine first handles the release of pre-frozen funds. Taking tenant A's large model call as an example, the estimated cost of 0.07 yuan was frozen before the access request was executed. When a discounted billing item with a final discounted cost of 1.26225 yuan is received, the pre-frozen funds are released through an atomic operation in Redis.

[0059] In the specific implementation, Lua scripts are used to ensure the atomicity of the unfreezing operation, avoiding data inconsistency in concurrent scenarios. After unfreezing, the deduction process is immediately initiated, using a distributed lock mechanism to lock tenant A's account information, ensuring the concurrency safety of the deduction process. During deduction execution, the voucher balance in the tenant's account is checked first. A usable general voucher of 5 yuan is found, of which 1 yuan can be used to offset this fee. Therefore, 1 yuan is deducted from the voucher balance, and the remaining 0.26225 yuan is deducted from the cash balance. The entire deduction process uses a transaction mechanism to ensure the atomicity of the operation, while high-precision calculations ensure the amount is accurate to four decimal places. This "unfreeze first, then deduct" processing mechanism ensures both the security of fund operations and data consistency in concurrent scenarios through atomic operations and distributed locks. It not only effectively prevents duplicate deductions and account over-deductions but also improves the reliability and accuracy of the billing system through precise fund processing.

[0060] For high-frequency trading scenarios, a database sharding strategy is employed to store transaction records in the accounting database. Data is evenly distributed and write performance is improved by using tenant ID hashing for sharding. Simultaneously, transaction results are pushed to the risk control and auditing systems via an asynchronous messaging mechanism, enabling real-time risk monitoring and compliance auditing. This comprehensive accounting mechanism not only ensures the security and accuracy of fund operations but also enhances the system's processing capacity and reliability through distributed storage and asynchronous notification mechanisms. Furthermore, detailed transaction records provide reliable data support for subsequent reconciliation, refunds, and auditing.

[0061] like Figure 3 The diagram illustrates the interaction flow between various modules in the billing system, including the alarm user, statistical metering service, large model service, billing engine, and balance service. In the initial request phase, the user initiates a POST request; the statistical metering service receives the request and preprocesses it, then requests an estimated cost from the billing engine; the billing engine calculates the cost, returns the estimated amount, freezes the corresponding amount in the balance service, and returns a token authentication information. In the service call phase, the statistical metering service sends actual usage data to the billing engine; the billing engine performs cost calculation and requests the release of the previously frozen amount; the final charge is deducted based on actual usage, and the deduction result is returned, generating a transaction record. Figure 3 The sequence diagram accurately reflects the billing system workflow described in the above technical solution, especially the fund operation and service call process in the prepaid scenario.

[0062] In one possible implementation, the refund process can also calculate the actual cost based on the current market price, and then output a refund transaction log record. Upon receiving a refund instruction, the instruction is extracted to obtain the refund tenant, original transaction number, refund amount, refund type, and refund initiator. If the refund initiator's identity verification is successful, the corresponding original transaction record is queried in the accounting database based on the original transaction number. When the refund type is a prepaid model, the historical discounted final cost and billing unit price are obtained from the original transaction record, with the billing unit price being the resource catalog unit price at the current moment. The actual usage time of the refund initiator since the purchase time is obtained, and the actual usage time is multiplied by the billing unit price to obtain the cost. The historical discounted final cost is subtracted from the cost to obtain the first refund amount. When the first refund amount is positive, it is confirmed as a valid refund amount. When the refund type is a postpaid model, retrieve the final fee after historical discounts from the original transaction record; determine whether the refund amount is less than or equal to the final fee after historical discounts; when the refund amount is less than or equal to the final fee after historical discounts, determine the refund amount as the second refund amount; when the first refund amount or the second refund amount is greater than 0, use the first refund amount or the second refund amount as the target refund amount, and refund the target refund amount based on the payment ratio to obtain the refund result; generate a refund transaction record based on the target refund amount and the refund result, and store the refund transaction record in the accounting database. The refund transaction record includes the refund transaction number, refund tenant, target refund amount, refund type, and associated original transaction number.

[0063] Specifically, when processing refund scenarios, the system first receives and parses the detailed information of the refund instruction. Taking tenant A's request to cancel an annual cloud server subscription as an example, the system extracts the refund tenant identifier "tenant_A", the original order serial number "ORDER_202501_001", the refund amount of 1000 yuan, the refund type "PREPAID" (prepaid mode), and the refund initiator "user_A" from the refund instruction. The system verifies the identity and permissions of the refund initiator through a unified authentication center, confirming that user_A has the authority to perform the refund operation for this order. After successful verification, the system queries the corresponding original transaction record in the sharded accounting database based on the original transaction serial number. The system finds that the transaction was for a yearly 8-core 16GB cloud server instance purchased by tenant A on January 1, 2025, with a final cost of 12,000 yuan after historical discounts (including a 2,000 yuan voucher and 10,000 yuan in cash payment).

[0064] Since the refund type is a prepaid model, it is necessary to calculate the actual cost of the used resources. The current pay-as-you-go price for this cloud server specification (8 cores, 16GB, 3 yuan / hour) is obtained from the resource catalog. Simultaneously, the actual usage time of the instance (from the purchase date of January 1, 2025 to the cancellation date of June 1, 2025, a total of 3624 hours) is obtained from the resource management system. Using a high-precision calculation engine, the actual usage time of 3624 hours is multiplied by the current pay-as-you-go price of 3 yuan / hour, resulting in a cost of 10872 yuan. Subtracting the cost of 10872 yuan from the historical discounted final cost of 12000 yuan yields the first refund amount of 1128 yuan. First, it is confirmed that the first refund amount is positive. Then, it is compared with the historical discounted final cost. Only when the first refund amount is positive and less than the historical discounted final cost is the first refund amount confirmed as a valid refund. Since the first refund amount is positive and less than the historical discounted final cost of 12000 yuan, the refund process continues. If the first refund amount is greater than or equal to the final cost after the historical discount, it means that the actual cost of use calculated based on the current unit price has exceeded the original payment amount, and a refund failure notification will be sent.

[0065] For refund requests under the postpaid model, the final fee after historical discounts is directly retrieved from the original transaction record, and it is determined whether the requested refund amount exceeds this amount. For example, if tenant B's API call fee for requesting a refund is 50 yuan, and the original transaction amount is found to be 100 yuan, then 50 yuan is determined as the second refund amount. Once the target refund amount is determined (in this example, the first refund amount is 1128 yuan, which meets the refund conditions), the refund amount is split according to the payment ratio in the original transaction to obtain the refund result.

[0066] In addition, the refund is processed based on the payment ratio to obtain the refund result. Specifically, this includes: obtaining multiple payment methods and their corresponding payment amounts from the original transaction records; dividing the multiple payment amounts by the final fee after historical discounts to obtain multiple payment ratios, with each payment ratio corresponding to one payment method; multiplying the target refund amount by each payment ratio to obtain multiple payment refund amounts; returning each payment refund amount to the original payment channel for the corresponding payment method and recording the initial refund result for each original payment channel; if the payment method is an account balance, adding the payment refund amount to the refund tenant's account balance; if the payment method is a voucher, returning the voucher amount of the payment refund amount to the refund tenant's account; if the payment method is a third-party payment, calling the corresponding payment gateway interface to execute the payment refund amount; and summarizing the initial refund results from all original payment channels to generate the final refund result.

[0067] Specifically, when processing the refund, the system first retrieves tenant A's various payment methods and corresponding payment details from the original transaction record "ORDER_202501_001": 8000 yuan paid with account balance, 2000 yuan paid with voucher, and 2000 yuan paid via WeChat. The final cost after historical discounts is 12000 yuan. A high-precision calculation engine is then used to calculate the percentage of each payment method: account balance payment accounts for 66.67% (8000 / 12000), voucher payment accounts for 16.67% (2000 / 12000), and WeChat payment accounts for 16.67% (2000 / 12000). After determining the proportion of each payment method, the target refund amount of 1128 yuan was split proportionally and the refund amount for each payment method was calculated as follows: 752 yuan for account balance (1128 × 66.67%), 188 yuan for vouchers (1128 × 16.67%), and 188 yuan for WeChat Pay (1128 × 16.67%). High-precision calculations were used to ensure that the sum of each refund amount equaled the target refund amount, avoiding any discrepancies in the amount.

[0068] For the account balance refund, 752 yuan is directly added to tenant A's account balance via distributed transactions. Specifically, a distributed lock on the account balance is first acquired to ensure concurrency safety, then an UPDATE operation is performed to add the balance, and the initial refund result "BALANCE_REFUND_SUCCESS" is recorded. For the voucher refund, the original voucher usage record is queried to confirm the voucher type and validity period. If the original voucher is still valid, the voucher amount is directly restored; if it has expired, a new voucher of equivalent value is issued. The voucher refund is executed atomically, and the initial refund result "COUPON_REFUND_SUCCESS" is recorded. For the wxpayer refund, the wxpayer refund gateway interface is called, passing in the original transaction number, refund amount of 188 yuan, and other parameters. The system waits for the wxpayer gateway to return the refund result through an asynchronous callback mechanism. Upon receiving a successful callback, the initial refund result "WECHAT_REFUND_SUCCESS" is recorded. If a refund fails, the refund operation will be automatically retried, and operations personnel will be notified for manual processing. Finally, the initial refund results from the three payment channels are aggregated to generate the final refund result "REFUND_SUCCESS". Throughout the refund process, distributed transactions ensure the atomicity of all refund operations; any refund failure from any channel will trigger a complete transaction rollback. Simultaneously, detailed refund operation logs are recorded, including the refund amount, refund time, and refund status for each payment method, ensuring the traceability of the refund process. After the target refund amount is returned to the corresponding payment channel according to the payment ratio, a refund transaction log is generated, including the newly generated refund log number "REFUND_202506_001", the refund tenant "tenant_A", the target refund amount of 1128 yuan (the respective refund amounts for each payment method), the refund type "PREPAID", and the associated original transaction log number "ORDER_202501_001".

[0069] A precise refund mechanism based on the original payment percentage effectively prevents users from using refunds to obtain vouchers (e.g., applying for a refund to a cash account after paying with a voucher). Simultaneously, complete refund transaction records and multi-level transaction protection ensure the security and accuracy of the refund process. Figure 4 As shown, the complete process of the above system in processing refund requests is demonstrated in detail, especially the processing of mixed prepaid and post-paid scenarios, realizing the compliant splitting of refund funds and ensuring complete refund measurement and traceability capabilities.

[0070] In one possible implementation, an upgrade instruction for a specific resource under a prepaid model is received, the upgrade instruction containing target configuration information; based on the target configuration information, the current configuration information of the specific resource, and the pricing plan, the upgrade surcharge for the specific resource in the remaining service period is calculated; target funds equal to the upgrade surcharge are frozen in the account information, and the upgrade operation is executed; the execution result of the upgrade operation is obtained; when the execution result is a successful upgrade, the frozen target funds are deducted to complete the payment of the upgrade fee, and the configuration information of the specific resource is updated to the target configuration information; when the execution result is a failed upgrade, the frozen target funds are unfrozen, and the configuration status of the specific resource is rolled back to the state before the upgrade.

[0071] Specifically, when handling resource upgrade scenarios, the system receives and parses the upgrade command from tenant A. Taking cloud server upgrade as an example, the system extracts the target configuration information from the upgrade command: upgrading from an 8-core 16GB configuration to a 16-core 32GB configuration. The system then queries the current configuration information of the instance: the original purchase date was January 1, 2025, the service period was 1 year, the current date is June 1, 2025, and the remaining service time is 214 days (inclusive).

[0072] Based on the target configuration and current configuration information, the upgrade price difference is calculated using the pricing plan. The annual standard price for two specifications is obtained from the resource catalog: 12,000 yuan / year for 8 cores and 16GB for 24,000 yuan / year for 16 cores and 32GB. Using a high-precision calculation engine, the upgrade price difference is calculated proportionally to the remaining service days: (24,000 - 12,000) × (214 / 365) = 7,047.12 yuan. Simultaneously, the discount strategy applicable to tenant A (e.g., 10% discount for enterprise users) is applied, resulting in a final upgrade price difference of 6,342.41 yuan. Before executing the upgrade operation, tenant A's account information is locked using a distributed lock, and the account balance is checked. Finding a cash balance of 8,000 yuan, meeting the upgrade requirements, the upgrade price difference of 6,342.41 yuan is frozen in the account via an atomic operation. After confirmation of the freeze, the upgrade interface of the resource management platform is called, passing in the instance ID, target specification parameters (16 cores and 32GB), etc., to initiate the upgrade operation.

[0073] An asynchronous callback mechanism is used to await the upgrade result from the resource platform. Upon receiving a successful upgrade response, the billing process is immediately initiated: the previously frozen 6342.41 yuan is deducted from tenant A's account via a distributed transaction, and a transaction record containing upgrade details and fee information is generated and stored in the accounting database. After successful billing, the configuration information of the instance in the resource management database is updated, changing the specification record to 16 cores and 32GB, and recording the change time and operation record.

[0074] Furthermore, if the resource platform returns an upgrade failure (e.g., due to insufficient physical resources), the frozen funds of 6342.41 yuan in the account will be immediately released via atomic operations, ensuring timely fund release. Simultaneously, the instance configuration rollback mechanism will be automatically triggered to ensure the instance status is restored to the pre-upgrade 8-core 16GB configuration, and a failure operation record will be generated. The reason for the upgrade failure will also be notified to the tenant via push notification. This pre-frozen fund upgrade mechanism ensures consistency between resource configuration changes and fee deductions through distributed transactions and atomic operations, effectively preventing upgrade failures due to insufficient balance. At the same time, accurate price difference calculation and complete operation records also guarantee the fairness and traceability of the upgrade process.

[0075] In one possible implementation, a time synchronization and state consistency guarantee mechanism is demonstrated in a distributed billing system, taking tenant A's order for a cloud server as an example. An NTP server cluster provides a unified time base for all billing nodes, while a Lamport logical clock is introduced to ensure the consistency of event order. When tenant A initiates a request to purchase an 8-core, 16GB cloud server at 10:00:23 on January 1, 2025, the timestamp is down-normalized to 10:00:00, which serves as the starting time for order billing.

[0076] In the forward-driven process, an order record is first created and a globally unique order number, ORDER_202501_001, is generated. Tenant A's account information is locked using a distributed lock mechanism. After verifying sufficient account balance (cash balance of 8000 yuan), 1000 yuan of the order amount is frozen in the account. A cloud host creation request is initiated via the OpenStack API, and a status monitor is started to continuously track the resource deployment status. Once the cloud host is successfully created and returns an instance ID (vm-abc123), the order status is updated to "Active," and the actual deduction of 1000 yuan from the tenant's account is completed.

[0077] In scenarios where network fluctuations or service anomalies may occur, a reverse correction mechanism ensures state consistency. For example, if an order status shows "Active" but a query via the OpenStack API reveals that the instance no longer exists, the system's Status Inspector will capture this anomaly. The inspection task immediately marks the order status as "Error" and creates a Compensation Task. This Compensation Task analyzes the complete lifecycle record of the order and discovers that it is a zombie instance (an instance that unexpectedly disappeared after creation). The system automatically triggers the refund process: unfreezing any undeducted funds, refunding any deducted funds to the original payment method, and recording the detailed status change process in the audit log.

[0078] To ensure accuracy in the time dimension, a full reconciliation is performed at the end of each billing cycle (e.g., 23:59:59 daily). The reconciliation program compares the resource status in the order system with the actual status returned by the underlying cloud platform. If inconsistencies are found, a status correction is automatically triggered. Simultaneously, a sliding time window (e.g., 5 minutes) is maintained. All billing events within this window are sorted and processed according to logical clock order to avoid billing errors caused by time deviations. Through time normalization and a two-way state mechanism, the data consistency problem in a distributed environment is effectively solved. The forward drive ensures synchronized updates of order and resource statuses under normal processes, while the reverse correction mechanism provides automatic recovery capabilities in abnormal scenarios.

[0079] This application embodiment also provides a unified billing system for digital resources. The system includes an acquisition unit, a processing unit, and an uploading unit. The acquisition unit acquires multiple event consumption data describing resource consumption from a multimodal resource adaptation layer, and aggregates the multiple event consumption data into a single heterogeneous metering data based on a preset aggregation strategy. The processing unit identifies the resource types contained in the heterogeneous metering data, queries a preset resource indicator mapping rule according to the resource type, and converts the original consumption values ​​in the heterogeneous metering data into standardized metering indicators and standardized values ​​corresponding to the standardized metering indicators according to the obtained preset resource indicator mapping rule, thereby generating normalized metering data containing tenant information, standardized metering indicators, and standardized values. The system also acquires the data corresponding to the tenant information. The user status includes at least a pricing plan, discount rules, and account information. The normalized metering data is processed by a multi-level pipeline billing engine. Based on the pricing plan and standardized metering indicators, the standardized values ​​are converted into pre-discount costs, resulting in approved billing items. These approved billing items are then processed in the discount processing stage of the multi-level pipeline billing engine. Based on the discount rules, the pre-discount costs are processed to obtain the final discounted cost, generating discounted billing items. Finally, the discounted billing items are uploaded to the accounting processing stage of the multi-level pipeline billing engine. Based on the final discounted cost, the account information is processed, generating a transaction record recording the expense, which is then stored in the accounting database.

[0080] In one possible implementation, the acquisition unit is used to acquire target event consumption data from multiple event consumption data, and estimate the cost of a single event from the target event consumption data; the processing unit is used to determine whether the event source type of the target event consumption data is a high-frequency type, and whether the cost of a single event is less than a preset cost; when the event source type of the target event consumption data is a high-frequency type, and the cost of a single event is less than the preset cost, the target event consumption data is temporarily stored in a high-speed memory buffer, and the multiple target event consumption data in the memory buffer are grouped according to a preset aggregation dimension, which includes tenant information, resource identifier, and original metering. The unit is used to obtain the target group from multiple groups in the memory cache and retrieve the initial temporary storage time point of the first event consumption data in the target group; the processing unit is used to accumulate the original consumption values ​​corresponding to all event consumption data in the target group when the difference between the initial temporary storage time point and the current time point reaches the preset time window length, to obtain the total consumption value; based on the total consumption value, the aggregation dimension of the target group and the current flushing timestamp, heterogeneous metering data is generated; when the event source type of the target event consumption data is not a high-frequency type, or the cost of a single event is greater than or equal to the preset cost, the target event consumption data is used as heterogeneous metering data.

[0081] In one possible implementation, the acquisition unit is used to receive a user's resource access request, extract estimated consumption parameters from the access request, and estimate the estimated cost based on the pricing plan; the processing unit is used to query the available balance of the account information in real time, determine whether the available balance is greater than or equal to the estimated cost; if the available balance is less than the estimated cost, the access request is rejected and a insufficient balance prompt is returned to the user; if the available balance is greater than or equal to the estimated cost, funds equal to the estimated cost are frozen in the account information, and the access request is allowed to be executed until the access request is completed, the consumption data of the streaming resource is obtained, and the consumption data is used as event consumption data.

[0082] In one possible implementation, the processing unit is used to release funds frozen in the account information equal to the estimated fee, and deduct the amount from the account information based on the final fee after discount.

[0083] In one possible implementation, the acquisition unit, upon receiving a refund instruction, extracts the refund instruction to obtain the refund tenant, original transaction serial number, refund amount, refund type, and refund initiator; the processing unit, if the refund initiator's identity verification is successful, queries the corresponding original transaction record in the accounting database based on the original transaction serial number; when the refund type is a prepaid model, it retrieves the historical discounted final cost and billing unit price from the original transaction record, where the billing unit price is the resource catalog unit price at the current moment; the acquisition unit obtains the actual usage time of the refund initiator since the purchase time, multiplies the actual usage time by the billing unit price to obtain the cost; the processing unit subtracts the cost from the historical discounted final cost to obtain the first refund amount, wherein, when the first refund amount is positive... The system confirms the first refund amount as a valid refund amount. When the refund type is a postpaid model, it retrieves the final fee after historical discounts from the original transaction record. It then determines whether the refund amount is less than or equal to the final fee after historical discounts. If the refund amount is less than or equal to the final fee after historical discounts, the refund amount is determined as the second refund amount. If either the first or second refund amount is greater than 0, the first or second refund amount is used as the target refund amount, and a refund is processed based on the payment ratio to obtain the refund result. The upload unit generates a refund transaction record based on the target refund amount and the refund result, and stores the refund transaction record in the accounting database. The refund transaction record includes the refund transaction number, refund tenant, target refund amount, refund type, and associated original transaction number.

[0084] In one possible implementation, the acquisition unit is used to obtain multiple payment methods and corresponding payment amounts from the original transaction records; the processing unit is used to divide the multiple payment amounts by the final fee after historical discounts to obtain multiple payment percentages, with each payment percentage corresponding to one payment method; multiply the target refund amount by each payment percentage to obtain multiple payment refund amounts; return each payment refund amount to the original payment channel of the corresponding payment method, and record the initial refund result of each original payment channel; if the payment method is an account balance, add the payment refund amount to the refund tenant's account balance; if the payment method is a voucher, return the voucher of the payment refund amount to the refund tenant's account; if the payment method is a third-party payment, call the corresponding payment gateway interface to execute the refund of the payment refund amount; and summarize the initial refund results of all original payment channels to generate a refund result.

[0085] In one possible implementation, the acquisition unit is used to receive an upgrade instruction for a specific resource under the prepaid model, the upgrade instruction containing target configuration information; the processing unit is used to calculate the upgrade price difference fee for the specific resource in the remaining service period based on the target configuration information, the current configuration information of the specific resource, and the pricing plan; freeze target funds equal to the upgrade price difference fee in the account information and execute the upgrade operation; obtain the execution result of the upgrade operation; when the execution result is a successful upgrade, deduct the frozen target funds to complete the payment of the upgrade fee and update the configuration information of the specific resource to the target configuration information; when the execution result is a failed upgrade, unfreeze the target funds and roll back the configuration status of the specific resource to the state before the upgrade.

[0086] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0087] This application also discloses an electronic device. (See reference...) Figure 5 , Figure 5 This application provides a schematic diagram of the structure of an electronic device. The electronic device 500 may include: at least one processor 501, at least one network interface 504, a user interface 503, a memory 502, and at least one communication bus 505.

[0088] The communication bus 505 is used to enable communication between these components.

[0089] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0090] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0091] The processor 501 may include one or more processing cores. The processor 501 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 502, and by calling data stored in memory 502. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and application requests; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0092] The memory 502 may include random access memory (RAM) or read-only memory. Optionally, the memory 502 may include a non-transitory computer-readable storage medium. The memory 502 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 502 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 502 may also be at least one storage device located remotely from the aforementioned processor 501.

[0093] like Figure 5 As shown, the memory 502, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application for unified billing of digital resources.

[0094] exist Figure 5In the electronic device 500 shown, the user interface 503 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 501 can be used to call the application program for unified billing of digital resources stored in the memory 502. When executed by one or more processors, the electronic device performs one or more of the methods described in the above embodiments.

[0095] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0096] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0097] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some service interfaces; indirect couplings or communication connections between devices or units may be electrical or other forms.

[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0100] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0101] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure.

Claims

1. A unified billing method for digital resources, characterized in that, The method includes: Multiple event consumption data describing resource consumption are obtained from the multimodal resource adaptation layer, and the multiple event consumption data are aggregated into a single heterogeneous metering data based on a preset aggregation strategy. Identify the resource types contained in the heterogeneous metering data, and query the preset resource indicator mapping rules according to the resource types; According to the preset resource index mapping rules, the original consumption values ​​in the heterogeneous metering data are converted into standardized metering indicators and standardized values ​​corresponding to the standardized metering indicators, thereby generating normalized metering data containing tenant information, the standardized metering indicators and the standardized values. Obtain the user status corresponding to the tenant information, wherein the user status includes at least the pricing plan, discount rules, and account information; The normalized metering data is processed by a multi-level pipeline billing engine. Based on the pricing plan and the standardized metering indicators, the standardized values ​​are converted into pre-discount fees to obtain the approved billing items. The pre-priced billing item is processed in the discount processing stage of the multi-level pipeline billing engine. Based on the discount rules, the pre-discount fee is processed to obtain the final post-discount fee and generate the discounted billing item. The discounted billing item is processed in the billing stage of the multi-level pipeline billing engine. The account information is processed according to the final cost after the discount, a transaction record is generated to record the expenditure of this expense, and the transaction record is stored in the accounting database.

2. The method according to claim 1, characterized in that, The aggregation of multiple event consumption data into a single heterogeneous measurement data based on a preset aggregation strategy specifically includes: Obtain target event consumption data from multiple event consumption data sets, and estimate the cost of a single event from the target event consumption data set; Determine whether the event source type of the target event data consumption is a high-frequency type, and whether the cost of a single event is less than a preset cost; When the event source type of the target event consumption data is the high-frequency type, and the cost of a single event is less than the preset cost, the target event consumption data is temporarily stored in a memory cache, and multiple target event consumption data in the memory cache are grouped according to a preset aggregation dimension, which includes tenant information, resource identifier, and original unit of measurement. Obtain the target group from the multiple groups in the memory cache, and retrieve the initial temporary storage time point of the first event consumption data in the target group; When the difference between the initial temporary storage time point and the current time point reaches the preset time window length, the original consumption values ​​corresponding to all the event consumption data in the target group are summed to obtain the total consumption value. The heterogeneous metering data is generated based on the total consumption value, the aggregation dimension of the target group, and the current flushing timestamp. When the event source type of the target event consumption data is not the high-frequency type, or the cost of a single event is greater than or equal to the preset cost, the target event consumption data will be used as the heterogeneous metering data.

3. The method according to claim 1, characterized in that, The resource type is a streaming resource, which obtains multiple event consumption data describing resource consumption from the multimodal resource adaptation layer, specifically including: Upon receiving a user's resource access request, the system extracts estimated consumption parameters from the access request and estimates the estimated cost based on the pricing plan. Real-time query of the available balance of the account information, and determination of whether the available balance is greater than or equal to the estimated cost; If the available balance is less than the estimated cost, the access request will be rejected and a message indicating insufficient balance will be returned to the user. If the available balance is greater than or equal to the estimated cost, funds equal to the estimated cost are frozen in the account information, and the access request is allowed to be executed until the access request is completed. Then, the consumption data of the streaming resource is obtained, and the consumption data is used as the event consumption data.

4. The method according to claim 3, characterized in that, The process of inputting the discounted billing item into the multi-level pipeline billing engine and processing the account information based on the final discounted cost specifically includes: Release the funds frozen in the account information equal to the estimated fee, and deduct the amount from the account information based on the final fee after the discount.

5. The method according to claim 1, characterized in that, The method further includes: Upon receiving a refund instruction, the refund instruction is extracted to obtain the refund tenant, original transaction serial number, refund amount, refund type, and refund initiator; If the identity verification of the refund initiator is successful, the corresponding original transaction record is retrieved from the accounting database based on the original transaction number. When the refund type is a prepaid mode, the final cost and billing unit price after historical discount are obtained from the original transaction record, and the billing unit price is the resource catalog unit price at the current moment; Obtain the actual usage duration from the time of purchase by the refund initiator, and multiply the actual usage duration by the billing unit price to obtain the cost. The first refund amount is obtained by subtracting the cost from the final cost after the historical discount. When the first refund amount is positive, the first refund amount is confirmed as a valid refund amount. When the refund type is a postpaid mode, the final fee after the historical discount is obtained from the original transaction record; Determine whether the refund amount is less than or equal to the final cost after the historical discount; When the refund amount is less than or equal to the final cost after the historical discount, the refund amount will be determined as the second refund amount; When the first refund amount or the second refund amount is greater than 0, the first refund amount or the second refund amount is used as the target refund amount, and the refund is processed based on the payment ratio to obtain the refund result; A refund transaction record is generated based on the target refund amount and the refund result, and the refund transaction record is stored in the accounting database. The refund transaction record includes a refund transaction number, the refund tenant, the target refund amount, the refund type, and the associated original transaction number.

6. The method according to claim 5, characterized in that, The refund is then processed based on the payment ratio to obtain the target refund amount, specifically including: Obtain multiple payment methods and corresponding payment amounts from the original transaction records; Divide the multiple payment amounts by the final cost after the historical discount to obtain multiple payment percentages, and each payment percentage corresponds to one payment method. Multiply the target refund amount by each of the payment percentages to obtain multiple payment refund amounts; Each of the aforementioned payment refund amounts will be returned to the original payment channel corresponding to the aforementioned payment method, and the initial refund result for each of the aforementioned original payment channels will be recorded; If the payment method is account balance, the refund amount is added to the refund tenant's account balance; if the payment method is voucher, the voucher amount of the refund amount is returned to the refund tenant's account. If the payment method is a third-party payment, then the corresponding payment gateway interface is called to execute the refund of the payment refund amount; The initial refund results from all original payment channels are aggregated to generate the aforementioned refund result.

7. The method according to claim 1, characterized in that, The method further includes: Receive an upgrade instruction for a specific resource under the prepaid model, wherein the upgrade instruction contains target configuration information; Based on the target configuration information, the current configuration information of the specific resource, and the pricing plan, the upgrade price difference fee for the specific resource in the remaining service period is calculated; Freeze the target funds equal to the upgrade price difference in the account information and execute the upgrade operation; obtain the execution result of the upgrade operation; When the execution result is a successful upgrade, the frozen target funds are deducted to complete the payment of the upgrade fee, and the configuration information of the specific resource is updated to the target configuration information; When the execution result is that the upgrade fails, the frozen target funds are released, and the configuration status of the specific resource is rolled back to the state before the upgrade.

8. A unified billing system for digital resources, characterized in that, The system includes an acquisition unit, a processing unit, and an upload unit. The acquisition unit acquires multiple event consumption data describing resource consumption from the multimodal resource adaptation layer, and aggregates the multiple event consumption data into a single heterogeneous metering data based on a preset aggregation strategy. The processing unit identifies the resource types contained in the heterogeneous metering data, queries a preset resource indicator mapping rule based on the resource types, and converts the original consumption values ​​in the heterogeneous metering data into standardized metering indicators and standardized values ​​corresponding to the standardized metering indicators according to the obtained preset resource indicator mapping rule, thereby generating normalized metering data containing tenant information, the standardized metering indicators, and the standardized values; obtains the user status corresponding to the tenant information, the user status including at least a pricing plan, discount rules, and account information; processes the normalized metering data through a multi-level pipeline billing engine, and converts the standardized values ​​into pre-discount fees based on the pricing plan and the standardized metering indicators to obtain approved billing items; The pre-priced billing item is processed in the discount processing stage of the multi-level pipeline billing engine. Based on the discount rules, the pre-discount fee is processed to obtain the final post-discount fee and generate the discounted billing item. The uploading unit enables the discounted billing item to be processed in the accounting stage of the multi-level pipeline billing engine, performs accounting processing on the account information based on the final cost after the discount, generates a transaction record recording the current expense, and stores the transaction record in the accounting database.

9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

Images