WO2023147716A1

WO2023147716A1 - Flow control and billing methods, apparatuses and system, electronic device, medium and product

Info

Publication number: WO2023147716A1
Application number: PCT/CN2022/106800
Authority: WO
Inventors: 黄世亮; 曲春雨; 刘明浩
Original assignee: 北京百度网讯科技有限公司
Priority date: 2022-02-07
Filing date: 2022-07-20
Publication date: 2023-08-10
Also published as: CN114500128B; CN114500128A

Abstract

The disclosure relates to the technical field of computers, in particular to the technical field of flow billing. Provided in the present disclosure are flow control and billing methods, apparatuses and system, an electronic device, a medium and a product, which may improve the accuracy of flow control in a high-concurrency scenario. A specific implementation solution is that: a flow control and billing module receives a begin request sent by a proxy service, and judges whether the sum of a current pre-billing amount, and a pre-billed amount and an expended amount corresponding to a user identifier is greater than an available credit so as to obtain a judgment result, wherein, the pre-billed amount corresponding to the user identifier is the sum of current pre-billing amounts of service requests which are being processed and which correspond to the user identifier; and then, whether to respond to a service request is determined on the basis of the judgment result, and the expended amounts corresponding to the user identifier are accumulated on the basis of the response result for the service request.

Description

Flow control billing method, device, system, electronic equipment, medium and product

This application claims the priority of the Chinese patent application with the application number 202210116365.5 submitted to the China Patent Office on February 07, 2022. The entire contents of which are incorporated by reference in this application.

technical field

The present disclosure relates to the technical field of computers, and in particular to the technical field of traffic billing.

Background technique

With the continuous development of the current Internet artificial intelligence (AI) technology, the form of AI products is also changing with each passing day, and more and more scenarios have the demand for flow control and billing (Flow Control and Billing). Flow control billing, that is, flow control and billing, refers to the control and billing of user access, that is, according to the billing objects consumed by user access, allowing users to access or prohibiting user access, and according to user access Billing is carried out according to the consumption of billing objects.

Flow control billing scenarios are widely used. For example, the current flow control billing scenarios include: AI voice recognition flow control billing scenarios, AI speech synthesis flow control billing scenarios, AI text translation character flow control billing scenarios, AI video live broadcast review flow control billing scenarios and mobile phone Traffic flow control billing scenarios, etc.

Contents of the invention

The disclosure provides a flow control billing method, device, system, electronic equipment, medium and product.

The first aspect of the embodiments of the present disclosure provides a flow control and charging method, which is applied to the flow control and charging module, including:

Receiving a start request sent by the proxy service, the begin request is sent by the proxy service after receiving the service request sent by the terminal, the begin request includes the user ID that triggers the service request and the script for processing the service request Estimated amount of fees;

Judging whether the sum of the expected charge amount for this time, the estimated charge amount corresponding to the user identifier, and the used amount is greater than the available amount, and obtain a judgment result; the estimated charge amount corresponding to the user identifier is the amount corresponding to the user identifier The sum of the current estimated cost of each service request being processed;

Based on the judgment result, determine whether to respond to the service request, and accumulate the used amount corresponding to the user identifier based on the response result of the service request.

The second aspect of the embodiments of the present disclosure provides a flow control billing method applied to proxy services, including:

receiving a service request sent by a terminal, where the service request includes a user identifier triggering the service request;

Determining the current estimated fee amount of the business request;

Sending a begin request carrying the user identifier and the estimated billing amount to the flow control and charging module, so that the flow control and billing module judges the current estimated billing amount and the already charged amount corresponding to the user identifier Whether the sum of the expected fee amount and the used amount is greater than the available amount is obtained to obtain a judgment result, and based on the judgment result, it is determined whether to respond to the service request, and based on the response result of the service request, the used amount corresponding to the user identifier is accumulated, and the The estimated billing amount corresponding to the user ID is the sum of the current estimated billing amounts of the service requests being processed corresponding to the user ID.

The third aspect of the embodiments of the present disclosure provides a flow control and charging device, which is applied to the flow control and charging module, including:

The first receiving module is configured to receive a start request sent by the proxy service, the begin request is sent by the proxy service after receiving the service request sent by the terminal, and the begin request includes the user identifier and the user ID that triggered the service request The current estimated fee for processing the business request;

A judging module, configured to judge whether the sum of the expected billing amount, the estimated billing amount corresponding to the user identifier, and the used amount is greater than the available amount, and obtain a judgment result; the estimated billing amount corresponding to the user identifier is The sum of the current estimated charges for each service request being processed corresponding to the above user ID;

The accumulation module is configured to determine whether to respond to the service request based on the judgment result of the judgment module, and to accumulate the used amount corresponding to the user identifier based on the response result of the service request.

According to the fourth aspect of the embodiments of the present disclosure, a device for flow control and charging is provided, which is applied to proxy services, including:

The second receiving module is configured to receive a service request sent by a terminal, where the service request includes a user identifier triggering the service request;

The current estimated fee amount determination module is used to determine the current estimated fee amount of the service request;

The second sending module is configured to send a begin request carrying the user identifier and the expected charge amount to the flow control and charging module, so that the flow control and charge module can judge the current estimate charge amount, Whether the sum of the estimated charge amount and the used amount corresponding to the user identifier is greater than the available amount is obtained as a judgment result, and based on the judgment result, it is determined whether to respond to the service request, and the user identifier is accumulated based on the response result of the service request The corresponding used amount, the estimated billed amount corresponding to the user ID is the sum of the current estimated billed amount of each service request being processed corresponding to the user ID.

The fifth aspect of the embodiments of the present disclosure provides a flow control and charging system, including a proxy service, a flow control and charging module, and an operator service;

The flow control and billing module is configured to execute the method described in any one of the first aspect;

The proxy service is used to perform the method described in any one of the second aspect;

The operator service is used to process business requests.

According to a sixth aspect of the embodiments of the present disclosure, an electronic device is provided, including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions are executed by the at least one processor, so that the at least one processor can perform any one of the first aspect or the second aspect the method described.

A seventh aspect of the embodiments of the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to make the computer execute any one of the first aspect or the second aspect the method described.

An eighth aspect of the embodiments of the present disclosure provides a computer program product, including a computer program, when the computer program is executed by a processor, the method described in any one of the first aspect or the second aspect is implemented.

It should be understood that what is described in this section is not intended to identify key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will be readily understood through the following description.

Description of drawings

In order to more clearly illustrate the embodiments of the present disclosure and the technical solutions of the prior art, the following briefly introduces the accompanying drawings required in the embodiments and the prior art. Obviously, the accompanying drawings in the following description are only the present invention. For some disclosed embodiments, those skilled in the art can also obtain other drawings based on these drawings without any creative work.

FIG. 1 is a flowchart of a flow control and billing method provided by an embodiment of the present disclosure;

Figure 2a is an exemplary schematic diagram of a flow control charging process in the related art;

Fig. 2b is an exemplary schematic diagram of a flow control and charging process in an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method for refreshing a doing heartbeat provided by an embodiment of the present disclosure;

FIG. 4 is a flow chart of a method for processing a timed task provided by an embodiment of the present disclosure;

FIG. 5 is a flowchart of another flow control and billing method provided by an embodiment of the present disclosure;

FIG. 6 is a flow chart of another doing heartbeat refreshing method provided by an embodiment of the present disclosure;

FIG. 7 is an exemplary schematic diagram of a process of processing a begin request provided by an embodiment of the present disclosure;

FIG. 8 is an exemplary schematic diagram of a process of processing an end request provided by an embodiment of the present disclosure;

FIG. 9 is an exemplary schematic diagram of a process of processing a doing request provided by an embodiment of the present disclosure;

FIG. 10 is an exemplary schematic diagram of a process of processing a timed task provided by an embodiment of the present disclosure;

Fig. 11 is a schematic structural diagram of a flow control and billing device provided by an embodiment of the present disclosure;

Fig. 12 is a schematic structural diagram of another flow control and billing device provided by an embodiment of the present disclosure;

Fig. 13 is a schematic structural diagram of a flow control and billing system provided by an embodiment of the present disclosure;

Fig. 14 is a block diagram of an electronic device used to implement the flow control and billing method of the embodiment of the present disclosure.

Detailed ways

Exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding, and they should be regarded as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The billing objects are different in different flow control billing scenarios. For example, the search function needs to perform flow control billing according to the number of searches, that is, the billing object is the number of searches; the audio and video processing function needs to perform flow control billing according to the duration of the audio and video, that is, the billing object is the duration of the audio and video; Processing requires flow control billing based on the number of words included in the document, that is, the billing object is the number of words included in the document; the use of mobile phone traffic needs to be billed according to the byte stream, that is, the billing object is the byte stream.

Although the billing objects in various scenarios are different, each billing object can be represented by a numerical value, so the traditional flow control billing method is an accumulative billing object.

For example, when the billing object is the number of visits, the traditional flow control billing method is: each time a request sent by a user is received, the number of visits is increased by 1, and the current number of visits is compared with the upper limit. If the upper limit is reached, the access is prohibited; otherwise, the access is allowed, and a billing data with the number of visits plus 1 is generated. Wherein, the billing data includes the amount that needs to be spent for one visit.

When the billing object is a non-time object such as duration, word count, byte stream, etc., the traditional flow control billing method is: each time a request sent by the user is received, the amount of the billing object is added to n, and the billing object The usage is compared with the upper limit, where n is the number of billing objects consumed by the request. If the upper limit is reached, the access is prohibited; otherwise, the access is allowed, and a billing data of the billing object usage plus n is generated. Wherein, the billing data includes the amount needed to consume n billing objects.

Although these two flow control billing methods can meet the basic needs of flow control billing, it is difficult to guarantee the accuracy of flow control billing in high concurrency scenarios. This is because in high-concurrency scenarios, limited by network jitter and the stability of operator services that process requests sent by users, operator services cannot process requests successfully every time, but operator services fail to process requests. In some cases, billing may also be performed, resulting in billing errors. Therefore, how to avoid the problem of billing even when the operator service fails to process is the difficulty of flow control billing.

To deal with this problem, there are currently two solutions:

Solution 1 is pre-emptive flow control: after receiving the request sent by the user, the flow control billing module estimates whether the number of billing objects required to process the request meets the quota requirements, and if so, directly processes the request and sends the estimated The number of billing objects is added to the number of used billing objects, and a bill is generated. When it is found that the processing of the request sent by the user fails, the data rollback operation is performed, or the generated billing bill is deleted. This solution has both data accumulation logic and data rollback logic, resulting in complex overall logic and high computational pressure on the flow control and billing module, so it is difficult to apply to high-concurrency scenarios. Moreover, users can perceive abnormal bills generated by request processing failures, so general scenarios are not applicable.

Solution 2 is downstream flow control: after receiving the request sent by the user, the flow control and billing module determines whether the user is a normal available user. Among them, the normally available users are users whose number of used billing objects has not exceeded the limit. If it is not a normally available user, the request is rejected. If it is a normal available user, the request is processed directly, and after the request is successfully processed, the number of billing objects consumed by processing the request is added to the number of billing objects used, and a billing bill is generated. Then judge whether the number of used billing objects exceeds the upper limit, and if so, set the user as an unavailable user without quota. If not, keep the user as a normal available user. This solution only bills for successfully processed requests, which can avoid abnormal bills. However, in high-concurrency scenarios, it is difficult to achieve timely traffic control due to the lag in the accumulation of billing objects due to subsequent deduction. It may happen that the user overuses the billing object.

It can be seen that the above two solutions are not suitable for high concurrency scenarios. In order to perform accurate flow control in a high-concurrency scenario, an embodiment of the present disclosure provides a flow control charging method.

First, the nouns involved in the embodiments of the present disclosure are described:

The current estimated billing amount indicates the estimated number of billing objects that will be consumed if the operator service processes the business request received this time.

The estimated billing amount indicates the sum of the current estimated billing amount of each business request being processed by the operator service.

The actual billing amount indicates the number of billing objects actually consumed by the operator service to process the business request received this time.

The successfully billed amount indicates the number of billing objects that have been successfully consumed during the process of the operator service processing the business request received this time.

The available quota indicates the upper limit of the number of billing objects that the user can use.

The flow control billing method provided by the embodiment of the present disclosure can be applied to the flow control billing module, as shown in Figure 1, the method includes the following steps:

S101. Receive a start (begin) request sent by the proxy service.

Wherein, the begin request is sent by the proxy service after receiving the service request sent by the terminal, and the begin request includes the user identification triggering the service request and the current estimated fee for processing the service request.

In one implementation manner, the user sends a service request to the proxy service through the terminal, and the proxy service extracts the traffic type from the service request after receiving the service request. Wherein, the traffic type may be an audio and video type, a text type, or a search type, and the like. Then, according to the preset corresponding relationship between the traffic type and the charging mode, the charging mode corresponding to the extracted traffic type is determined. And according to the determined charging method, determine the current estimated fee amount of the service request. For example, when the billing method is billing according to the duration, the duration of the audio and video data included in the service request is taken as the estimated billing amount for this time; 1. Then the proxy service generates a begin request, wherein the begin request specifically includes: the user ID that triggers the service request, the current estimated billing amount, the session number (Session Number, SN) of the session between the proxy service and the terminal, the charging method and the billing method. The fee interface identity identification number (Identity document, id). Afterwards, the proxy service sends a begin request to the flow control and billing module. Wherein, the session number may also be referred to as a session identifier.

In the embodiment of the present disclosure, the proxy service is used to replace the flow control and billing module to interact with the terminal, and replace the flow control and billing module to interact with the operator service. Among them, the operator service is used to process business requests.

In the embodiment of the present disclosure, there may be multiple operator services, and different operator services are used to implement different processing logics. The billing interface id is the interface id for calling operator services, that is, each operator service corresponds to a The billing interface id, the proxy service can extract the billing interface id from the service request.

S102 , judging whether the sum of the expected billing amount, the estimated billing amount corresponding to the user identifier, and the used amount is greater than the available amount, and a judgment result is obtained. Wherein, the estimated billing amount corresponding to the user ID is the sum of the current estimated billing amounts of the service requests being processed corresponding to the user ID.

Because in a high-concurrency scenario, the same user may send multiple business requests, the business requests can be processed in parallel, and the usage will not be accumulated until the business requests are successfully processed. If for each business request, it is only judged whether the sum of the expected fee amount and the used amount of the business request exceeds the available quota, then when multiple business requests are processed in parallel, because the business requests have not been processed, the accumulated amount will not be accumulated. usage, so that the sum of the expected charge amount and the used amount of each business request does not exceed the available quota, and each business request will be processed normally. However, after the processing is completed, when accumulating the used amount, the actual billing amount of each business request is added to the used amount. At this time, the used amount may exceed the available quota, resulting in the problem of exceeding the actual usage quota.

Therefore, in the embodiment of the present disclosure, for each service request, it is judged whether the sum of the estimated charge amount for processing the service request, the estimated charge amount consumed by the user’s other service requests being processed, and the user’s used amount is Exceeding the available quota, in this way, even if all business requests processed at the same time are successfully processed, when the used amount is accumulated, the used amount will not exceed the available quota, thereby reducing the problem of the actual usage quota exceeding the limit.

For example, assuming billing by the number of times, a user sends two service requests, the user's available quota is 5, and the used quota is 4. When the flow control billing module receives the first request, it will process it normally. But when the second request is received, if the first request is being processed and the used amount is not accumulated at this time, so that the used amount is still 4, then for the second request, the estimated amount of 1 and the used amount of 4 are still used The sum of is compared with the available quota 5, and the result of not exceeding the available quota is obtained, so that the second request will also be processed. But if the two requests are processed successfully, the accumulated amount will be 6, exceeding the available quota.

However, in the embodiment of the present disclosure, when the flow control and billing module receives the first request, it processes it normally. When the second request is received, if the first request is being processed, the estimated amount is 1. At this time, it is judged whether the sum of the estimated amount 1, the estimated amount 1, and the used amount 4 exceeds the available amount 5, A result that exceeds the available quota causes the second request to not be processed. In this way, the problem of excessive usage of billing objects in high concurrency scenarios can be reduced.

S103. Determine whether to respond to the service request based on the judgment result, and accumulate the used amount corresponding to the user identifier based on the response result of the service request.

In an implementation manner, when the judgment result is yes, it is determined to reject the service request of the terminal, and 0 is added to the used amount corresponding to the user identifier, that is, the used amount corresponding to the user identifier remains unchanged. When the judgment result is no, it is determined to respond to the service request of the terminal, and the used amount corresponding to the user identifier is accumulated according to the processing situation of the service request.

