Business processing method and apparatus

Abstract

The embodiment of the application provides a service processing method and device, the method comprises the following steps: a server sends a charging request message to a charging platform, the charging request message comprises at least one consumption data, wherein each consumption data comprises the generation time of the consumption data and the debiting service specification of a target service. The server adjusts the quantity and / or sending interval of the consumption data sent to the charging platform next time in response to the indication of the charging platform, so as to realize the dynamic adjustment of the consumption data reporting rate on the server side.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a service processing method and apparatus. Background Technology

[0002] With the development of the Internet and the maturity of various cloud-based business models, more and more service providers have emerged that offer specific professional services. For example, SMS sending service providers can offer individual developers a very easy-to-use and simple-to-integrate SMS sending service (also known as SMS sending business), allowing individual developers to focus on their application development without having to pay too much attention to building the capabilities related to sending SMS messages.

[0003] Service providers (also known as merchants) typically focus solely on their own business in their capability architecture, often outsourcing the development of common capabilities to specialized platforms. For example, taking SMS sending service providers as an example, a merchant can offer SMS sending services to individual users, but the consumption data generated from this service is sent to a SaaS (Software as a Service) billing platform for billing and other related functions. Current billing systems (including those for individual developers, merchants, and billing platforms) typically rely on merchants reporting consumption data at fixed intervals or in real-time. This simplistic reporting method often leads to a decrease in overall system processing speed or waste of system resources. Summary of the Invention

[0004] This application provides a business processing method and apparatus that can dynamically adjust business processing capabilities.

[0005] Firstly, embodiments of this application provide a business processing method. This method is applied to a server and includes: At a first moment, the server sends a first billing request message to a billing platform. The first billing request message includes m1 pieces of consumption data, and is used to request the billing platform to bill and issue charges for the m1 pieces of consumption data. m1 is a positive integer greater than 0. Next, the server receives a first billing request response message sent by the billing platform, wherein the first billing request response message includes first billing success indication information and first consumption data transmission parameters. The first billing success indication information is used to instruct the billing platform to complete the billing and issuing of charges for the m1 pieces of consumption data, and the first consumption data transmission parameters are used to indicate a first period duration and the number of first consumption data sent. Subsequently, at a second moment, the server sends a second billing request message to the billing platform. The second billing request message includes m2 pieces of consumption data, and is used to request the billing platform to bill and issue charges for the m2 pieces of consumption data. In this embodiment, the time difference between the first and second moments is the duration of the first cycle, and m2 equals the number of first consumption data transmissions; m2 is a positive integer greater than 0, and m2 is different from m1. In this embodiment, single consumption data is generated by the server after providing the target service to the user based on the user's business needs. Furthermore, single consumption data includes time information and billing service specification information. The time information indicates the generation time of the single consumption data, and the billing service specification information indicates the billing service specification corresponding to the target service. Thus, the merchant server can dynamically adjust the amount and interval of consumption data transmission based on the instructions of the billing platform, thereby achieving dynamic adjustment of the server-side consumption data reporting rate. Additionally, the billing platform dynamically configures the server's reporting rate based on the server's billing service specifications and the backlog of consumption data, effectively balancing the overall reporting efficiency of the system and improving the reliability and efficiency of the overall business data processing.

[0006] For example, the billing platform can determine the consumption data transmission parameters corresponding to each server based on the request messages sent by each server. The consumption data transmission parameters may be the same or different for each server.

[0007] For example, if the billing platform determines that the period duration corresponding to the server remains unchanged, the consumption data transmission parameters may not include the period duration, in order to indicate that the current period duration is the same as the previous period duration.

[0008] For example, the consumption data is generated when the server provides the server to the user based on the user's needs.

[0009] For example, billing service specifications include fast billing server specifications, medium billing service specifications, and slow billing service specifications. Each server corresponds to one specification. For example, different billing service specifications correspond to different service levels and costs.

[0010] For example, the merchant's server and the user's terminal are pre-registered and logged in on the billing platform. Furthermore, both the merchant and the user have accounts on the billing platform.

[0011] For example, the billing platform may bill consumption data by calculating the total cost of multiple consumption data based on the merchant's billing specifications. The billing platform may also bill consumption data by deducting fees from the user's account and transferring the deducted fees to the merchant's account.

[0012] In one possible implementation, m1 consumption data points are the consumption data from n1 consumption data points cached by the server before the first time step; m2 consumption data points are the consumption data from n2 consumption data points cached by the server before the second time step; n1 and n2 are both positive integers greater than 0, and n1 and n2 may be the same or different. In this way, the merchant's server can send all or part of the consumption data cached locally to the billing platform, thereby reducing the caching pressure on the merchant's server. Furthermore, the merchant server's caching function reduces the risk of data loss during reporting, ensuring that data on the merchant's server is not lost in the event of server failure.

[0013] For example, different merchant servers may have the same or different cache capacities.

[0014] In one possible implementation, n1 data items are cached in at least one of the server's first, second, and third cache regions; the read rate of the first cache region is higher than that of the second cache region, and the read rate of the second cache region is higher than that of the third cache region. In this way, the merchant's server side effectively avoids data overflow issues when dealing with large amounts of data through multi-level caching.

[0015] In one possible implementation, the first and second cache regions reside in the server's memory, while the third cache region resides on the server's hard drive. This effectively increases the cache capacity by establishing cache regions on the hard drive, preventing data overflow issues. Furthermore, establishing cache regions in memory significantly improves data access speed.

[0016] In one possible implementation, the first billing request message also includes cache status information, indicating the cache status of the first, second, and third cache areas. This allows the merchant server to report the current cache status to the billing platform in real time, enabling the platform to update the merchant's cache capacity based on the cache status, billing specifications, and data backlog. This ensures the merchant's cache always adapts to its reporting rate. For example, when the reporting rate is low, the merchant can increase the cache size to prevent data overflow. When the reporting rate is high, the merchant can increase the first-level cache size to improve read speed.

[0017] In one possible implementation, the first billing request response message further includes cache state update information, which indicates the need to update the capacity of at least one of the first, second, and third cache regions. The method further includes: the server responding to the cache state update information by updating the capacity of at least one of the first, second, and third cache regions. This allows the merchant server to dynamically adjust the cache regions, preventing data overflow while maintaining data read speed.

[0018] In one possible implementation, the method further includes: the server receiving a second billing request response message from the billing platform, the second billing request response message including second billing success indication information and second consumption data transmission parameters; the second billing success indication information is used to instruct the billing platform to complete the billing and billing of m2 consumption data; the second consumption data transmission parameters are used to indicate the second cycle duration and the number of second consumption data sent; the second cycle duration is different from the first cycle duration, and the number of second consumption data sent is different from the number of first consumption data sent; at a third moment, a third billing request message is sent to the billing platform, the third billing request message including m3 consumption data, the third billing request message is used to request the billing platform to bill and bill the m3 consumption data; wherein, the time difference between the third moment and the second moment is the second cycle duration, m3 is equal to the number of second consumption data sent; m3 is a positive integer greater than 0, and m3, m2 are different from m1. In this way, merchants can dynamically adjust the number of consumption data sent and the reporting interval based on the instructions of the billing platform, thereby realizing the dynamic adjustment of the consumption data reporting rate.

[0019] In one possible implementation, the method further includes: the server receiving a third billing request response message sent by the billing platform, the third billing request response message including billing failure indication information; the billing failure indication information is used to indicate that the billing and billing of m2 consumption data failed.

[0020] For example, if the billing platform detects a billing and / or billing failure, it sends a failure indication message to the merchant server. For instance, if the billing platform detects insufficient funds in a user's account, it sends a failure indication message to the merchant server so that the merchant server can promptly stop providing the target service to the user, thereby preventing losses for the merchant.

[0021] In this embodiment, some merchants are latency-sensitive and have a higher reporting rate. The billing platform can promptly bill and issue charges for the consumption data of these merchants, thereby preventing insufficient user balances and resulting losses for the merchants. For example, some merchants are not latency-sensitive, and the billing platform can dynamically adjust their reporting rate, allowing them to report data more slowly, thus allocating more resources to process the consumption data of latency-sensitive merchants.

[0022] In one possible implementation, the method also includes: the server stopping providing the target service to the user.

[0023] In one possible implementation, before sending the first billing request message to the billing platform, the process includes: the server obtaining the billing service specification from the billing platform; the billing service specification is pre-set. This allows merchants to pre-set their billing service specifications according to their actual needs, enabling the billing platform to dynamically adjust the consumption data reporting rate of different merchant servers based on these specifications. For merchants with higher billing service specifications and / or larger backlogs of consumption data, the billing platform can prioritize allocating resources to these merchants to process their consumption data, thereby meeting the needs of merchants with high-specification billing services while preventing excessive backlogs of consumption data for merchants with low-specification billing services.

[0024] Secondly, embodiments of this application provide a business processing apparatus. This apparatus is applied to a server and includes: a memory and a processor; the memory and processor are coupled; the memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, the apparatus performs the following steps: at a first moment, sending a first billing request message to a billing platform, the first billing request message including m1 consumption data points, the first billing request message being used to request the billing platform to bill and issue charges for the m1 consumption data points; m1 is a positive integer greater than 0; receiving a first billing request response message sent by the billing platform, the first billing request response message including first billing success indication information and first consumption data transmission parameters; the first billing success indication information being used to instruct the billing platform to complete the billing and issuing of charges for the m1 consumption data points; the first consumption data transmission... The parameters are used to indicate the duration of the first period and the number of first consumption data sent. At the second moment, a second billing request message is sent to the billing platform. The second billing request message includes m2 consumption data items and is used to request the billing platform to bill and issue charges for the m2 consumption data items. The time difference between the first moment and the second moment is the duration of the first period, and m2 is equal to the number of first consumption data items sent. m2 is a positive integer greater than 0 and is different from m1. The single consumption data is generated by the server after providing the target service to the user based on the user's business needs. The single consumption data includes time information and billing service specification information. The time information is used to indicate the generation time of the single consumption data, and the billing service specification information is used to indicate the billing service specification corresponding to the target service.

[0025] In one possible implementation, m1 consumed data are consumed data from n1 consumed data cached by the server before the first time step; m2 consumed data are consumed data from n2 consumed data cached by the server before the second time step; n1 and n2 are both positive integers greater than 0, and n1 and n2 may be the same or different.