As shown in Figure 2a, the traditional flow control billing scheme adopts the straight-line strategy, that is, the flow control billing module is responsible for receiving service requests sent by users, calling operator services to process service requests, and returning the processing results to users. Perform flow control and billing. It can be seen that in this method, the flow control and billing module is responsible for more processing logic, so the processing pressure it bears is relatively high. In high concurrency scenarios, as the traffic pressure increases, it is difficult to guarantee the stability of the flow control and billing module. .

It can be seen from the method shown in FIG. 1 that the embodiment of the present disclosure separates traffic sending and receiving from flow control and charging, that is, as shown in FIG. 2b, the embodiment of the present disclosure adds a proxy service, and the proxy service replaces the flow control and charging module Interact with terminals and operator services, that is, the proxy service is responsible for simple logic processing and does not perform complex logic calculations. The flow control and billing module is responsible for flow control and billing. Since the embodiment of the present disclosure reduces the processing logic of the flow control and charging module, that is, reduces the pressure carried by the flow control and charging module, it is applicable to high concurrency scenarios.

Moreover, in the embodiment of the present disclosure, before processing the service request, the flow control and billing module first judges whether the sum of the expected billing amount, the estimated billing amount and the used amount corresponding to the user ID is greater than the available amount, that is, judges whether the processing business The question of whether the request will cause excess, at this time, the available quota is not directly accumulated, but the available quota is subsequently accumulated according to the response result of the business request. Therefore, even if the service request fails to be processed, there is no need to perform data rollback or deletion, which solves the problem of data rollback or deletion caused by premature billing in advance flow control. In addition, because the embodiment of the present disclosure first judges whether processing a business request will cause an overage problem before processing the business request, it solves the hysteresis of subsequent flow control oversubscription determination, and thus can be applied to high concurrency scenarios.

In an embodiment of the present disclosure, the above-mentioned S103 determines whether to respond to the service request based on the judgment result, and accumulates the used amount corresponding to the user ID based on the response result of the service request, including the following steps:

Step 1. If the judgment result is yes, the flow control and billing module sends a begin failure response to the proxy service, so that the proxy service sends a request failure response to the terminal.

When the sum of the estimated billing amount, the estimated billing amount corresponding to the user ID, and the used amount is greater than the available amount, it means that if all the service requests currently being processed by the user are successfully processed, the difference between the available amount and the accumulated estimated amount The difference is less than the expected fee amount for this time, that is, processing the service request currently sent by the user may cause the used quota to exceed the limit, so the service request is rejected and the request failure is reported to the terminal.

Step 2. If the judgment result is no, the flow control and billing module will add the estimated billing amount to the estimated billing amount corresponding to the user ID, and send a begin success response to the proxy service, so that the proxy service calls the operator service to process the business request, and send an end (end) request to the flow control and billing module when it is determined that the operator service processing is completed. Wherein, the end request includes the actual billing amount consumed by processing the service request.

In the embodiments of the present disclosure, the estimated billing amount represents the sum of the current estimated billing amount of each service request being processed by the operator service. If the sum of the current estimated billing amount, the estimated billing amount and the used amount If it is greater than the available quota, it means that if all the business requests currently being processed by the user are successfully processed, the difference between the available quota and the accumulated estimated billing amount is still greater than or equal to the estimated billing amount of this time, that is, the business request currently sent by the user is processed The used quota will not be exceeded, so the received service request can be processed. Since it has been judged that the business request can be processed at this time, and the business request is about to be forwarded to the operator service for processing, it is necessary to add the current estimated fee amount of the business request to the estimated fee amount.

Wherein, the response of the flow control and accounting module to the begin request may include a status flag, which is used to indicate whether the begin request is successful, so that the proxy service can identify whether the begin request is successful through the status flag. For example, when the status flag is 1, it means that the begin request is successful, and the response at this time is called a begin success response; when the status flag is 0, it means that the begin request fails, and the response at this time is called a begin failure response.

When the proxy service receives a successful response from begin, it forwards the received business request to the operator service, and the operator service processes the business request and forwards the processing result to the proxy service. Wherein, the processing result specifically includes the response result to the service request and the actual billing amount consumed for processing the service request. When the proxy service receives the processing result of the operator service, it determines that the processing of the operator service is completed, and sends an end request to the flow control and billing module. Moreover, when the proxy service receives the processing result of the operator service, it can also feed back the response result to the business request to the terminal.

Step 3: The flow control and billing module receives the end request sent by the proxy service, adds the actual billed amount to the used amount corresponding to the user ID, and deletes the current estimated billed amount from the estimated billed amount corresponding to the user ID.

When the flow control and billing module receives the end request, it means that the operator service has completed processing the business request, so the actual billing amount needs to be added to the user's used amount. At the same time, since the service request has been processed, it is necessary to delete the current estimated amount from the user's estimated amount.

Using the above method, in the embodiment of the present disclosure, before processing the service request, the flow control and billing module performs flow control based on the current estimated fee amount, and the current estimated fee amount is not directly added to the used amount, but is added to the service The actual billed amount will be added to the used amount only after the request processing is completed. That is to say, the embodiment of the present disclosure combines proactive flow control and backward flow control, and there is no accumulated used amount during proactive flow control, so even if the service request processing fails, there is no need to perform data rollback or deletion, which solves the problem of proactive flow control Problems caused by premature billing that require data rollback or deletion. Subsequent flow control can accumulate the used amount according to the actual billing amount consumed when the request is processed successfully, and pre-emptive flow control is performed before post-traffic flow control, and pre-emptive flow control can reduce traffic overuse, that is, in On the basis of accurate flow control, it solves the problem that subsequent flow control easily leads to excessive use of flow. Therefore, the embodiments of the present disclosure can perform accurate flow control in high concurrency scenarios.

In an embodiment of the present disclosure, because the operator service may successfully process the service request, it may also fail to process it. Regardless of whether the processing succeeds or fails, the billing amount actually consumed by the computing sub-service in the process of processing the business request can be counted, so that the subsequent analysis and statistics of the processing results of the computing sub-service can be performed. Therefore, no matter whether the operator service is processed successfully or not, the processing result can include the actual billing amount consumed by processing the service request. In order for the flow control billing module to distinguish whether the operator service is successfully processed, the actual billing amount of the successfully processed business request is added to the used amount, and the actual billing amount of the failed business request is not added to the used amount. In , it is necessary to distinguish between the actual billing amount when the service request is processed successfully and the actual billing amount when the service request fails to be processed. The embodiment of the present disclosure sets a status code (status_code), which is used to indicate whether the service request is processed successfully. The proxy service can extract the status code from the processing result fed back by the operator service for the business request, and generate an end request including the status code.

Therefore, after receiving the end request, the flow control and billing module needs to judge whether the actual charging amount needs to be accumulated, including the following steps: judging whether the status code in the end request indicates that the service request is processed successfully, wherein the end request includes the status code. If not, it is determined that the actual charging amount consumed for processing the service request is 0, and the used amount corresponding to the user identifier remains unchanged. If yes, obtain the actual billing amount from the end request, and perform the step of adding the actual billing amount to the used amount corresponding to the user ID in step 3.

For example, when the status code is -1, it means that there is an internal error in the operator service, that is, the business request processing failed; when the status code is 0, it means that the calculation of the business request by the operator service is normal, that is, the business request is processed successfully.

In the embodiment of the present disclosure, the status code is used to distinguish whether the service request is successfully processed, so that the flow control and charging module can use the status code to distinguish whether the actual charging amount needs to be added to the used amount. And no matter whether the service request is processed successfully, the end request can include the actual billing amount, so that the flow control billing module can store the actual billing amount of each service request, which is convenient for subsequent statistical analysis.

In one embodiment of the present disclosure, since the communication between the proxy service and the flow control and billing module may be unstable, if the flow control and billing module receives at least two end request, the flow control billing module may mistakenly add the actual billed amount in the end request to the used amount for multiple consecutive times, resulting in billing errors.

In order to reduce such errors, in the embodiment of the present disclosure, both the begin request and the end request include the session identifier of the session between the proxy service and the terminal.

Therefore, before S102 judges whether the sum of the expected charge amount, the estimated charge amount corresponding to the user ID, and the used amount is greater than the available amount, the flow control and billing module can also record the session ID in the begin request.