[0026] In one possible implementation, n1 data are cached in at least one of the server's first, second, and third cache regions; the read rate of the first cache region is higher than that of the second cache region, and the read rate of the second cache region is higher than that of the third cache region.

[0027] In one possible implementation, the first and second cache regions are located in the server's memory, and the third cache region is located in the server's hard disk.

[0028] In one possible implementation, the first billing request message also includes cache status information, which is used to indicate the cache status of the first cache area, the cache status of the second cache area, and the cache status of the third cache area.

[0029] In one possible implementation, the first billing request response message further includes cache state update information, which is used to indicate updating the capacity of at least one of the first cache region, the second cache region, and the third cache region. When the processor executes computer instructions, the device performs the following steps: in response to the cache state update information, updating the capacity of at least one of the first cache region, the second cache region, and the third cache region.

[0030] In one possible implementation, when the processor executes computer instructions, the device performs the following steps: receiving a second billing request response message sent by a billing platform, the second billing request response message including second billing success indication information and second consumption data transmission parameters; the second billing success indication information is used to instruct the billing platform to complete the billing and billing of m2 consumption data; the second consumption data transmission parameters are used to indicate the second cycle duration and the number of second consumption data sent; the second cycle duration is different from the first cycle duration, and the number of second consumption data sent is different from the number of first consumption data sent; at a third moment, sending a third billing request message to the billing platform, the third billing request message including m3 consumption data, the third billing request message is used to request the billing platform to bill and bill the m3 consumption data; wherein, the time difference between the third moment and the second moment is the second cycle duration, m3 is equal to the number of second consumption data sent; m3 is a positive integer greater than 0, and m3, m2 are different from m1.

[0031] In one possible implementation, when the processor executes computer instructions, the device performs the following steps: receiving a third billing request response message sent by the billing platform, the third billing request response message including billing failure indication information; the billing failure indication information is used to indicate that the billing and billing of m2 consumption data failed.

[0032] In one possible implementation, when the processor executes computer instructions, it causes the device to perform the following steps: stop providing the target service to the user.

[0033] In one possible implementation, when the processor executes computer instructions, the device performs the following steps: before sending a first billing request message to the billing platform, it obtains a billing service specification from the billing platform; the billing service specification is pre-set.

[0034] Thirdly, embodiments of this application provide a computer-readable medium for storing a computer program, the computer program including instructions for performing the method in the first aspect or any possible implementation of the first aspect.

[0035] Fourthly, embodiments of this application provide a computer program including instructions for performing the method in the first aspect or any possible implementation thereof.

[0036] Fifthly, embodiments of this application provide a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes all or part of the method steps in the first aspect or any possible implementation of the first aspect to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

[0037] Sixthly, embodiments of this application provide a system including the server and billing platform described in the first aspect above. For example, the billing platform may include at least one billing server. Attached Figure Description

[0038] Figure 1 This is a schematic diagram illustrating the business process of a billing system as an example.

[0039] Figure 2 This is a schematic diagram of the structure of an exemplary billing system;

[0040] Figure 3 This is a schematic diagram illustrating the business process of a billing system as an example.

[0041] Figure 4 This is a schematic diagram of an exemplary billing platform configuration page;

[0042] Figure 5 This is a schematic diagram illustrating an exemplary business process.

[0043] Figures 6a-6b The diagram shown is a schematic of the cache structure.

[0044] Figures 7a to 7d This is a schematic diagram illustrating an exemplary business process.

[0045] Figure 8 This is an example illustration of changes in the number of reported consumption data.

[0046] Figure 9 This is a schematic diagram of the billing platform structure as an example.

[0047] Figure 10 This is a schematic diagram of the structure of an exemplary device. Detailed Implementation

[0048] The technical solutions in the embodiments of this application 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.

[0049] Figure 1 This is a schematic diagram of the business process of a billing system, as exemplarily shown. Please refer to... Figure 1 The billing system includes three roles: user, merchant, and billing platform. For example, the user role can be a mobile phone, computer, server, wearable device, etc. The merchant role can be a server, client (which can be a client provided by a computer or other device, or a client provided by a server), etc. The billing platform role can be a server or a server cluster. In the entire process, the user uses the merchant's service, generating consumption data. The merchant transmits this consumption data to the billing platform, which then performs the billing and collection functions, converting this consumption data into fees, and settles accounts with the user and merchant to generate a bill. For further explanation, we will continue with the SMS sending service example described above. Please refer to [link / reference]. Figure 1 The specific steps include, but are not limited to:

[0050] S101, users recharge and apply for merchant services through the billing platform.

[0051] For example, a user can be an individual developer. The billing platform can provide a user-side client, which users can log in to via a terminal (or other devices; this embodiment only uses a terminal as an example). For instance, a user can open the webpage corresponding to the billing platform's user-side client on the terminal. Users can complete user registration on the webpage, such as creating a user account, including username, password, and other information. Users can then top up their registered accounts in the client for subsequent payments.

[0052] For example, users can also select a specific merchant through the webpage corresponding to the client, which can also be understood as activating a specific service. In this example, taking SMS sending service as an example, users can choose to activate SMS sending service, and the corresponding merchant for this service is the SMS sending provider. Optionally, a merchant usually only provides one service (or business), for example, an SMS sending service provider provides SMS sending service, and an advertising service provider provides advertising service, etc.

[0053] The billing platform responds to user settings on the client, creating accounts and topping up user accounts. It also associates users with designated merchants. For example, the billing platform can send instructions to designated merchants, directing users to associate with those merchants who can provide related services to them.

[0054] For example, each merchant pre-registers an account on the billing platform, including a merchant name and password. Merchants can also set service information, specifying the services they offer and their prices. For instance, an SMS provider could set its service as SMS sending and charge 0.1 yuan per SMS sent.

[0055] S102, the user sends a business request to the merchant.

[0056] For example, a user can send a business request to a designated merchant. Let's continue with the SMS sending scenario. An individual developer (e.g., a shop or game developer) needs to send SMS messages to customers regularly (e.g., weekly). The developer can send a business request to the merchant, which includes a customer list and the SMS content, instructing the merchant to send SMS messages with specified content to customers in the customer list.

[0057] S103, Merchants provide services to users according to their business needs.

[0058] For example, in response to a received business request, a merchant can perform relevant services according to the business request. For instance, a merchant can send a text message with specified content to each customer in a customer list based on the business request.

[0059] S104, Merchants send consumption data to the billing platform.

[0060] For example, each time a merchant performs a business transaction according to its business needs, it provides a service to the user and is recorded as a consumption record (also known as user consumption data). The merchant sends a billing request message to the billing platform, which includes the consumption data, to request the billing platform to process the billing.

[0061] Taking SMS sending service as an example, each SMS sent by a merchant is recorded as a consumption record. Consumption data includes, but is not limited to, relevant information such as consumption time and service recipient. The consumption time is the time the merchant sends the SMS. The service recipient is the object corresponding to this service. For example, if a merchant sends SMS messages to multiple terminals based on user A's business needs, then the service recipient is user A.

[0062] In one possible implementation, the merchant can agree on a reporting cycle with the billing platform. For example, during registration, the reporting cycle length can be agreed to be one hour, meaning the merchant reports consumption data every hour. For instance, after each SMS message is sent, the merchant records and saves the consumption data. When the reporting cycle is triggered, the merchant sends a billing request message to the billing platform, which includes the consumption data generated within the current cycle. It should be noted that in this embodiment, the consumption data sent by the merchant to the billing platform is a file of a specified type generated according to the format required by the billing platform. The specific type can be set according to actual needs, and this application does not limit it.

[0063] In another possible implementation, merchants can send consumption data to the billing platform after each consumption record is generated. For example, after a merchant sends an SMS message, a consumption record is generated. The merchant then sends a billing request message to the billing platform, which includes the generated consumption data. In other words, the merchant sends a consumption record to the billing platform for each SMS message sent.

[0064] For example, merchants can interact with the billing platform by calling the interface provided by the billing platform.

[0065] S105, the billing platform bills and issues charges.

[0066] S106, the billing platform indicates to the merchant that the user's balance is insufficient.

[0067] For example, the billing platform obtains the consumption data sent by the merchant. Based on the price agreed upon by the merchant (the details of the price agreement can be found in the relevant content in S101), the billing platform calculates the price corresponding to each piece of consumption data, that is, the actual expense incurred by the consumption data (i.e., fees, amounts, etc., which are not limited in this application and will not be repeated below).

[0068] After calculating the charges, the billing platform issues a payment. This process involves the billing platform deducting the charge from the user's account and transferring the deducted amount to the merchant's account. For example, the billing platform can identify the corresponding user and obtain their account based on the service recipients included in the consumption data. Optionally, the service recipients in the consumption data can be user names or other identifying information, and the billing platform can find the corresponding user account based on the user name or other identifying information in the consumption data.

[0069] Optionally, billing may also include, but is not limited to, recording this billing event. Billing events include, but are not limited to: the time the consumption data was generated, the billing time (which could be the time after the fee was calculated, the time the fee was deducted from the user's account, or the time the fee was transferred to the merchant's account; this application does not impose any limitations on this), billing delay, the user's account name, the merchant's account name, the amount deducted from the user's account and the amount transferred to the merchant's account, the user's balance, and the merchant's balance. The billing delay may optionally be the time between the merchant generating the user's consumption data and the billing platform completing the billing process. It should be noted that the billing platform generates a corresponding billing event for each piece of consumption data it processes.

[0070] In one possible implementation, as described above, the merchant can send consumption information to the billing platform at regular intervals. This consumption information includes consumption data for the current period. In this example, the billing platform receives the consumption information and retrieves the consumption data from it. The billing platform calculates the cost of each consumption data entry and the sum of all consumption data for each user within the period. For example, the merchant sends 10 SMS messages based on user A's business needs and 5 SMS messages based on user B's business needs within the current period. The merchant generates 10 consumption data entries for user A and 5 for user B within the current period. At the period trigger, the merchant sends a billing request message to the billing platform. This message includes, but is not limited to, the 10 consumption data entries for user A and the 5 consumption data entries for user B. Each consumption data entry for user A includes, but is not limited to, the consumption data generation time and user A's name. Each consumption data entry for user B includes, but is not limited to, the consumption tree generation event and user B's name. The billing platform receives the billing request message and retrieves 15 of these consumption data entries. In one example, the billing platform can sort the received consumption data and bill each piece of consumption data sequentially. Optionally, the sorting method can be based on the order of the consumption data in the billing request message, or it can be understood as the order in which the billing platform receives the data. Optionally, the sorting method can also be based on the generation time of the consumption data; this application does not limit this. In another example, the billing platform can perform unordered billing, that is, it does not sort the received consumption data and calculates the cost of each piece of consumption data sequentially. It should be noted that in this embodiment of the application, the billing platform can deduct the corresponding cost from the user's account and transfer the funds to the merchant's account for each piece of user consumption data. In other embodiments, the billing platform can also calculate all the user's costs within the period before deducting the user's cost and transferring the funds to the merchant's account. For example, the billing platform calculates the cost of 1 yuan for 10 consumption records of user A and the cost of 0.5 yuan for 5 consumption records of user B. The billing platform deducts 1 yuan from user A's account, deducts 0.5 yuan from user B's account, and transfers 1.5 yuan to the merchant's account.