Specifically, after receiving the begin request, the flow control billing module can perform data analysis and preprocessing on the begin request, including: extracting from the begin request the user ID that triggers the service request, the expected charge amount, SN, and billing method and billing interface id and other data, and store the extracted data correspondingly. In the embodiments of the present disclosure, the data extracted from the begin request, the estimated billing amount, the successfully billed amount, the actual billed amount, and the used amount are collectively referred to as billing data.

Optionally, the flow control and billing module can store the billing data in a distributed remote dictionary service (Remote Dictionary Server, Redis), wherein the distributed Redis includes multiple fragments, and the flow control and billing module can be based on user ID, and store the billing data of the same user in the same shard of distributed Redis. This makes it convenient for the flow control billing module to find the billing data of the same user from the same shard when looking for billing data. Compared with the method of finding the billing data of the same user from multiple shards, The embodiments of the present disclosure can improve search efficiency, and thus are more suitable for high concurrency scenarios.

After S102 judges whether the sum of the expected billing amount, the estimated billing amount corresponding to the user ID, and the used amount is greater than the available amount, the flow control and billing module may also delete the recorded session ID when the judgment result is yes. Understandably, since the flow control billing module judges that the sum of the expected billing amount, the estimated amount corresponding to the user ID, and the used amount is greater than the available amount, it returns a begin failure response to the proxy service. At this time, the business request does not will be processed, so delete the recorded session id.

Before step 3 adds the actual billing amount to the used amount corresponding to the user ID, the flow control billing module can also inquire whether the session ID in the end request has been recorded; if so, delete the recorded session ID; if not, then End requests are ignored.

It can be understood that when the flow control and billing module receives the end request, if the session identifier included in the end request is not recorded, it means that the service request corresponding to the session identifier has not been processed or has been processed, so the end request can be ignored. If the session ID included in the end request is recorded, it means that the service request corresponding to the session ID is currently processed and needs to be billed. Therefore, the flow control billing module will add the actual billing amount to the used amount corresponding to the user ID. Delete the session ID to avoid repeated charging for subsequent service requests corresponding to the session ID.

Using the above method, the flow control and charging module identifies the processing status of the service request corresponding to the session ID through the session ID, thereby reducing the situation of repeated charging for the service request that has been processed.

In one embodiment of the present disclosure, in order to further improve the accuracy of flow control and billing, the embodiment of the present disclosure is based on the requirements of long sessions, and on the basis of combining pre-flow control and post-flow control, between the begin request and the end request Increase the refreshing of doing heartbeats. As shown in Figure 3, after the flow control and billing module sends a begin success response to the proxy service in the above step 2, and before receiving the end request in step 3, it can also perform the following steps:

S301. Receive a processing (doing) request sent by the proxy service. Among them, the doing request includes the successfully billed amount consumed by the operator service currently processing the business request.

In one implementation, the proxy service can obtain the successfully billed amount consumed by processing business requests in real time from the operator service, and periodically send a doing request to the flow control and billing module, so that the flow control and billing module can timely Get the current successfully billed amount.

S302. Obtain the successfully billed amount from the doing request, update the current estimated billed amount in the estimated billed amount corresponding to the user ID to the obtained successfully billed amount, and determine the current estimated billed amount and the user ID Whether the sum of the corresponding used amount is greater than the available amount. If not, execute S303; if yes, execute S304.

Since the estimated billing amount determined for the first time is the estimated billing amount for processing business requests, not the real billing amount, and the successful billing amount is the real billing amount consumed by processing business requests, so flow control When the billing module obtains the successfully billed amount, it can update the estimated billed amount to the successfully billed amount, so as to perform traffic control based on the real billed amount. And when the doing request is continuously received subsequently, the current estimated billing amount can be updated to the successfully billed amount included in the latest received doing request, so that flow control can be performed in real time according to the real billing amount.

That is, the current estimated amount recorded in the flow control billing module is the estimated amount included in the begin request, or the successfully billed amount included in the latest received doing request.

S303. Send a doing success response to the proxy service, so that the proxy service sends an end request to the flow control and charging module when it is determined that the processing of the operator service is completed. The actual billing amount included in the end request is the total billing amount consumed by the operator service from the start of processing the business request to the completion of the processing.

Wherein, the response of the flow control and billing module to the doing request may include a doing status flag, which is used to indicate whether the doing request is successful, so that the proxy service can identify whether the doing request is successful through the doing status flag. For example, in the response sent by the flow control and accounting module to the proxy service for the doing request, if the doing status flag is 1, it means that the doing request is successful, and the response is called a doing success response; if the doing status flag is 0, it means If the doing request fails, the response is called a doing failure response.

When the proxy service receives a successful response of doing, it means that there is no overrun problem in the current processing of business requests, so the business requests can continue to be executed.

S304. Send a doing failure response to the proxy service, so that the proxy service terminates the operator service to process the business request, and determines that the actual billing amount is the successfully billed amount consumed by the operator service currently processing the business request, and sends the determined The end request of the actual billing amount.

When the proxy service receives a doing failure response, it means that the current processing business request has exceeded the limit and needs to stop processing the business request. Therefore, the proxy service can send a termination notification message to the operator service, so that the operator service stops processing the business request, and When the processing of the business request is stopped, the successfully billed amount consumed by the current processing of the business request is sent to the proxy service. The proxy service generates an end request based on the status code indicating that the business request processing failed and the received successful billing amount, and sends the end request to the flow control billing module.

After receiving the end request, the flow control and billing module performs flow control and billing according to the relevant steps in the above step 3.

Using the above method, the flow control billing module can obtain the successfully billed amount of the operator service processing business request in real time through the doing heartbeat mechanism, and the successful billed amount is the real usage, so the traffic billing module can real-time Traffic control and billing are performed based on actual usage.

It should be noted that before the proxy service sends the doing request, it can also determine whether the billing method is billing by the number of times. When the billing method is billing according to the number of times, the session between the terminal and the proxy service is a short connection session. At this time, the doing heartbeat mechanism shown in Figure 3 may not be executed, or, when the doing heartbeat mechanism is executed, the operator is set The service is billed 1 per successful transfer to the proxy service.

On the contrary, when the billing method is not billing according to the number of times, the session between the terminal and the proxy service is generally a long connection session, so the doing heartbeat mechanism shown in FIG. 3 can be implemented.

In an embodiment of the present disclosure, since the operator service starts to process the business request, the amount of successful billing is small, and the amount of successful billing increases as the processing time increases. Therefore, the successful billing amount received by the flow control billing module in the early stage of business request processing is relatively small. When the successfully billed amount is small, the current estimated billing amount will not be updated for the time being. That is, after the flow control and billing module obtains the successfully billed amount from the doing request in S302, it can also perform the following steps:

Determine whether the successfully billed amount is greater than the current estimated billing amount. If yes, execute the step of updating the estimated billing amount for this time among the estimated billing amounts corresponding to the user identifier in S302 to the obtained successfully billed amount. If not, keep the estimated billing amount unchanged, and execute the step of judging whether the sum of the current estimated billing amount and the used amount corresponding to the user identifier is greater than the available quota in S302.

Using the above method, the flow control billing module does not update the estimated billing amount for the time being when the successful billing amount is less than or equal to the estimated billing amount, that is, does not update the estimated billing amount when the successful billing amount is small . If the current estimated charge amount in the estimated charge amount is small, the current flow control based on the estimated charge amount may be inaccurate, resulting in an overuse problem. Therefore, in the embodiment of the present disclosure, when the successfully billed amount is greater than the current estimated billed amount, the current estimated billed amount in the estimated billed amount is updated to the successfully billed amount, so as to reduce the problem of overuse. Moreover, the actual billing amount of the business request may be greater than the estimated billing amount of this time. Therefore, when the successful billing amount is greater than the estimated billing amount of this time, updating the estimated billing amount of this time in time can also reduce the estimated amount of this time. The problem of excess usage caused by the billed amount being less than the actual billed amount.

In one embodiment of the present disclosure, the end request sent by the proxy service may be lost due to network or other problems. If the flow control and billing module does not receive the end request, it will always save the current estimated billing amount obtained through the begin request. , and it is also impossible to correctly charge the service request.

In order to solve this problem, in the embodiment of the present disclosure, a scheduled garbage collection (Garbage Collection, GC) task is set in the flow control billing module, as shown in Figure 4, the flow control billing module can also perform the following steps:

S401. If a doing request or an end request is not received for a preset duration, judge whether the successfully billed amount carried in the doing request has been obtained. If yes, execute S402; if not, execute S403.

In one implementation manner, after receiving a begin request or a doing request last time, if the doing request or the end request is not received for a preset period of time, it may be considered that the session ends abnormally. At this point, it can be judged whether the successfully billed amount has been obtained from the doing request before.

S402. Determine that the actual billing amount is the successfully billed amount acquired from the doing request last time.

If you have obtained the successfully billed amount carried in the doing request, the last successfully billed amount obtained from the doing request is closest to the actual billed amount consumed by processing the service request, so the actual billed amount is determined as the latest The successfully billed amount obtained from a doing request.

S403. Determine that the actual billing amount is 0.

If the successfully billed amount carried in the doing request has not been obtained, it means that the service request may not be processed, so it is determined that the actual billed amount is 0.

S404. Add the determined actual billing amount to the used amount corresponding to the user ID, and delete the current estimated billing amount from the estimated billing amount corresponding to the user ID.

Since no doing request or end request is received for the preset duration, it is determined that the session ends abnormally and the processing of the service request stops, so billing is required, that is, the actual billed amount is added to the used amount corresponding to the user ID. And because the processing of the service request has stopped, it is necessary to delete the current estimated amount from the estimated amount corresponding to the user ID.

Using the above method, the flow control billing module can perform timely billing when the session ends abnormally through the scheduled GC task, and clear up the estimated billing amount in time to reduce the storage resources occupied by invalid withholding usage.

In an embodiment of the present disclosure, after the above step 3 or S404 deletes the current estimated amount from the estimated amount corresponding to the user ID, the flow control and billing module can also calculate the actual billing amount based on The actual billing amount generates this billing bill.

Wherein, the charging bill includes: the actual billing amount, the fee calculated based on the actual billing amount, and a time stamp. The timestamp may be the time when the proxy service receives the business request, or the time when the business request is processed.

In the embodiment of the present disclosure, when the service request processing is completed and the actual billing amount is not 0, the current billing bill can be regenerated, that is, when the service request processing fails, the actual billing amount is 0, and no billing bill will be generated at this time. Therefore, it avoids the problem that the charging bills generated in advance in the pre-emptive flow control scheme need to be deleted after the service request makes an error.

Based on the same inventive concept, corresponding to the method embodiment shown in FIG. 1, the embodiment of the present disclosure also provides a flow control charging method, which is applied to proxy services. As shown in FIG. 5, the method includes the following steps:

S501. Receive a service request sent by a terminal. Wherein, the service request includes the ID of the user who triggers the service request.

S502. Determine the current estimated fee amount of the service request.

Wherein, for specific implementation manners of S501 and S502, reference may be made to the description in S101 above, and details are not repeated here.

S503. Send a begin request carrying the user ID and the estimated amount of charge to the flow control and billing module, so that the flow control and billing module judges whether the sum of the estimated charge amount, the estimated charge amount and the used amount corresponding to the user identifier is greater than the available amount Quota, get the judgment result, determine whether to respond to the business request based on the judgment result, and accumulate the used amount corresponding to the user ID based on the response result of the business request. Wherein, the estimated billing amount corresponding to the user ID is the sum of the current estimated billing amounts of the service requests being processed corresponding to the user ID.

Wherein, for the specific implementation manner of S503, reference may be made to the description in S102 above, which will not be repeated here.

It can be seen from the method shown in FIG. 5 that the embodiment of the present disclosure separates traffic sending and receiving from flow control billing, that is, as shown in FIG. 2b, the embodiment of the present disclosure adds a proxy service, and the proxy service replaces the stream control billing module Interact with terminals and operator services, that is, the proxy service is responsible for simple logic processing and does not perform complex logic calculations. The flow control and billing module is responsible for flow control and billing. Since the embodiment of the present disclosure reduces the processing logic of the flow control and charging module, that is, reduces the pressure carried by the flow control and charging module, it is applicable to high concurrency scenarios.

In an embodiment of the present disclosure, after the above S503, the proxy service may also perform the following steps:

Step 1. Identify whether the received response sent by the flow control and accounting module to the begin request is a begin failure response or a begin success response.

Step 2. If the begin failure response sent by the flow control and accounting module is received, send a request failure response to the terminal.

If the begin failure response sent by the flow control and billing module is received, it means that the processing of the business request may lead to a quota limit problem, so a request failure response is sent to the terminal.

Wherein, for the specific implementation manner of step 2, reference may be made to the description in the above step 1, which will not be repeated here.

Step 3. If the begin success response sent by the flow control and billing module is received, the service request is forwarded to the operator service, so that the operator service processes the service request.

If the begin success response sent by the flow control and billing module is received, it means that the processing of business requests generally does not cause the problem of exceeding the quota, so the operator service can be controlled to process business requests.

Wherein, for the specific implementation manner of step 3, reference may be made to the description in the above step 2, which will not be repeated here.

Step 4. When it is determined that the operator service has completed the processing of the business request, send an end request to the flow control and billing module, so that the flow control and billing module will add the actual billing amount consumed by processing the business request included in the end request to the user In the used amount corresponding to the ID, delete the estimated billing amount for this time from the estimated billed amount corresponding to the user ID.

Wherein, for the specific implementation manner of step 4, reference may be made to the description in the above step 2, which will not be repeated here.

Using the above method, before processing the service request, the flow control and billing module in the embodiment of the present disclosure performs flow control based on the current estimated fee amount, and the current estimated fee amount is not directly added to the billed amount, but is added to the service The actual billed amount is added to the billed amount only after the request processing is completed. That is to say, the embodiment of the present disclosure combines the advanced flow control and the backward flow control, and the billed amount is not accumulated during the advanced flow control, so even if the service request processing fails, there is no need to perform data rollback or deletion, which solves the problem of the advanced flow Problems that require data rollback or deletion caused by premature billing of the control. Subsequent flow control can accumulate the used amount according to the actual billing amount consumed when the request is processed successfully, and pre-emptive flow control is performed before post-traffic flow control, and pre-emptive flow control can reduce traffic overuse, that is, in On the basis of accurate flow control, it solves the problem that subsequent flow control easily leads to excessive use of flow. Therefore, the embodiments of the present disclosure can perform accurate flow control in high concurrency scenarios.

In an embodiment of the present disclosure, in order to further improve the accuracy of flow control and billing, after the above step 3 forwards the business request to the operator service, as shown in Figure 6, the proxy service can also perform the following steps:

S601. Obtain in real time the successfully billed amount consumed by the current service request processing from the operator service.

In one implementation manner, the operator service may send the successful billing amount consumed by the previously processed service request to the proxy service in real time during the process of processing the service request.

S602. Periodically send a doing request carrying a successfully billed amount to the flow control and billing module, so that the flow control and billing module obtains the successfully billed amount from the doing request, and includes the estimated billed amount corresponding to the user identifier Update the estimated billing amount of this time to the successfully billed amount obtained, and judge whether the sum of the current estimated billing amount and the used amount corresponding to the user ID is greater than the available amount, if not, send a doing success response to the proxy service, If so, send a doing failure response to the proxy service.

Wherein, for the specific implementation manner of S602, reference may be made to the above descriptions in S302-S304, which will not be repeated here.

S603. If the doing failure response sent by the flow control and billing module is received, terminate the operator service to process the business request, and determine that the actual billing amount is the successfully billed amount consumed by the operator service currently processing the business request, based on the determination The actual billing amount generates an end request, and sends the generated end request to the flow control billing module.

In the embodiment of the present disclosure, if the doing success response sent by the flow control and billing module is received, it means that there is no overage problem in currently processing the service request, so the service request can continue to be processed.

Wherein, for the specific implementation manner of S603, reference may be made to the description in S304 above, which will not be repeated here.

Using the above method, through the doing heartbeat mechanism, the flow control billing module can obtain the successfully billed amount of the operator service processing business request in real time, and the successful billed amount is the real usage, so the traffic billing module can real-time Traffic control and billing are performed based on actual usage.

In the flow control and charging method applied to the proxy service and the flow control and charging method applied to the flow control and charging module, the realization of the same steps can be referred to each other.

The specific process of the flow control and billing method provided by the embodiment of the present disclosure is described below in conjunction with the application scenario:

Referring to Figure 7, after receiving the begin request, the flow control and billing module performs data analysis and preprocessing on the begin request, specifically: extracting the user ID that triggers the service request, the estimated amount of charge, SN, and billing method from the begin request and billing interface id and other data, and record the extracted data correspondingly. Then call the lua script of begin, and the processing process of the lua script of begin is the steps in the dotted line box in Fig. 7. Among them, lua is a small scripting language that can be flexibly embedded in applications, thus providing flexible expansion and customization functions for applications.

By calling the lua script of begin, lock the session identifier of the session, that is, record the SN, and judge whether the locking is successful. If unsuccessful, return a begin failure response to the proxy service. If it succeeds, it is judged whether the sum of the expected charge amount, the estimated charge amount corresponding to the user ID, and the used amount is greater than the available amount. If it is greater than, the lock is released, that is, the recorded SN is deleted, and a begin failure response is returned to the proxy service. If it is not greater, add the estimated fee amount to the estimated fee amount. Store session data information, specifically store the data extracted from the begin request to distributed Redis. Then return a begin success response to the proxy service.

Referring to Figure 8, after receiving the end request, the flow control and billing module performs data analysis and preprocessing on the end request, specifically: extracting SN, status_code and actual billing amount from the end request, and corresponding records. Then judge whether the status_code is 0; if not, set the actual billing amount to 0, and if so, call the lua script of end. The processing process of the lua script of end is the steps in the dashed box in Figure 8.

By calling the lua script of end, release the lock of the SN of the session, and judge whether the lock release is successful, if not, delete the session data information corresponding to the SN. If successful, add the extracted actual charging amount to the used amount corresponding to the user ID, and delete the current estimated billing amount from the estimated billing amount corresponding to the user ID.

Then it is judged whether the actual charging amount is non-zero, and if not, the session data information corresponding to the SN is deleted. If yes, generate a current billing bill according to the actual billing amount, and then delete the session data information corresponding to the SN. Afterwards, an end response is returned to the proxy service, indicating that the charging for this session is completed.

Referring to Figure 9, after receiving the doing request, the flow control and billing module performs data analysis and preprocessing on the doing request, specifically: extracting the SN and the successfully billed amount, and corresponding records. Then call the lua script of doing, and the processing process of the lua script of doing is the steps in the dotted line box in Fig. 9 .

By calling the lua script of doing, determine whether the lock of the session identifier exists, that is, whether the SN is recorded. If it does not exist, return a doing failure response to the proxy service. If it exists, update the latest processing time to the current time, and judge whether the successfully billed amount is greater than the expected billing amount this time. If it is greater, update the current estimated billing amount in the estimated billing amount corresponding to the user identifier to the successfully billed amount. If not greater than, keep the estimated cost unchanged. Then it is judged whether the sum of the current estimated billing amount and the used amount corresponding to the user identifier is greater than the available amount. If it is greater than, return a doing failure response to the proxy service. If it is not greater than, return a doing success response to the proxy service.

Referring to Figure 10, the flow control and billing module detects in real time whether there is a timeout session, that is, for each SN, it is judged whether the doing request including the SN has not been received for a preset period of time after receiving the begin or doing request of the SN last time or end request. If not, return to continue detection. If yes, it is judged whether the timed out session has been marked with the successful billing amount by doing, that is, whether the successful billing amount carried in the doing request has been obtained. If not marked, set the actual billing amount to 0. If marked, set the actual billing amount to the last successful billing amount obtained from the doing request. Then call the lua script of end.

Then it is judged whether the actual charging amount is non-zero, and if not, the session data information corresponding to the SN is deleted. If yes, then generate the current billing bill according to the actual billing amount, and then delete the session data information corresponding to the SN. Then return to continue to detect whether there is a timeout session.

For the specific implementation manners of FIGS. 7-10 , reference may be made to the above related descriptions.

Based on the same inventive concept, corresponding to the above-mentioned method embodiments, an embodiment of the present disclosure provides a flow control and charging device, which is applied to the flow control and charging module. As shown in FIG. 11 , the device includes: a first receiving module 1101 , judgment module 1102 and accumulation module 1103;

The first receiving module 1101 is used to receive the begin request sent by the proxy service. The begin request is sent by the proxy service after receiving the service request sent by the terminal. The begin request includes the user identification that triggers the service request and the current estimated fee for processing the service request quantity;

The judging module 1102 is used to judge whether the sum of the expected billing amount, the estimated billing amount corresponding to the user ID, and the used amount is greater than the available amount, and obtain the judgment result; The sum of the current estimated fee volume of each service request processed;

The accumulation module 1103 is configured to determine whether to respond to the service request based on the judgment result of the judgment module 1102, and to accumulate the used amount corresponding to the user identifier based on the response result of the service request.

In an embodiment of the present disclosure, the accumulation module 1103 is specifically used for:

If the judgment result of the judging module 1102 is yes, then send a begin failure response to the proxy service, so that the proxy service sends a request failure response to the terminal;

If the judging result of the judging module 1102 is no, then add the estimated billing amount to the estimated billing amount corresponding to the user identifier, and send a begin success response to the proxy service, so that the proxy service calls the operator service to process the business request, and When it is determined that the operator service processing is completed, an end request is sent to the flow control and billing module, and the end request includes the actual billing amount consumed by processing the business request;

Receive the end request sent by the proxy service, add the actual billing amount to the used amount corresponding to the user ID, and delete the estimated billing amount from the estimated billing amount corresponding to the user ID.

In an embodiment of the present disclosure, the end request includes a status code, and the status code is used to indicate whether the service request is processed successfully; the device may also include: an actual charging amount determination module and an acquisition module;

The judging module 1102 is also used to judge whether the status code in the end request indicates that the business request is processed successfully after receiving the end request sent by the proxy service;

The actual billing amount determination module is used to determine that the actual billing amount consumed by processing the service request is 0 if the judgment result of the judging module 1102 is no, and keep the used amount corresponding to the user identification unchanged;

The acquiring module is configured to acquire the actual billing amount from the end request if the judging result of the judging module 1102 is yes, and perform the step of adding the actual billing amount to the used amount corresponding to the user identifier.

In an embodiment of the present disclosure, both the begin request and the end request include the session identifier of the session between the proxy service and the terminal; the device may also include: a recording module, a deletion module and a query module;

The recording module is used to record the session ID in the begin request before judging whether the sum of the estimated billing amount, the estimated billing amount and the used amount corresponding to the user ID is greater than the available amount;

The deletion module is used to delete the recorded session identification after judging whether the sum of the estimated amount of charge, the estimated amount corresponding to the user ID, and the amount used is greater than the available amount;

The query module is used to query whether the session ID in the end request has been recorded before adding the actual billing amount to the used amount corresponding to the user ID; if so, delete the recorded session ID; if not, ignore the end request.

In an embodiment of the present disclosure, the device may further include: a first sending module;

The first receiving module 1101 is also configured to receive the processing doing request sent by the proxy service after sending the begin success response to the proxy service and before receiving the end request sent by the proxy service, the doing request includes the current processing business request of the operator service The successfully billed amount consumed;

The judging module 1102 is also used to obtain the successfully billed amount from the doing request, update the current estimated billed amount in the estimated billed amount corresponding to the user identifier to the acquired successful billed amount, and judge the current estimated billed amount Whether the sum of the fee amount and the used amount corresponding to the user ID is greater than the available amount;

The first sending module is configured to send a doing success response to the proxy service if the judgment result of the judging module 1102 is no, so that the proxy service sends an end request to the flow control and charging module when it is determined that the operator service processing is completed;

The first sending module is also configured to send a doing failure response to the proxy service if the judgment result of the judging module 1102 is yes, so that the proxy service terminates the operator service to process the business request, and determines that the actual billing amount is the current operator service Process the successfully billed amount consumed by the service request, and send an end request carrying the determined actual billed amount.

In an embodiment of the present disclosure, the device may further include: a calling module;

The judging module 1102 is also used for judging whether the successfully billed amount is greater than the expected billing amount after obtaining the successfully billed amount from the doing request;

The calling module is used to call the judging module 1102 to execute the step of updating the current estimated charging amount in the estimated charging amount corresponding to the user identification to the acquired successful charging amount if the judgment result of the judging module 1102 is yes;

The calling module is also used to keep the estimated billing amount unchanged if the judging result of the judging module 1102 is no, and call the judging module 1102 to judge whether the sum of the current estimated billing amount and the used amount corresponding to the user identification is greater than the available amount Quota steps.