[0071] In another possible implementation, as described above, each time a merchant generates a consumption record, they can send a billing request message containing the consumption data to the billing platform. In this example, the billing platform receives a billing request message, retrieves the consumption data from it, and bills for the consumption data. Based on the billing result, the billing platform deducts the corresponding amount from the user's account and transfers the funds to the merchant's account.

[0072] Optionally, if the billing platform successfully issues the bill—that is, successfully deducts the consumption fee from the user's account and transfers the funds to the merchant—the billing platform sends a billing request confirmation message to the merchant to indicate that the billing and issuance were successful. Optionally, the billing request confirmation message may carry all or part of the information from the billing event, such as information other than the user's balance and account name. Optionally, the billing request confirmation message may also exclude the relevant information from the billing event, and the billing platform will store the billing event locally. The merchant's operations personnel can query the billing event through the merchant client provided by the billing platform.

[0073] Optionally, if the billing platform fails to process the bill, for example, if the user's account balance is insufficient to deduct the current consumption fee, the billing platform executes S106, that is, the billing platform sends a billing request failure message to the merchant to indicate that the billing has failed. In one example, the billing platform can deduct the entire balance in the user's account and transfer the deducted amount to the merchant's account, and then send a billing request failure message to the merchant. In another example, the billing platform deducts the current consumption fee from the user's account, and the insufficient balance is represented by a negative amount. For example, suppose the current consumption fee is 10 yuan, and the user's account balance is 5 yuan. The billing platform deducts 5 yuan from the user's balance and updates the user's balance to -5 yuan. The billing platform transfers the deducted 5 yuan to the merchant's account and sends a billing request failure message to the merchant. Exemplarily, the billing request failure message may include all or part of the information of the billing event, such as information other than the user's balance and user's account name in the billing event, which is not limited in this application.

[0074] Optionally, if the billing platform fails to process the billing, it can send a low balance notification message to the corresponding user, indicating that the user's account has insufficient funds. Upon receiving this message, the user can recharge their account through the billing platform's user client.

[0075] For example, if a merchant receives a billing request confirmation message from the billing platform, the merchant can continue to provide services to the user corresponding to the billing request confirmation message. For instance, if a merchant receives a billing request confirmation message and determines that the user who successfully paid this time is user A based on the billing event in the message, the merchant can continue to provide SMS sending services to user A.