In an embodiment of the present disclosure, the device may further include: an actual billing amount determination module and a deletion module;

The judging module 1102 is also used to judge whether the successful billing amount carried in the doing request has been obtained if the doing request or the end request has not been received for a preset duration;

The actual billing amount determination module is used to determine that the actual billing amount is the successful billing amount obtained from the doing request last time if the judging result of the judging module 1102 is yes;

The actual billing amount determination module is also used to determine that the actual billing amount is 0 if the judgment result of the judging module 1102 is no;

The deletion module is used to add the actual billing amount determined by the actual billing amount determination module to the used amount corresponding to the user ID, and delete the current estimated billing amount from the estimated billing amount corresponding to the user ID.

In an embodiment of the present disclosure, the device may further include: a generating module;

The generating module is configured to generate a current bill based on the actual billing amount when the actual billing amount is greater than zero after deleting the current estimated billing amount from the estimated billing amount corresponding to the user identifier.

Based on the same inventive concept, corresponding to the above-mentioned method embodiments, the embodiment of the present disclosure provides a device for flow control and billing, which is applied to proxy services. As shown in FIG. 12 , the device includes: a second receiving module 1201, this The estimated fee amount determination module 1202 and the second sending module 1203;

The second receiving module 1201 is configured to receive a service request sent by a terminal, where the service request includes a user identifier triggering the service request;

The current estimated fee amount determination module 1202 is used to determine the current estimated fee amount of the service request;

The second sending module 1203 is configured to send a begin request carrying a user identifier and an estimated billing amount to the flow control and billing module, so that the stream control and billing module can determine the estimated billing amount, the estimated billing amount corresponding to the user identifier, and the Determine whether the sum of usage is greater than the available quota. Based on the judgment result, determine whether to respond to the business request, and based on the response result of the business request, add up the used amount corresponding to the user ID. The estimated amount corresponding to the user ID is the amount corresponding to the user ID. The sum of the current estimated charge amount of each service request being processed.

In an embodiment of the present disclosure, the device may further include: an identification module;

The identification module is used to identify whether the received response sent by the flow control and accounting module to the begin request is a begin failure response or a begin success response after sending a begin request carrying a user identifier and an estimated amount to the flow control and accounting module;

The second sending module 1203 is further configured to send a request failure response to the terminal if the begin failure response sent by the flow control and billing module is received;

The second sending module 1203 is further configured to forward the service request to the operator service if the begin success response sent by the flow control and billing module is received, so that the operator service processes the service request;

The second sending module 1203 is further configured to send an end request to the flow control and billing module when it is determined that the operator service has completed the processing of the service request, so that the flow control and billing module will use the end request to process the service request. The actual billed amount is added to the used amount corresponding to the user ID, and the current estimated billing amount is deleted from the estimated billed amount corresponding to the user ID.

In an embodiment of the present disclosure, the device may further include: an acquisition module;

The obtaining module is used to obtain the successfully billed amount consumed by the current processing business request from the operator service in real time after forwarding the service request to the operator service;

The second sending module 1203 is also configured to periodically send a doing request carrying a successfully charged amount to the flow control and charging module, so that the flow control and charging module obtains the successfully charged amount from the doing request, and identifies the user In the corresponding estimated billing amount, the current estimated billing amount is updated to the obtained successfully billed amount, and it is judged whether the sum of the current estimated billing amount and the used amount corresponding to the user ID is greater than the available amount, and if not, send to The proxy service sends a doing success response, and if so, sends a doing failure response to the proxy service;

The second sending module 1203 is further configured to terminate the operator service processing business request if receiving the doing failure response sent by the flow control and charging module, and determine that the actual billing amount is the consumed current processing business request of the operator service Successful billing amount, generate an end request based on the determined actual billing amount, and send the generated end request to the flow control billing module.

Based on the same inventive concept, corresponding to the above-mentioned method embodiments, an embodiment of the present disclosure provides a flow control billing system, as shown in FIG. 1303;

A flow control and billing module 1302, configured to execute the method steps performed by the flow control and billing module in the above method embodiments;

Proxy service 1301, configured to execute the method steps performed by the proxy service in the above method embodiments;

Operator service 1303, used to process business requests.

In the technical solution of the present disclosure, the collection, storage, use, processing, transmission, provision, and disclosure of billing data involved are all in compliance with relevant laws and regulations, and do not violate public order and good customs.

It should be noted that the service request in this embodiment is not a request for a specific user, and cannot reflect the personal information of a specific user.

According to the embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

FIG. 14 shows a schematic block diagram of an example electronic device 1400 that may be used to implement embodiments of the present disclosure. Electronic device is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are by way of example only, and are not intended to limit implementations of the disclosure described and/or claimed herein.

As shown in FIG. 14 , an electronic device 1400 includes a computing unit 1401, which can perform calculations according to a computer program stored in a read-only memory (ROM) 1402 or a computer program loaded from a storage unit 1408 into a random access memory (RAM) 1403. Various appropriate actions and processes are performed. In the RAM 1403, various programs and data necessary for the operation of the electronic device 1400 can also be stored. The computing unit 1401, ROM 1402, and RAM 1403 are connected to each other through a bus 1404. An input/output (I/O) interface 1405 is also connected to the bus 1404 .

Multiple components in the electronic device 1400 are connected to the I/O interface 1405, including: an input unit 1406, such as a keyboard, a mouse, etc.; an output unit 1407, such as various types of displays, speakers, etc.; a storage unit 1408, such as a magnetic disk, an optical disk etc.; and a communication unit 1409, such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 1409 allows the electronic device 1400 to exchange information/data with other devices through a computer network such as the Internet and/or various telecommunication networks.

The computing unit 1401 may be various general-purpose and/or special-purpose processing components having processing and computing capabilities. Some examples of computing units 1401 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processing processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1401 executes various methods and processes described above, such as flow control and charging methods. For example, in some embodiments, the flow control billing method may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 1408 . In some embodiments, part or all of the computer program can be loaded and/or installed on the electronic device 1400 via the ROM 1402 and/or the communication unit 1409. When the computer program is loaded into the RAM 1403 and executed by the computing unit 1401, one or more steps of the flow control charging method described above can be performed. Alternatively, in other embodiments, the computing unit 1401 may be configured in any other appropriate way (for example, by means of firmware) to execute the flow control and charging method.

Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips Implemented in a system of systems (SOC), complex programmable logic device (CPLD), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer programs executable and/or interpreted on a programmable system including at least one programmable processor, the programmable processor Can be special-purpose or general-purpose programmable processor, can receive data and instruction from storage system, at least one input device, and at least one output device, and transmit data and instruction to this storage system, this at least one input device, and this at least one output device an output device.

Program codes for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special purpose computer, or other programmable data processing devices, so that the program codes, when executed by the processor or controller, make the functions/functions specified in the flow diagrams and/or block diagrams Action is implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include one or more wire-based electrical connections, portable computer discs, hard drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.

To provide for interaction with the user, the systems and techniques described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user. ); and a keyboard and pointing device (eg, a mouse or a trackball) through which a user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and can be in any form (including Acoustic input, speech input or, tactile input) to receive input from the user.

The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., as a a user computer having a graphical user interface or web browser through which a user can interact with embodiments of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system. The components of the system can be interconnected by any form or medium of digital data communication, eg, a communication network. Examples of communication networks include: Local Area Network (LAN), Wide Area Network (WAN) and the Internet.

A computer system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, a server of a distributed system, or a server combined with a blockchain.

It should be understood that steps may be reordered, added or deleted using the various forms of flow shown above. For example, each step described in the present disclosure may be executed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in the present disclosure can be achieved, no limitation is imposed herein.

The specific implementation manners described above do not limit the protection scope of the present disclosure. It should be apparent to those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present disclosure shall be included within the protection scope of the present disclosure.

Claims

A flow control billing method applied to a flow control billing module, comprising:

Receiving a start request sent by the proxy service, the begin request is sent by the proxy service after receiving the service request sent by the terminal, the begin request includes the user ID that triggers the service request and the script for processing the service request Estimated fee amount;

Judging whether the sum of the expected charge amount for this time, the estimated charge amount corresponding to the user identifier, and the used amount is greater than the available amount, and obtain a judgment result; the estimated charge amount corresponding to the user identifier is the amount corresponding to the user identifier The sum of the current estimated cost of each service request being processed;