[0076] For example, upon receiving a billing request failure message from the billing platform, the merchant ceases providing services to the corresponding user. For instance, upon receiving a billing request failure message, the merchant, based on the billing event in the message, determines that the user whose payment failed is user B, and the merchant stops providing SMS sending services to that user. Optionally, the merchant can send a service termination notification message to the user (referring to the terminal logged into the user's account) to instruct the merchant to stop providing services to that user. Optionally, the merchant can also send a service termination notification message through the billing platform; this application does not limit this. For example, after receiving the service termination notification message, the user's terminal displays the service termination notification information on the display interface to prompt the merchant to stop providing services to that user. The user can recharge through the user client provided by the billing platform. After successful recharge, the billing platform can send a recharge notification message to the merchant to instruct the user that the recharge was successful. After receiving the recharge notification message, the merchant can continue to provide services to that user. Of course, in other embodiments, after determining that a user's balance is insufficient, the merchant may continue to provide services to the user for a period of time (e.g., 3 days, which can be set according to actual needs; this application does not limit this). After the preset time period, if the user has successfully recharged, that is, after the merchant receives a billing request success message from the billing platform, the merchant may continue to provide services to that user. After the preset time period, if the user has still not recharged, that is, the message received by the merchant is still a billing request failure message, the merchant will stop providing services to that user.

[0077] It's important to note that a crucial step in the entire process is the rate at which merchants report user consumption data to the billing platform. In this embodiment, the reporting rate of consumption data affects the billing platform's final billing and payment processing time, typically measured by payment latency. Payment latency is a critical parameter for the billing platform, and different merchants have varying sensitivities to it. For example, cloud server rental service providers have payment latency on the order of hours; meaning that even if the cloud service provider reports consumption data every hour, it won't significantly impact their costs (the impact is negligible). However, advertising service providers may receive numerous user requests in a short period, such as 1000 ad clicks within one minute. Consequently, advertising service providers have higher requirements for payment latency, typically requiring it to be on the order of seconds.

[0078] However, as mentioned above, current merchant reporting methods are typically periodic or reported every time a transaction is recorded. With periodic reporting, the need for users to periodically aggregate transaction data over a specific period before uploading it to the billing platform results in significant billing delays. By the time a merchant receives a message from the billing platform indicating insufficient user balance, a considerable amount of time may have already passed. For example, an advertising service provider might generate 1000 clicks per minute. If it reports transaction data every minute, by the time it receives the insufficient balance message, the user may have already generated nearly 1000 clicks before the merchant stops providing service. Therefore, for merchants highly sensitive to billing delays, periodic reporting may lead to losses. The method of reporting consumption data in real-time, i.e., reporting each consumption data point as it is generated, may encounter a situation where a sudden surge in user consumption data due to a hot event may overwhelm the billing platform, making it unable to handle the excessive amount of data. Furthermore, the billing platform may be unable to process consumption data exceeding its processing threshold (which can be set according to actual needs; this application does not impose any limitations). To cope with scenarios involving a surge in consumption data, existing technologies may employ billing platform expansion, such as increasing the number of servers, to improve the billing platform's processing capacity. However, this approach will result in resource waste during off-peak hours (i.e., when the amount of consumption data received is relatively small).

[0079] To address the aforementioned issues, this application provides a business processing method that can dynamically configure the reporting rate of consumption data for merchants, thereby improving the resource utilization of the billing system while ensuring the overall billing delay.

[0080] Figure 2 This is a schematic diagram illustrating the structure of an exemplary billing system. Please refer to... Figure 2 The billing system includes users, merchants, billing platforms, and cloud platforms.

[0081] For example, a merchant, also known as a merchant role, includes merchant operators, merchant terminals, and merchant servers. The merchant terminal can be a mobile phone, wearable device, computer, etc., and this application does not limit its scope. Figure 3 As shown, merchant operations personnel can register and log in to the billing platform configuration page corresponding to the merchant client provided by the billing platform through the merchant terminal. On the billing platform configuration page, merchant operations personnel can set billing delay specifications, query purchased billing delay specifications, query the remaining credit limit for purchased billing delay specifications, query billing events for billed consumption data, and query the amount in the merchant account, etc.

[0082] Still refer to Figure 3 For example, the billing platform can synchronize the information that needs to be displayed to the billing platform configuration page, so that the merchant's operators can log in to the page through the terminal and query the relevant information on the page.

[0083] It should be noted that this application embodiment only uses the merchant client's corresponding billing platform configuration page as an example for illustration. In other embodiments, merchant operators may also select billing delay specifications and other steps through SMS or other means, and this application does not limit this.

[0084] In this embodiment, the billing latency specifications include three types: fast billing, medium billing, and slow billing. The fast billing specification includes a billing latency (see above for details) of less than 1 minute, the ability to process 100,000 transaction records per month, and a fee of 200 yuan. The medium billing specification includes a billing latency of less than 10 minutes, the ability to process 100,000 transaction records per month, and a fee of 50 yuan. The slow billing specification includes a billing latency of less than 60 minutes (i.e., 1 hour), the ability to process 100,000 transaction records per month, and a fee of 20 yuan. By providing different billing latency specifications, the billing platform in this embodiment allows merchants to choose the appropriate specification based on their business characteristics and needs, thus meeting the diverse requirements of different merchants.

[0085] It should be noted that the billing specifications and contents of each specification described in the embodiments of this application are merely illustrative examples. In other embodiments, fewer or more specifications may be included, and each specification may include fewer or more contents. This application does not limit the scope of the embodiments.

[0086] Figure 4 For an illustrative example of a billing platform configuration page, please refer to... Figure 4 The billing platform configuration page includes the billing service specification selection area 401 (also known as the billing delay specification), the specification and balance query area 402, and the billing query area 403.

[0087] For example, the billing service specification selection area 401 includes three specifications provided by the billing platform and the corresponding content for each specification. Merchant operators can select the corresponding billing specification on the page. For example, in response to the received operation, the merchant terminal sends an instruction message to the billing platform to indicate the billing specification selected by the merchant. In response to the received instruction message, the billing platform determines the billing specification selected by the user. For example, the merchant operator can also change the specification in the billing specification selection area 401. For example, if the medium-speed billing specification is currently selected, the operator can click on the slow-speed billing specification on the page. In response to the received operation, the merchant terminal sends an instruction message to the billing platform to instruct the merchant to select a billing specification that meets the requirements. In response to the received instruction message, the billing platform can immediately modify the merchant's billing specification or change it in the next cycle (e.g., next month), which is not limited in this application.

[0088] For example, the specification and remaining quantity query area 402 includes, but is not limited to, information on purchased specifications, remaining billing quantity, and remaining time. For instance, taking a merchant's purchase of a medium-speed billing specification as an example, the purchased specification information indicates that the billing specification purchased by the merchant is medium-speed billing. The remaining billing quantity information indicates the quantity of billing specifications already used by the merchant. For example, medium-speed billing corresponds to processing 100,000 consumption data entries per month. If the merchant requests the billing platform to process 80,000 consumption data entries this month, then the remaining billing quantity for the medium-speed billing specification is 20,000 entries. For example, the remaining time information indicates the remaining time for the billing specification. For example, if the medium-speed billing specification corresponds to 30 days (i.e., 1 month), and the starting date is the merchant's purchase date, for example, if the merchant has used the medium-speed billing specification for 9 days, then the remaining time indicates 21 days remaining.

[0089] For example, the billing query area 403 includes, but is not limited to, at least one of the following: order number information, generation time information, billing event information, and delay information (i.e., billing delay information). The order number information can be sorted according to the order of the billing events corresponding to the received consumption data (see above for a conceptual explanation). That is, each time the billing platform completes the billing for a merchant's consumption data, it generates a corresponding billing event and generates the corresponding order number according to the order in which the billing events are generated. For example, the generation time information indicates the generation time of the consumption data, which is obtained by the billing platform from the consumption data sent by the merchant. Specific details can be found above and will not be repeated here. For example, the billing time is recorded as the time when the billing platform completes the billing for a consumption data item. Specific details can be found above and will not be repeated here. The delay information, recorded as billing delay information, indicates the duration between the generation time and the billing time. For an example, please refer to... Figure 4The billing platform bills and issues charges for merchant's consumption data 1. Upon successful billing, it records and saves the billing event, which includes, but is not limited to: consumption data generation time, billing time, billing delay, user's account name, merchant's account name, amount deducted from user's account and amount transferred to merchant's account, user's balance, and merchant's balance. The billing platform can synchronize partial information from the billing event—generation time, billing time, and billing delay—to the billing platform configuration page. For example, for the table entry corresponding to order number 0, the generation time is 9:00:00, the billing event is 9:00:50, and the billing delay is 50 seconds. Next, the billing platform bills and issues charges for merchant's consumption data 2, and upon successful billing, records and saves the billing event. The billing platform updates the information displayed on the page, such as the table entry corresponding to order number 1, which was generated at 9:01:00, the billing event was at 9:02:00, and the billing delay was 2 minutes.

[0090] It should be noted that the time when the billing platform displays the entry may differ from the actual time when the billing event is generated; this application does not impose any restrictions on this.

[0091] It should be further noted that the billing query area 403 may also display more or less information about the billing event, which is not limited in this application.

[0092] For example, when a merchant first accesses the billing platform—that is, after registering and logging into the billing platform for the first time—the merchant executes the billing specification selection process described above. After selecting the billing specification, the merchant's server can obtain the SDK (Software Development Kit) from the billing platform. For example, the billing platform's operators pre-configure the SDK on the billing platform's server. It should be noted that the billing platform may include SDKs for performing different functions. The SDK described in this embodiment can be used by the merchant's server to execute the business processing flow of this embodiment after running the SDK.

[0093] For example, in this embodiment, after the merchant server runs the SDK, it can call the corresponding interfaces of the SDK to complete the initialization configuration of caching and other related parameters, and report (i.e., send) consumption data to the billing platform. Furthermore, after the merchant server runs the SDK, the SDK can complete the initialization configuration based on the merchant server's instructions and provide the merchant server with an interface for interacting with the billing platform. The SDK also performs operations such as obtaining billing delay specifications from the billing platform, caching consumption data and adding tags to the consumption data, receiving cache status update information and consumption data transmission parameters from the billing platform, modifying the SDK's cache status according to the received cache status update information, and adjusting the rate at which the merchant server sends consumption data to the billing platform according to the received consumption data transmission parameters. Specific implementation details will be provided in the following embodiments.

[0094] Optionally, after detecting that a merchant has selected a billing specification, which can also be interpreted as confirming that the merchant will use the billing platform's services, the billing platform may send an SDK to the merchant's server. Optionally, the merchant's server may also send an SDK request to the billing platform. In response to the received SDK request, the billing platform will send the SDK to the merchant's server. The specific acquisition method can be set according to actual needs, and this application does not impose any restrictions.

[0095] It should be noted that the merchant mentioned in the embodiments of this application refers to the merchant role, which can refer to the merchant operator performing the corresponding operation through the terminal, or to the merchant server performing the corresponding operation, which will not be elaborated further below.

[0096] Please continue to refer to Figure 2 For example, a user, also known as a user role, is the individual developer mentioned above. A user may include the individual developer and the terminal used by the user, such as a server, mobile phone, wearable device, tablet, etc., which are not limited in this application. An individual developer can send business requests to merchants based on the terminal. For example, individual developer A (i.e., user A) can send an SMS service request message to merchant A through the terminal. The SMS service request message is used to request merchant A to provide SMS sending services. The SMS service request message may include a customer list and SMS content. Individual developer B (user B) can send a broadcast service request message to merchant B through the terminal. The advertising service request message is used to request merchant B to provide advertising services, such as displaying user B's advertising interface in a designated area of ​​merchant B's app store. For example, users can also perform registration, login, and recharge operations on the page corresponding to the user client provided by the billing platform. The parts not described can be referred to above and will not be repeated here.

[0097] Still refer to Figure 2For example, a billing platform, or billing platform role, can include a server or server cluster. The billing platform can configure parameters corresponding to the merchant's SDK, such as cache status update information, based on the current cache status of the SDK reported by the merchant. Furthermore, the billing platform can adjust the rate at which merchants report consumption data based on the consumption data reported by the merchants. For example, the billing platform can also be used to notify relevant subscribers (including users and / or merchants) when insufficient user balance is detected. For example, in this embodiment, the billing platform can also dynamically scale up and down based on the billing latency specifications subscribed by the merchant, thereby avoiding resource waste while ensuring business needs are met.

[0098] For example, a cloud platform is used to provide server resources to a billing platform to provide sufficient hardware support when the billing platform is expanded. The cloud platform may include a server cluster.

[0099] Combination Figure 2 , Figure 5 For an illustrative business process diagram, please refer to... Figure 5 Specifically, it includes:

[0100] S501, Merchant configuration SDK parameters.

[0101] For example, after a merchant operations staff member registers and logs in to the billing platform through the merchant terminal, the merchant terminal displays... Figure 4 The interface is as follows. Merchant operators can select the corresponding billing specifications on the page. In this embodiment, we will take Merchant A selecting the slow billing specification (also known as slow billing service) and Merchant B selecting the fast billing specification (also known as fast billing service) as an example. After Merchant A and Merchant B select the corresponding specifications, Merchant A and Merchant B (specifically, their servers) obtain the SDK from the billing platform. Merchant A and Merchant B install and run the SDK. It should be noted that the steps performed by the SDK in this embodiment can also be understood as the steps performed by the merchant server when it runs the SDK program instructions, which will not be repeated below.

[0102] For example, the merchant server's SDK configuration parameters include, but are not limited to: the merchant allocating a corresponding cache region for the SDK, and the cache region being used to cache consumption data. For example, the merchant server includes different cache regions, each corresponding to a different function, or it can be understood that different cache regions are invoked by different program instructions. The merchant server configures a cache region for the SDK, which is used to store SDK-related data, such as consumption data.

[0103] For example, in this embodiment of the application, the cache regions include, but are not limited to, level 1 cache, level 2 cache, and level 3 cache.

[0104] Figure 6a The diagram shown is a schematic of the cache structure. Please refer to it. Figure 6a For example, the merchant server allocates a first-level cache, a second-level cache, and a third-level cache for the SDK.

[0105] For example, the first-level cache may optionally use the merchant server's memory as its storage medium, meaning the storage path for the first-level cache is the merchant server's memory. The data structure of the first-level cache may optionally be an array. Setting the first-level cache in memory ensures maximum read and delete speeds for the cached data. Optionally, the first-level cache may support unordered characteristics, meaning the data stored in the cache is unordered; that is, when the merchant server inserts data into the first-level cache, the data in the first-level cache does not need to be sorted according to its creation time.

[0106] For example, the second-level cache may optionally use the merchant server's memory as its storage medium, meaning the storage path for the second-level cache is the merchant server's memory. Optionally, the second-level cache may use a red-black tree as its data structure, and the data in the second-level cache can be stored in an ordered manner. For example, it can be stored according to data priority; for example, the data priority may be based on the generation time of the consumption data, or it may be sorted according to the priority of the user corresponding to the consumption data. This application does not impose any limitations.

[0107] For example, the three-level cache may optionally use the merchant server's hard drive as its storage location; that is, the storage path of the three-level cache is the merchant server's hard drive. Optionally, the three-level cache may use a B+ tree as its data structure. The data in the three-level cache is arranged in an ordered manner.

[0108] In this embodiment, the access speed of the multi-level cache (i.e., level 1 cache, level 2 cache, and level 3 cache) is ordered from largest to smallest as follows: level 1 cache > level 2 cache > level 3 cache. That is, the merchant server accesses data from the level 1 cache fastest, while accessing data from the level 3 cache is slowest. For example, the storage capacity of the multi-level cache is ordered from largest to smallest as follows: level 3 cache > level 2 cache > level 1 cache. The level 1 cache occupies memory; however, due to limited memory space, the level 1 cache typically only occupies a portion of the memory.

[0109] For example, when a merchant server saves data to a multi-level cache, the priority order from top to bottom is: Level 1 cache > Level 2 cache > Level 3 cache. That is, when transaction data generated by the merchant server is saved to the cache, it is first saved to the Level 1 cache. If the Level 1 cache is full, the merchant server saves the transaction data to the Level 2 cache. If the Level 2 cache is full, the merchant server inserts the transaction data into the Level 3 cache.

[0110] For example, please refer to Figure 6a For example, assuming that the first-level cache and the second-level cache are both full, after the merchant server generates consumption data, it stores the consumption data in the third-level cache, that is, in the disk.

[0111] For example, when reading data from the cache, the merchant server reads data in the order of first-level cache, which is then second-level cache, which is then third-level cache. For instance, ... Figure 6b As shown, the merchant server reads data from the first-level cache. This data can be the earliest stored consumption data in the first-level cache, or any data within the first-level cache; this application does not impose any restrictions. After reading the consumption data from the first-level cache, the merchant server deletes that data from the first-level cache, that is, removes the data from its original location. The merchant server then retrieves the earliest stored consumption data from the second-level cache and stores it in the first-level cache. The merchant server deletes the data in the original consumption data area of ​​the second-level cache. Finally, the merchant server retrieves the consumption data from the third-level cache and stores it in the second-level cache, and deletes the data in the original area corresponding to the consumption data in the third-level cache.

[0112] For example, in the embodiments of this application, the SDK parameters configured on the merchant server may include, but are not limited to: whether the consumption data is ordered, the maximum amount of memory allowed, the maximum amount of disk space allowed, and the maximum network bandwidth allowed.

[0113] For example, the order of consumption data is configured by the merchant's operations personnel. Ordered arrangement can optionally involve storing consumption data in an ordered cache, for example, sorting it by its creation time. Furthermore, during subsequent transmissions, consumption data is also sent according to its creation time. The no-order method, on the other hand, requires no sorting and can store consumption data arbitrarily in the cache. It should be noted that the ordered storage method is slightly slower to read than the no-order method. For example, if the consumption data generated by the merchant's server is inherently ordered, or if the merchant has low requirements for the orderliness of the consumption data, internal ordered storage in the SDK cache can be omitted, thereby improving the read speed.

[0114] For example, the maximum allowed memory amount may optionally be the maximum memory capacity occupied by consumption data and other SDK-related program instructions. In this embodiment, in subsequent steps, the merchant server may dynamically adjust the capacity of each level of cache according to the instructions of the billing platform, but the memory capacity occupied by the adjusted cache is less than the maximum allowed memory.

[0115] For example, the maximum allowed disk space may optionally be the maximum disk space occupied by the consumed data. In this embodiment, in subsequent steps, the merchant server may dynamically adjust the capacity of each level of cache according to the instructions of the billing platform, but the disk space occupied by the adjusted cache is less than the maximum allowed disk space.

[0116] For example, the maximum network bandwidth allowed may be the maximum network bandwidth that the merchant server can use to send messages (such as consumption data) to the billing platform, thereby avoiding excessive bandwidth consumption for data interaction between the merchant server and the billing platform, which would affect the network transmission of other data on the merchant server.

[0117] In one possible implementation, the size of each cache region can be a default value during initial setup. This default value can be set according to actual needs, and this application does not impose any limitations. In subsequent processes, the merchant server can dynamically configure the size of each cache region based on instructions from the billing platform. Specific examples will be described in the following embodiments.

[0118] In another possible implementation, different billing specifications can correspond to different cache capacity settings. After the merchant server installs and runs the SDK, it obtains the billing service specifications subscribed to by the merchant from the billing platform through the interface provided by the SDK. The SDK can store the cache capacity configuration parameters corresponding to different billing specifications. The merchant server can configure the cache capacity for the SDK based on the SDK's requirements. For example, let's take Merchant A purchasing slow billing service and Merchant B purchasing fast billing service as an example. Merchant A purchases slow billing service, so Merchant A can configure the level 3 cache capacity and the maximum allowed disk space to be larger. Because the billing speed is slower, it is more likely to cause data backlog, and configuring a larger disk space can ensure that there is still enough disk space to store data when there is a large backlog. Merchant B purchases fast billing service, so Merchant B can configure the level 1 cache capacity, the maximum allowed network bandwidth, and the maximum allowed memory to be larger, thereby achieving faster read and transfer speeds.

[0119] S502, merchants provide services based on business needs and generate consumption data.

[0120] In this embodiment, merchant A is the SMS sending provider and merchant B is the advertising provider. User A sends an SMS service request to merchant A. The service request includes a customer list and SMS content, instructing the merchant to send SMS messages with specified content to the customers in the customer list.

[0121] Merchant A, in response to a received business request, can execute the relevant services accordingly. For example, based on user A's business request, Merchant A can send SMS messages with specified content to each customer in its customer list.

[0122] User B sends an advertising service request to Merchant B, which includes advertising content. Merchant B responds to User B's request by displaying User B's advertising content in a designated area of ​​the app store.

[0123] For example, each time merchant A sends a text message, it generates consumption data corresponding to user A. In other words, this consumption data is generated after providing services to user A. Each piece of consumption data includes, but is not limited to, user A's name, the time the consumption data was generated (i.e., the time the text message was sent), etc.

[0124] For example, each time merchant B detects a click event corresponding to an advertisement content of user B, it generates a consumption data record. In other words, this consumption data is generated after providing services to user B. Each consumption data record includes, but is not limited to, user B's name, the time when the consumption data was generated (i.e., the click event occurred), etc.

[0125] It should be noted that the same merchant can provide services to multiple users. This application embodiment only uses user A and user B as examples for illustration, and this application does not limit it.

[0126] It should be further noted that the same type of service can correspond to multiple merchants. For example, both Merchant B and Merchant C are advertising providers, and this application does not impose any restrictions.

[0127] S503, Merchants can inquire about billing services from the billing platform.

[0128] For example, the merchant server obtains the merchant's billing service from the billing platform through the SDK interface. For instance, the merchant server can send a billing service query request message to the billing platform through the interface provided by the SDK. In response to the received billing service query request message, the billing platform sends a billing service query response message to the merchant server, which includes the merchant's billing service specifications (e.g., fast billing, medium billing, or slow billing). The merchant server receives the billing service query response message and obtains the billing service specifications through the interface provided by the SDK. It should be noted that in this embodiment, the interaction between the merchant server and the billing platform is entirely through the interface provided by the SDK, and will not be repeated below.

[0129] S504, Merchants add tags to consumer data.

[0130] For example, after obtaining the merchant's billing service, the merchant server (specifically, an SDK) can optionally perform a validity check on the consumption data. Upon successful verification, a tag is added to the generated consumption data. The tag includes the merchant's billing service specification. For instance, if merchant A obtains that its billing service specification is slow billing, the tag in the consumption data generated by merchant A will include slow billing service indication information, indicating that merchant A's billing service is slow. If merchant B obtains that its billing service specification is fast billing, the tag in the consumption data generated by merchant B will include fast billing service indication information, indicating that merchant B's billing service is fast.

[0131] Optionally, the merchant server can obtain the billing service specifications from the billing platform for each consumption data generated and add corresponding tags to the consumption data.

[0132] Optionally, the merchant server may obtain the billing service specification from the billing platform every preset time interval (e.g., 1 minute, which can be set according to actual needs and is not limited in this application). The tags of the consumption data generated before the next time the billing service specification is obtained include the billing service specification indication information obtained this time.

[0133] Optionally, the billing platform can also send a billing service change instruction to the merchant after detecting a change in the merchant's billing service. That is, in this example, the merchant only needs to obtain the corresponding billing service specification in the configuration parameter stage of S503 or S501. When adding tags to consumption data, the merchant can add the corresponding tags based on the obtained billing service specification. If the merchant receives the billing service change instruction from the billing platform, it will add the corresponding tags to the consumption data generated after receiving the billing service change instruction, based on the changed billing service specification. The billing service specification indicated by the tag is the changed billing service specification.

[0134] In one possible implementation, the consumption data generated in step S502 may not include the consumption data generation time. The tags added to the consumption data by the merchant server may include the consumption data generation time and billing service specification information.

[0135] It should be noted that the tags described in this application embodiment can also be understood as part of the consumption data, that is, the consumption data includes, but is not limited to: the user's name, the time when the consumption data was generated, and the merchant's billing service specifications. Optionally, the tags can be in reserved fields in the consumption data, which is not limited in this application.

[0136] S505 saves consumption data to a multi-level cache.

[0137] For example, as described above, the merchant server is configured with a multi-level cache, including but not limited to at least one of the following: a first-level cache, a second-level cache, and a third-level cache. Each time the merchant server generates a new consumption data entry (which includes a tag), it inserts the newly generated consumption data into the multi-level cache.

[0138] In this embodiment, the merchant server inserts consumption data into the multi-level cache sequentially according to the priority order of the multi-level cache. For details, please refer to... Figure 6a The description in the text will not be repeated here.

[0139] S506, Merchants send consumption data and cache status information to the billing platform.

[0140] For example, this example illustrates the scenario of a merchant sending consumption data to the billing platform for the first time. In this embodiment, the number of consumption data items sent by the merchant to the billing platform for the first time can be a preset value. For example, the SDK may have a preset value for the first sending, such as 5 items. That is, each merchant sends 5 consumption data items for the first time. For example, as described above, merchant A inserts one consumption data item into the cache each time it generates one consumption data item. After generating 5 data items, merchant A retrieves 5 consumption data items from the cache, encapsulates them, and obtains a billing request message. Merchant A then sends the billing request message to the billing platform. For example, the method by which the merchant server retrieves consumption data from the cache can be referred to... Figure 6b The relevant descriptions will not be repeated here.

[0141] Optionally, in other embodiments, the SDK can be configured with the initial consumption data quantity corresponding to different billing specifications. For example, the initial consumption data quantity for the slow billing specification is 2 records, for the medium billing specification it is 5 records, and for the fast billing specification it is 10 records. Specific values ​​can be set according to actual needs and are not limited in this application. Taking merchant A subscribing to the slow billing specification and merchant B subscribing to the fast billing specification as an example: After generating 2 records, merchant A sends a billing request message to the billing platform, which includes the 2 consumption records. After generating 10 consumption records, merchant B sends a billing request message to the billing platform, which includes the 10 consumption records.

[0142] For example, in this embodiment of the application, the billing request message sent by the merchant server to the billing platform also includes cache status information, which can also be called SDK configuration parameter information, to indicate the current cache status of the SDK, including but not limited to: the capacity of each level of cache, and the backlog status information of each level of cache, wherein the backlog status information may include the capacity already used and / or the remaining capacity of each level of cache.

[0143] S507, the billing platform determines cache status update information and consumption data transmission parameters based on the tag and cache status information of consumption data.

[0144] For example, the billing platform receives a billing request message sent by the merchant's server through the SDK interface. The billing request message includes, but is not limited to, consumption data and cache status information. The billing platform parses the billing request message (e.g., decapsulation) to obtain the consumption data and cache status information.

[0145] For example, the billing platform bills and issues charges for consumption data. In this instance, the billing platform receives five initial consumption data entries from merchant A and five initial consumption data entries from merchant B. The billing platform bills merchant A's five consumption data entries, obtaining the consumption fee. The billing platform deducts the corresponding amount from user A's account and transfers the deducted amount to merchant A's account. The billing platform bills merchant B's five consumption data entries, obtaining the consumption fee. The billing platform deducts the corresponding amount from user B's account and transfers the deducted amount to merchant B's account. Specific details regarding billing and issuing charges can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0146] For example, the billing platform determines the priority of the merchant's current reported consumption data based on the generation time and billing service specifications in the consumption data, and determines the merchant's consumption data transmission parameters based on the priority of the consumption data. In this embodiment, the consumption data transmission parameters are used to indicate the quantity of consumption data that the merchant will report next.

[0147] In this embodiment of the application, the billing platform can pre-set weight values ​​for the generation time and the billing service specification, and obtain the weight (i.e., priority) of the consumption data based on the weight values. For example, the earlier the generation time, the higher the priority of the consumption data; for example, the higher the billing service specification (which can also be understood as the higher the amount spent by the merchant), the higher the priority of the consumption data.

[0148] The billing platform can calculate the priority of consumption data based on formula (1):

[0149] Priority = Time difference between generation time and current time * a + Billing service specification * b (1)

[0150] Where 'a' is the weight value corresponding to the generation time, and 'b' is the weight value corresponding to the billing service specification.

[0151] For example, let's take the weighting of the generation time and the billing service specification as 1. It should be noted that the weighting values ​​described in this embodiment are merely illustrative examples and can be set according to actual needs. For instance, the weighting value for the generation time could be 0.9 and the weighting value for the billing service specification could be 0.1, or the weighting value for the generation time could be 0.6 and the weighting value for the billing service specification could be 0.4. This application does not impose any limitations. Let's continue with the example of Merchant A subscribing to the slow billing specification and Merchant B subscribing to the fast billing specification. In this embodiment, the value corresponding to the fast billing service is 1, the value corresponding to the medium billing service is 5, and the value corresponding to the fast billing service is 10.