Based on the judgment result, determine whether to respond to the service request, and accumulate the used amount corresponding to the user identifier based on the response result of the service request.
The method according to claim 1, wherein, based on the judgment result, determining whether to respond to the service request, and accumulating the used amount corresponding to the user identifier based on the response result of the service request, includes:

If the judgment result is yes, then send a begin failure response to the proxy service, so that the proxy service sends a request failure response to the terminal;

If the judgment result is no, then add the current estimated billing amount to the estimated billing amount corresponding to the user identifier, and send a begin success response to the proxy service, so that the proxy service calls the operator service to process the The service request, and when it is determined that the operator service processing is completed, send an end request to the flow control and charging module, the end request includes the actual billing amount consumed by processing the service request;

Receive the end request sent by the proxy service, add the actual billing amount to the used amount corresponding to the user ID, and delete the current estimated billing amount from the estimated billing amount corresponding to the user ID .
According to the method according to claim 2, the end request includes a status code, and the status code is used to indicate whether the business request is processed successfully; after receiving the end request sent by the proxy service, the method further include:

Judging whether the status code in the end request indicates that the business request has been processed successfully;

If not, then determine that the actual billing amount consumed by processing the service request is 0, and keep the used amount corresponding to the user identifier unchanged;

If yes, the actual billing amount is obtained from the end request, and the step of adding the actual billing amount to the used amount corresponding to the user identifier is executed.
According to the method according to claim 2 or 3, both the begin request and the end request include the session identifier of the session between the proxy service and the terminal;

Before judging whether the sum of the current estimated billing amount, the estimated billing amount corresponding to the user identifier, and the used amount is greater than the available quota, the method further includes: recording the session identifier in the begin request;

After judging whether the sum of the current estimated billing amount, the estimated billing amount corresponding to the user identifier, and the used amount is greater than the available quota, the method further includes: if yes, deleting the recorded session identifier;

Before adding the actual charging amount to the used amount corresponding to the user identifier, the method further includes: querying whether the session identifier in the end request has been recorded; if so, deleting the recorded Session ID; if not, the end request is ignored.
The method according to claim 2, after sending a begin success response to the proxy service and before receiving the end request sent by the proxy service, the method further comprises:

receiving a processing doing request sent by the proxy service, where the doing request includes the successfully billed amount consumed by the operator service currently processing the business request;

Obtain the successfully billed amount from the doing request, update the current estimated billed amount in the estimated billed amount corresponding to the user ID to the obtained successfully billed amount, and determine the current estimated billed amount Whether the sum of the amount and the used amount corresponding to the user ID is greater than the available amount;

If not, then send a doing success response to the proxy service, so that the proxy service sends an end request to the flow control and charging module when it is determined that the operator service processing is completed;

If so, send a doing failure response to the proxy service, so that the proxy service terminates the operator service from processing the business request, and determines that the actual charging amount is what the operator service is currently processing the business request The successfully billed amount consumed, and an end request carrying the determined actual billed amount is sent.
According to the method according to claim 5, after said obtaining the successfully billed amount from said doing request, said method further comprises:

Judging whether the successfully billed amount is greater than the current expected billing amount;

If yes, then perform the step of updating the current estimated charge amount in the estimated charge amount corresponding to the user identifier to the obtained successfully charged amount;

If not, keep the estimated amount unchanged, and execute the step of judging whether the sum of the current estimated amount and the used amount corresponding to the user identifier is greater than the available amount.
The method according to claim 5 or 6, said method further comprising:

If the doing request or end request is not received for the preset duration, it is judged whether the successful billing amount carried in the doing request has been obtained;

If so, determine that the actual billing amount is the last successful billing amount obtained from the doing request;

If not, then determine that the actual billing amount is 0;

Adding the determined actual billing amount to the used amount corresponding to the user identifier, and deleting the current estimated billing amount from the estimated billing amount corresponding to the user identifier.
According to the method according to any one of claims 2-7, after deleting the current estimated charge amount from the estimated charge amount corresponding to the user identifier, the method further includes:

When the actual charging amount is greater than zero, a current charging bill is generated based on the actual charging amount.
A flow control billing method applied to proxy services, comprising:

receiving a service request sent by a terminal, where the service request includes a user identifier triggering the service request;

Determining the current estimated fee amount of the business request;

Sending a begin request carrying the user identifier and the estimated billing amount to the flow control and charging module, so that the flow control and billing module judges the current estimated billing amount and the already charged amount corresponding to the user identifier Whether the sum of the expected fee amount and the used amount is greater than the available amount is obtained to obtain a judgment result, and based on the judgment result, it is determined whether to respond to the service request, and based on the response result of the service request, the used amount corresponding to the user identifier is accumulated, and the The estimated billing amount corresponding to the user ID is the sum of the current estimated billing amounts of the service requests being processed corresponding to the user ID.
The method according to claim 9, after sending the begin request carrying the user identification and the estimated billing amount to the flow control billing module, the method further includes:

identifying whether the received response sent by the flow control and billing module to the begin request is a begin failure response or a begin success response;

If the begin failure response sent by the flow control and billing module is received, a request failure response is sent to the terminal;

Or, if the begin success response sent by the flow control and billing module is received, forward the service request to the operator service, so that the operator service processes the service request;

When it is determined that the operator service has completed the processing of the business request, an end request is sent to the flow control and charging module, so that the flow control and charging module processes the service request included in the end request The actual billing amount consumed is added to the used amount corresponding to the user identifier, and the current estimated billing amount is deleted from the estimated billing amount corresponding to the user identifier.
According to the method according to claim 10, after said forwarding said service request to said operator service, said method further comprises:

Acquiring in real time from the operator service the successfully billed amount currently consumed in processing the business request;

periodically sending a doing request carrying the successfully charged amount to the flow control and charging module, so that the flow control and charging module obtains the successfully charged amount from the doing request, and sends the user The current estimated billing amount in the corresponding estimated billing amount is updated to the obtained successfully billed amount, and it is judged whether the sum of the current estimated billing amount and the used amount corresponding to the user identification is greater than the available Quota, if no, then send a doing success response to the proxy service, if so, then send a doing failure response to the proxy service;

If the doing failure response sent by the flow control and charging module is received, the operator service is terminated to process the business request, and the actual billing amount is determined to be the amount consumed by the operator service currently processing the business request The successfully billed amount generates an end request based on the determined actual billed amount, and sends the generated end request to the flow control billing module.
A flow control billing device, applied to a flow control billing module, comprising:

The first receiving module is configured to receive a start request sent by the proxy service, the begin request is sent by the proxy service after receiving the service request sent by the terminal, and the begin request includes the user identifier and the user ID that triggered the service request The current estimated fee for processing the business request;

A judging module, configured to judge whether the sum of the expected billing amount, the estimated billing amount corresponding to the user identifier, and the used amount is greater than the available amount, and obtain a judgment result; the estimated billing amount corresponding to the user identifier is The sum of the current estimated charges for each service request being processed corresponding to the above user ID;

The accumulation module is configured to determine whether to respond to the service request based on the judgment result of the judgment module, and to accumulate the used amount corresponding to the user identifier based on the response result of the service request.
A flow control billing device, applied to proxy services, comprising:

The second receiving module is configured to receive a service request sent by a terminal, where the service request includes a user identifier triggering the service request;

The current estimated fee amount determination module is used to determine the current estimated fee amount of the service request;

The second sending module is configured to send a begin request carrying the user identifier and the expected charge amount to the flow control and charging module, so that the flow control and charge module can judge the current estimate charge amount, Whether the sum of the estimated charge amount and the used amount corresponding to the user identifier is greater than the available amount is obtained as a judgment result, and based on the judgment result, it is determined whether to respond to the service request, and the user identifier is accumulated based on the response result of the service request The corresponding used amount, the estimated billed amount corresponding to the user ID is the sum of the current estimated billed amount of each service request being processed corresponding to the user ID.
A flow control billing system, including a proxy service, a flow control billing module, and an operator service;

The flow control and billing module is configured to execute the method according to any one of claims 1-8;

The proxy service is used to execute the method according to any one of claims 9-11;

The operator service is used to process business requests.
An electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions are executed by the at least one processor, so that the at least one processor can perform any of claims 1-8 or 9-11 one of the methods described.
A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to make the computer execute the method according to any one of claims 1-8 or 9-11.
A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-8 or 9-11.