[0152] Suppose that merchant A sends 5 consumption data items, including consumption data 1 to consumption data 5. Taking consumption data 1 as an example, the time of generation of consumption data 1 is 1 day from the current time, the billing service specification is slow billing service, and the corresponding value is 1. Substituting into formula (1), the priority of consumption data 1 is 2. It should be noted that in this embodiment, only the unit of time difference is days is used as an example for explanation. In other embodiments, the unit of time difference can also be minutes or other time units, which is not limited in this application. The billing platform calculates the priority of consumption data 2 to 5 in the above manner. Among them, the priority of the consumption data with the lowest priority among multiple consumption data items can be regarded as the priority of merchant A. For example, if the priority of consumption data 1 is the lowest among consumption data 1 to 5 (for example, 2), then the priority of merchant A can be optionally 2.

[0153] Suppose that merchant B sends 5 consumption data entries, including consumption data 6 to 10. Taking consumption data 6 as an example, the time since consumption data 6 was generated is 1 day ago, the billing service specification is fast billing service, and the corresponding value is 10. Substituting into formula (1), the priority of consumption data 6 is 11. The billing platform calculates the priority of consumption data 7 to 10 in the same way. For example, if consumption data 11 has the lowest priority (e.g., 10), then merchant B's priority can optionally be 10.

[0154] For example, the billing platform can determine the merchant's consumption data transmission parameters based on at least one of the following: the priority of the consumption data, the current load of the billing platform (which can also be understood as processing capacity), and the maximum network bandwidth allowed by the merchant's server. This embodiment uses the consumption data transmission parameter to indicate the amount of consumption data the merchant will transmit next (also known as the consumption data reporting quantity) as an example. The adjusted consumption data reporting quantity is less than the maximum amount of consumption data that can be transmitted with the maximum allowed network bandwidth.

[0155] In one possible implementation, if the billing platform is currently under heavy load, for example, if the amount of received consumption data is large, exceeding 60% of the billing platform's processing capacity (this can be set according to actual needs, and this application does not limit it), the billing platform can keep the number of consumption data reports from high-priority merchants (e.g., greater than a preset threshold, which can be set according to actual needs, and this application does not limit it) unchanged or adjusted to a higher level. In other words, the reporting rate of consumption data from high-priority merchants is increased or kept unchanged. Meanwhile, the number of consumption data reports from low-priority merchants (e.g., less than a preset threshold, which can be set according to actual needs, and this application does not limit it) is reduced. This allows for priority processing of consumption data from higher-priority merchants under heavy load, thereby avoiding data transmission congestion and preventing delays in processing consumption data from merchants sensitive to billing latency.

[0156] In another possible implementation, when the billing platform is idle, for example, when the amount of consumption data received is small, less than 30% of the billing platform's processing capacity (this can be set according to actual needs, and this application does not limit it), the billing platform can increase the overall number of consumption data reports submitted by each merchant. Among them, the increase in the number of consumption data reports submitted by merchants with high priority (e.g., greater than a preset threshold, which can be set according to actual needs, and this application does not limit it) can be greater than or equal to the increase in the number of consumption data reports submitted by merchants with low priority (e.g., less than a preset threshold, which can be set according to actual needs, and this application does not limit it), and this application does not limit it.

[0157] This embodiment of the application illustrates a scenario where the billing platform is operating normally, for example, with a load greater than 30% but less than 60%. In this scenario, the billing platform can adjust the merchant's transmission parameters based on the merchant's priority. For example, the billing platform can set different consumption data transmission parameters corresponding to different priorities. The specific values ​​can be set according to actual needs, and this application does not limit them. Taking merchant A's priority as 2 and merchant B's priority as 10 as an example (the specific calculation method can be referred to above, and will not be repeated here), the billing platform determines the next consumption data reporting quantity for merchant A (i.e., merchant A's consumption data transmission parameter) as 2 based on merchant A's priority, and determines the next consumption data reporting quantity for merchant B (i.e., merchant B's consumption data transmission parameter) as 10 based on merchant B's priority. The above values ​​are merely illustrative examples and are not limited in this application.

[0158] In this embodiment, the billing platform is further configured to determine whether the capacity of the merchant's cache at each level needs to be adjusted based on the cache status information reported by the merchant. If the billing platform determines that the capacity of the merchant's cache at each level needs to be adjusted, the billing platform will send cache status update information back to the merchant, which will instruct the merchant to adjust the capacity of the cache at each level. Optionally, if the billing platform determines that the capacity of the merchant's cache at each level does not need to be adjusted, the billing platform may choose not to send cache status information back to the merchant.

[0159] For example, as described above, the billing platform can obtain cache status information reported by merchants to indicate the current capacity and backlog of caches at all levels (i.e., used capacity and / or remaining capacity).

[0160] In one possible implementation, for merchants with significant cache backlog, such as those whose remaining cache capacity is less than a preset threshold (which can be set according to actual needs and is not limited in this application), the billing platform can increase the capacity of the merchant's first-level cache and / or second-level cache to enable the merchant to quickly report consumption data, thereby quickly clearing the backlog cache. For example, for merchants who can report data more slowly, the billing platform can increase the capacity of the merchant's third-level cache and pre-reserve space to ensure more data can be stored locally, while reducing the capacity of the first-level and second-level caches to avoid prolonged and excessive use of the merchant's server memory. Optionally, the merchants who can report data more slowly mentioned above may be merchants with lower priority (e.g., priority less than a preset threshold) or merchants with lower billing service specifications (e.g., slow billing specifications), which is not limited in this application. In practice, the aforementioned "pre-placement" can optionally involve the merchant server expanding the capacity of its Level 3 cache based on instructions from the billing platform. The merchant server can fill the expanded capacity area with empty data (e.g., all zeros) to prevent other data from being written to the area requiring expansion. The merchant server can then write newly generated consumption data into the pre-placement area.

[0161] In another possible implementation, the billing platform can also reduce the capacity of a merchant's cache at each level based on the merchant's cache status information. For example, as mentioned above, the initial values ​​of the various levels of cache set by the billing platform may be default values. For merchants with higher billing service specifications (such as fast billing service specifications), the billing platform can reduce the capacity of the three-level cache for such merchants to reduce resource waste.

[0162] It should be noted that this embodiment uses a fixed reporting interval set in the SDK as an example, such as a reporting cycle of 1 minute, meaning that each merchant server reports consumption data once every 1 minute, and the amount of consumption data reported each time can be dynamically adjusted. In this embodiment, the merchant's consumption data reporting rate can be adjusted by changing the amount of consumption data sent every cycle.

[0163] In another possible implementation, the SDK can be set to a fixed amount of data to be reported, such as 5 data entries per report. In this example, the merchant server can respond to the billing platform's instructions to adjust the reporting cycle duration, thereby adjusting the merchant's consumption data reporting rate by adjusting the reporting interval of consumption data.

[0164] In another possible implementation, the SDK may not set the reporting quantity and reporting interval. The merchant server can respond to the instructions of the billing platform to adjust the reporting interval and the number of consumption data reported each time, thereby adjusting the merchant's consumption data reporting rate.

[0165] In other words, in this embodiment, the merchant server can dynamically adjust the reporting period and / or the number of reported consumption data to achieve dynamic adjustment of the consumption data reporting rate. This embodiment only illustrates the adjustment of the number of reported consumption data at a fixed period. The implementation process for adjusting the reporting period, or adjusting both the reporting period and the number of reported consumption data, is the same as the steps in this embodiment, and will not be described in detail here.

[0166] S508, the billing platform sends cache status update information and consumption data transmission parameters to merchants.

[0167] For example, after the billing platform determines the cache status update information and consumption data transmission parameters for each merchant, it sends a billing response message to the merchant. The billing response message includes a billing confirmation message and a billing failure message. For specific concepts, please refer to the above text, which will not be repeated here.

[0168] For example, the billing response message includes, but is not limited to, at least one of the following: indication information indicating billing success or failure, all or part of the billing event information, cache status update information, and consumption data transmission parameters.

[0169] S509, Merchant updates cache.

[0170] For example, if the billing response message includes cache status update information, the merchant can update (including expand or shrink) the corresponding cache capacity according to the instructions in the cache status update information.

[0171] S510a: Merchants provide services based on business needs and generate consumption data.

[0172] S510b allows merchants to add tags to consumer data.

[0173] The S510c saves consumption data to a multi-level cache.

[0174] For example, in this embodiment, the steps of generating and saving consumption data for the merchant to provide services to the user can be performed at any time, such as simultaneously with S511, before S511, or after S511. Of course, for some merchants, no new consumption data may be generated before S511 is executed, and this application does not limit this. Details not described can be referred to the relevant content in the above embodiments, and will not be repeated here.

[0175] S511, the merchant sends cache status information to the billing platform, and sends consumption data according to the consumption data transmission parameters.

[0176] For example, in the next cycle, the merchant sends a billing request message to the billing platform. This message includes consumption data and cache status information. The concepts related to cache status information are explained above and will not be repeated here. For example, the amount of consumption data included in the billing request message is the amount reported by the merchant according to the consumption data transmission parameters.

[0177] For example, as illustrated above, the billing platform sends consumption data transmission parameters to Merchant A, indicating that Merchant A should report 2 consumption data entries. Similarly, the billing platform sends consumption data transmission parameters to Merchant B, indicating that Merchant B should report 10 consumption data entries. Accordingly, in the next cycle, for example, one minute after the previous report, Merchant A sends 2 consumption data entries to the billing platform. Merchant B, in the next cycle, sends 10 consumption data entries to the billing platform.

[0178] S512, the billing platform determines cache status update information and consumption data transmission parameters based on the tag and cache status information of consumption data.

[0179] S513, the billing platform sends cache status update information and consumption data transmission parameters to merchants.

[0180] For example, the billing platform repeatedly executes steps such as billing, billing, determining cache status information, and determining consumption data transmission parameters based on the billing request messages received from each merchant. In other words, in this embodiment, the billing platform executes these steps each time it receives consumption data reported by a single merchant. It can be understood that the amount of consumption data a merchant sends to the billing platform each time is determined based on the consumption data sent previously.

[0181] For example, taking merchant A and merchant B as an example again, the billing platform receives a billing request message from merchant A and obtains two consumption data and cache status information of merchant A. Similarly, the billing platform receives a billing request message from merchant B and obtains ten consumption data and cache status information of merchant B.

[0182] The billing platform performs billing and reimbursement based on two consumption records from Merchant A. Details can be found above and will not be repeated here. The billing platform determines the capacity of Merchant A's cache at each level based on cache status information. Details can be found above and will not be repeated here.

[0183] For example, the billing platform determines the priority of each of the two consumption data entries sent by merchant A based on the generation time and billing service specifications in merchant A's consumption data. The lowest priority is the priority corresponding to merchant A. The billing platform can determine merchant A's data transmission parameters, i.e., the quantity of consumption data that merchant A will report next, based on information such as merchant A's priority, the billing platform's current processing capacity, and merchant A's maximum transmission bandwidth. For example, if the billing platform obtains that merchant A's priority is 3, the billing platform determines merchant A's data transmission parameter to be 5, indicating that merchant A will transmit 5 consumption data entries next.

[0184] For example, the billing platform processes merchant B similarly to merchant A. For instance, the billing platform determines that merchant B's consumption data transmission parameter is 10, indicating that the next transmission of consumption data will contain 10 data points. Other details can be found above and will not be repeated here.

[0185] For example, the system repeatedly executes S509 to S513. That is, the merchant updates the cache and reports the consumption data to the billing platform according to the consumption data transmission parameters newly indicated by the billing platform.

[0186] The following detailed explanation of the dynamic adjustment scheme for the consumption data transmission parameters described above uses specific embodiments. Please refer to [link / reference]. Figure 7a Assume that both Merchant A and Merchant B currently have 100 transaction records cached. Merchant A subscribes to the slow billing service, while Merchant B subscribes to the fast billing service. The current transaction data transmission parameters (i.e., the ones received last time) indicate that the number of transaction records to be sent is 5. At time t1, Merchant A retrieves 5 transaction records (i.e., transaction records 1-5) from its cache and sends a billing request message to the billing platform. The billing request message includes the 5 transaction records, cache status information, etc. Each of the 5 transaction records includes tag information, which includes the transaction data generation time and billing service specification. Merchant B follows the same procedure, which will not be elaborated upon here. This embodiment uses successful billing and billing by the billing platform as an example. Furthermore, this example primarily illustrates the scenario of changes in transaction data transmission parameters; other aspects, such as cache status updates, will not be discussed further. It should be noted that this example uses Merchant A and Merchant B caching 100 consumer data entries as an illustration. Furthermore, no new consumer data is generated in the cache during the execution process. This is only to better illustrate the changes in consumer data. In reality, new consumer data can be generated in the caches of Merchant A and Merchant B, but this will not be repeated in this example.

[0187] For example, the billing platform obtains the priority of each consumption data based on the tags of merchant A's consumption data, and determines that merchant A's priority (i.e., the lowest priority among the consumption data) is 2. Accordingly, based on merchant A's priority, the billing platform determines that merchant A's consumption data transmission parameter is 2, which is used to indicate that the number of consumption data reported by merchant A next time is 2, thereby reducing merchant A's reporting rate.

[0188] For example, the billing platform obtains the priority of each consumption data based on the tags of merchant B's consumption data, and determines that merchant B's priority (i.e., the lowest priority in the consumption data) is 15. Accordingly, based on merchant B's priority, the billing platform determines that merchant B's consumption data transmission parameter is 15, which is used to indicate that the number of consumption data reported by merchant B next time is 10, thereby improving merchant B's reporting rate.

[0189] Please refer to Figure 7bAt time t2, Merchant A, following the instructions of the billing platform, sends two consumption data entries to the billing platform, for example, consumption data entries 6-8 in Merchant A's data. Merchant B, following the instructions of the billing platform, sends ten consumption data entries to the billing platform, for example, consumption data entries 6-16 in Merchant B's data. The billing platform feeds back the consumption data transmission parameters to Merchant A, indicating that the number of consumption data entries Merchant A will report next is 2. The billing platform feeds back the consumption data transmission parameters to Merchant B, indicating that the number of consumption data entries Merchant B will report next is 10. Details not described herein can be found above and will not be repeated here.

[0190] Please refer to Figure 7c At time t3, Merchant A sends two consumption data entries to the billing platform, such as consumption data 9-10. Merchant B sends ten consumption data entries to the billing platform, such as consumption data 17-27. At this time, due to the slow reporting rate of Merchant A, the consumption data in Merchant A may be backlogged. For example, the time difference between the generation time of consumption data 10 and the current time is 30 minutes. Based on formula (1), the billing platform can obtain the priority of consumption data 10 as 31 (where the weight corresponding to the generation time is 1, the value corresponding to the slow billing service is 1, and the weight is 1). Because Merchant B previously reported data at a faster rate, its backlog is smaller, potentially lowering the priority of its consumption data. For example, if the time difference between the generation time of consumption data 27 and the current time is 1 minute, based on formula (1), the billing platform can obtain a priority of 11 for consumption data 27 (where the weight corresponding to the generation time is 1, and the value corresponding to the fast billing service is 10, with a weight of 1). The billing platform can determine the consumption data transmission parameter of Merchant A as 7 based on Merchant A's priority (e.g., 31), thereby increasing Merchant A's consumption data reporting rate. For example, the billing platform can determine the consumption data transmission parameter of Merchant B as 5 based on Merchant B's priority (e.g., 2), thereby reducing Merchant B's consumption data reporting rate. It should be noted that in this scenario, since Merchant A's cache may have a backlog, the billing platform can increase Merchant A's cache capacity, for example, by increasing the capacity of the first-level cache. For example, if the billing platform detects that merchant A's backlog has eased, the billing platform can instruct merchant A to reduce the size of its first-level cache.

[0191] For example, please refer to Figure 7d For example, Merchant A sends 7 transaction data entries to the billing platform, such as transaction data entries 11-17. Merchant B sends 5 transaction data entries to the billing platform, such as transaction data entries 28-32. The billing platform then proceeds with the confirmation and feedback process for the transaction data transmission parameters, which will not be repeated here.

[0192] Figure 8For an illustrative diagram showing changes in the amount of reported consumption data, please refer to... Figure 8 For example, at time t1, Merchant A and Merchant B report a total of 5 consumption data entries. At times t2 and t3, Merchant A, responding to the billing platform's instructions, reduces the number of consumption data entries reported, for example, to 2 at time t2. Merchant B, responding to the platform's instructions, increases the number of consumption data entries reported, for example, to 10. This allows for faster processing of consumption data in Merchant B, reducing billing delays and clearing the backlog of consumption data. Since Merchant A has a lower priority, its consumption data reporting rate can be appropriately reduced, allowing the billing platform to prioritize processing consumption data from Merchant B, preventing lower-priority consumption data from consuming excessive processing power and interface resources on the billing platform. For example, if Merchant A's reporting rate decreases, potentially causing a backlog of transaction data, then at time t3, Merchant A can increase its reporting rate, i.e., increase the amount of transaction data reported, to promptly clear the backlog of transaction data and avoid excessive delays in billing, which could affect Merchant A's overall billing delay. Merchant B can appropriately decrease its reporting rate so that the billing platform prioritizes processing the transaction data of Merchant A, which has a more severe backlog.

[0193] like Figure 8 As shown in the embodiment of this application, the number of consumption data reported by Merchant B and Merchant A at times t3 to t7 changes dynamically, thereby improving the reliability and stress resistance of the billing platform while ensuring the billing delay of each merchant.

[0194] In one possible implementation, the billing platform can scale down or up based on the merchant's subscription to billing services, the platform's processing capacity, and the amount of consumption data received. Scale-up can optionally involve increasing the number of servers on the billing platform to improve its processing capacity. Scale-down can optionally involve reducing the number of servers on the billing platform to improve resource utilization.

[0195] For example, if the billing platform detects a large number of merchants subscribing to the fast billing service, such as exceeding a preset merchant threshold (which can be set according to actual needs, and this application does not limit this), the billing platform can pre-scale up its capacity. That is, after detecting a large number of merchants subscribing to the fast billing service, the number of servers is increased to prevent sudden data surges from affecting the overall billing latency of the system. In other words, in this embodiment, the billing platform can accurately distinguish and calculate the peak data volume of all merchants based on their subscription information, and thus accurately calculate the pre-expansion capacity. Furthermore, as mentioned above, the billing platform can dynamically adjust the merchant's reporting rate and cache capacity. Therefore, when the amount of consumption data received by the billing platform increases or decreases sharply, i.e., when the amount of received consumption data changes significantly, the billing platform can dynamically adjust the reporting rate and cache capacity of each merchant to reduce or increase the overall system processing speed. When reducing the overall system processing speed, the billing platform has sufficient time to scale up or down.

[0196] In this embodiment, if the billing platform successfully issues the bill—that is, successfully deducts the consumption fee from the user's account and transfers the funds to the merchant—the billing platform sends a billing request confirmation message to the merchant to indicate that the billing and issuance were successful. Optionally, if the billing platform fails to issue the bill, for example, if the user's account balance is insufficient to deduct the consumption fee, the billing platform sends a billing request failure message to the merchant to indicate that the billing failed. Specific details can be found in the relevant content of the embodiments above, and will not be repeated here.

[0197] In one possible implementation, the billing platform processes consumption data with different billing latency specifications uniformly during billing, billing, and scaling up / down, without differentiation. However, for some merchants with high latency requirements, even a 100-millisecond reduction in billing latency can have a significant impact. Scaling up the entire billing platform solely for these merchants could lead to a waste of resources. To address this scenario, this embodiment further differentiates and processes consumption data with different billing latency specifications using different processing modules within the billing platform.

[0198] For example, taking the three billing latency options mentioned above—fast billing, medium billing, and slow billing—as an example, the billing platform can set up separate fast billing processing modules, medium billing processing modules, and slow billing processing modules within each option. Figure 9As shown, different modules can correspond to different processors or servers. In this example, the fast billing processing module processes the consumption data of merchants subscribing to the fast billing service, the medium billing processing module processes the consumption data of merchants subscribing to the medium billing service, and the slow billing processing module processes the consumption data of merchants subscribing to the slow billing service. When the billing platform detects a significant change in the amount of consumption data corresponding to at least one billing service, it will scale up or down the corresponding module. For example, when the billing platform detects a surge in the amount of consumption data corresponding to the fast billing service, it can scale up the fast processing module. By using separate modules to process consumption data with different billing latency specifications, each processing module can be independently selected and designed, achieving architectural decoupling. Furthermore, each specification of processing module can be scaled up or down independently according to its own processing needs without affecting the processing capacity of other modules.

[0199] It is understood that, in order to achieve the above-mentioned functions, electronic devices include hardware and / or software modules that perform the respective functions. Based on the algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software.

[0200] In one example, Figure 10 The schematic block diagram illustrating an embodiment of the present application shows an apparatus 1000. The apparatus 1000 may include a processor 1001 and a transceiver / transceiver pin 1002, and optionally, a memory 1003.

[0201] The various components of device 1000 are coupled together via bus 1004, which includes a data bus, a power bus, a control bus, and a status signal bus. However, for clarity, all buses are referred to as bus 1004 in the figure.

[0202] Optionally, the memory 1003 can be used to store instructions from the foregoing method embodiments. The processor 1001 can be used to execute the instructions in the memory 1003, control the receive pin to receive signals, and control the transmit pin to transmit signals.

[0203] The device 1000 may be an electronic device or a chip of an electronic device in the above method embodiments.

[0204] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0205] This embodiment also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the methods described in the above embodiments.

[0206] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the methods described in the above embodiments.

[0207] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the methods in the above-described method embodiments.

[0208] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.

[0209] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. 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.

[0210] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or 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 apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0211] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0212] 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.

[0213] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0214] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0215] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0216] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0217] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0218] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A business processing method, characterized in that, Applied to a server, the method includes: At the first moment, a first billing request message is sent to the billing platform. The first billing request message includes m1 consumption data. The first billing request message is used to request the billing platform to bill and issue bills for the m1 consumption data. m1 is a positive integer greater than 0. The system receives a first billing request response message from the billing platform. The first billing request response message includes a first billing success indication message and a first consumption data transmission parameter. The first billing success indication message is used to instruct the billing platform to complete the billing and billing of the m1 consumption data. The first consumption data transmission parameter is used to indicate the first cycle duration and the number of first consumption data sent. At the second moment, a second billing request message is sent to the billing platform. The second billing request message includes m2 consumption data points. The second billing request message is used to request the billing platform to bill and issue charges for the m2 consumption data points. The time difference between the first moment and the second moment is the duration of the first period, m2 is equal to the number of first consumption data points sent, m2 is a positive integer greater than 0, and m2 is different from m1. The single consumption data is generated by the server after providing the target service to the user based on the user's business needs information. The single consumption data includes time information and billing service specification information. The time information is used to indicate the time when the single consumption data was generated, and the billing service specification information is used to indicate the billing service specification corresponding to the target service.

2. The method according to claim 1, characterized in that, The m1 consumed data are consumed data from the n1 consumed data cached by the server before the first time point; the m2 consumed data are consumed data from the n2 consumed data cached by the server before the second time point; n1 and n2 are both positive integers greater than 0, and n1 and n2 may be the same or different.

3. The method according to claim 2, characterized in that, The n1 data are cached in at least one of the first, second, and third cache regions of the server; the read rate of the first cache region is higher than the read rate of the second cache region, and the read rate of the second cache region is higher than the read rate of the third cache region.

4. The method according to claim 3, characterized in that, The first cache region and the second cache region are located in the memory of the server, and the third cache region is located in the hard disk of the server.

5. The method according to claim 3, characterized in that, The first billing request message also includes cache status information, which is used to indicate the cache status of the first cache area, the cache status of the second cache area, and the cache status of the third cache area.

6. The method according to claim 5, characterized in that, The first billing request response message further includes cache status update information, which is used to indicate updating the capacity of at least one of the first cache region, the second cache region, and the third cache region. The method further includes: In response to the cache status update information, the capacity of at least one of the first cache region, the second cache region, and the third cache region is updated.

7. The method according to claim 1, characterized in that, The method further includes: The system receives a second billing request response message from the billing platform. The second billing request response message includes a second billing success indication message and a second consumption data transmission parameter. The second billing success indication message is used to instruct the billing platform to complete the billing and billing of the m2 consumption data. The second consumption data transmission parameter is used to indicate the second cycle duration and the number of second consumption data sent. The second cycle duration is different from the first cycle duration, and the number of second consumption data sent is different from the number of first consumption data sent. At the third moment, a third billing request message is sent to the billing platform. The third billing request message includes m3 consumption data. The third billing request message is used to request the billing platform to bill and issue bills for the m3 consumption data. The time difference between the third moment and the second moment is the duration of the second period. m3 is equal to the number of second consumption data sent. m3 is a positive integer greater than 0. m3, m2 and m1 are different.

8. The method according to claim 1, characterized in that, The method further includes: The system receives a third billing request response message sent by the billing platform. The third billing request response message includes billing failure indication information. The billing failure indication information is used to indicate that the billing and billing of the m2 consumption data failed.

9. The method according to claim 8, characterized in that, The method further includes: Stop providing the target service to the user.

10. The method according to claim 1, characterized in that, Before sending the first billing request message to the billing platform, the following steps are included: The billing service specification is obtained from the billing platform; the billing service specification is preset.

11. A business processing apparatus, characterized in that, Applied to a server, the device includes: Memory and processor; the memory is coupled to the processor; The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the device performs the following steps: At the first moment, a first billing request message is sent to the billing platform. The first billing request message includes m1 consumption data. The first billing request message is used to request the billing platform to bill and issue bills for the m1 consumption data. m1 is a positive integer greater than 0. The system receives a first billing request response message from the billing platform. The first billing request response message includes a first billing success indication message and a first consumption data transmission parameter. The first billing success indication message is used to instruct the billing platform to complete the billing and billing of the m1 consumption data. The first consumption data transmission parameter is used to indicate the first cycle duration and the number of first consumption data sent. At the second moment, a second billing request message is sent to the billing platform. The second billing request message includes m2 consumption data points. The second billing request message is used to request the billing platform to bill and issue charges for the m2 consumption data points. The time difference between the first moment and the second moment is the duration of the first period, m2 is equal to the number of first consumption data points sent, m2 is a positive integer greater than 0, and m2 is different from m1. The single consumption data is generated by the server after providing the target service to the user based on the user's business needs information. The single consumption data includes time information and billing service specification information. The time information is used to indicate the time when the single consumption data was generated, and the billing service specification information is used to indicate the billing service specification corresponding to the target service.

12. The apparatus according to claim 11, characterized in that, The m1 consumed data are consumed data from the n1 consumed data cached by the server before the first time point; the m2 consumed data are consumed data from the n2 consumed data cached by the server before the second time point; n1 and n2 are both positive integers greater than 0, and n1 and n2 may be the same or different.

13. The apparatus according to claim 12, characterized in that, The n1 data are cached in at least one of the first, second, and third cache regions of the server; the read rate of the first cache region is higher than the read rate of the second cache region, and the read rate of the second cache region is higher than the read rate of the third cache region.

14. The apparatus according to claim 13, characterized in that, The first cache region and the second cache region are located in the memory of the server, and the third cache region is located in the hard disk of the server.

15. The apparatus according to claim 13, characterized in that, The first billing request message also includes cache status information, which is used to indicate the cache status of the first cache area, the cache status of the second cache area, and the cache status of the third cache area.

16. The apparatus according to claim 15, characterized in that, The first billing request response message further includes cache status update information, which is used to indicate updating the capacity of at least one of the first cache region, the second cache region, and the third cache region. When the processor executes the computer instructions, the device performs the following steps: In response to the cache status update information, the capacity of at least one of the first cache region, the second cache region, and the third cache region is updated.

17. The apparatus according to claim 11, characterized in that, When the processor executes the computer instructions, the device performs the following steps: The system receives a second billing request response message from the billing platform. The second billing request response message includes a second billing success indication message and a second consumption data transmission parameter. The second billing success indication message is used to instruct the billing platform to complete the billing and billing of the m2 consumption data. The second consumption data transmission parameter is used to indicate the second cycle duration and the number of second consumption data sent. The second cycle duration is different from the first cycle duration, and the number of second consumption data sent is different from the number of first consumption data sent. At the third moment, a third billing request message is sent to the billing platform. The third billing request message includes m3 consumption data. The third billing request message is used to request the billing platform to bill and issue bills for the m3 consumption data. The time difference between the third moment and the second moment is the duration of the second period. m3 is equal to the number of second consumption data sent. m3 is a positive integer greater than 0. m3, m2 and m1 are different.

18. The apparatus according to claim 11, characterized in that, When the processor executes the computer instructions, the device performs the following steps: The system receives a third billing request response message sent by the billing platform. The third billing request response message includes billing failure indication information. The billing failure indication information is used to indicate that the billing and billing of the m2 consumption data failed.

19. The apparatus according to claim 18, characterized in that, When the processor executes the computer instructions, the device performs the following steps: Stop providing the target service to the user.

20. The apparatus according to claim 11, characterized in that, When the processor executes the computer instructions, the device performs the following steps: Before sending the first billing request message to the billing platform, the billing service specification is obtained from the billing platform; the billing service specification is preset.

21. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-10.

22. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-10.

23. A chip, characterized in that, The device includes one or more interface circuits and one or more processors; the interface circuits are configured to receive signals from the memory of an electronic device and send the signals to the processors, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method according to any one of claims 1 to 10.

Images