A timestamp-based quota pre-application method and device

Abstract

The disclosure provides a timestamp-based quota pre-application method and device, electronic equipment and storage medium, and relates to the technical field of capacity management. The method is applied to a client and includes: in response to an operation instruction triggered by a user account, determining whether a local quota meets quota requirements of the operation instruction; in the case where the local quota does not meet the quota requirements of the operation instruction, marking a current time node as a first timestamp; according to a size relationship between a time interval between the first timestamp and a second timestamp and a time interval threshold, determining whether to send a quota pre-application request to a server; in the case where the time interval between the first timestamp and the second timestamp is not greater than the time interval threshold, returning prompt information representing insufficient quota to the user account. The method of the disclosure reduces the use amount of system resources, effectively saves system resource overhead under the same business pressure, and improves system performance.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of capacity management, in particular to a timestamp-based quota pre-application method and device, electronic equipment and storage medium. BACKGROUND

[0002] Client-Server architecture is widely used in the interaction of distributed systems, and its main features are strong interaction, safe access mode, fast response, and easy to handle large amounts of data.

[0003] In the interaction scheme under the traditional Client-Server architecture, when the total quota of the system increases to the upper limit, the system returns an error message such as insufficient quota to the client. Once the client receives such an error message, it will repeatedly submit a quota pre-application request. In fact, this part of the message is invalid, and in an extreme scenario, it will increase the amount of messages between modules in the architecture, and increase unnecessary pressure on the system. SUMMARY

[0004] The embodiments of the present disclosure provide a timestamp-based quota pre-application method and device, electronic equipment and storage medium, aiming to solve the problems in the background art.

[0005] In order to solve the above technical problems, the present disclosure is implemented as follows:

[0006] In a first aspect, the embodiments of the present disclosure provide a timestamp-based quota pre-application method applied to a client, comprising:

[0007] In response to an operation instruction triggered by a user account, determining whether a local quota meets the quota requirement of the operation instruction;

[0008] In the case where the local quota does not meet the quota requirement of the operation instruction, marking a current time node as a first timestamp;

[0009] According to the size relationship between the time interval between the first timestamp and a second timestamp and the time interval threshold value, determining whether to send a quota pre-application request to a server; the second timestamp represents the time when the last pre-application failure response returned by the server is received;

[0010] In the case where the time interval between the first timestamp and the second timestamp is not greater than the time interval threshold value, returning prompt information representing insufficient quota to the user account.

[0011] Optionally, the method further comprises:

[0012] in a case that a time interval between the first timestamp and the second timestamp is greater than the time interval threshold, sending the quota pre-application request to the server.

[0013] Optionally, after the sending the quota pre-application request to the server, the method further comprises:

[0014] in a case that the server returns a pre-application success response, saving a pre-application quota corresponding to the pre-application success response into the local quota, and clearing the first timestamp;

[0015] in a case that the server returns the pre-application failure response, updating the second timestamp as the first timestamp.

[0016] Optionally, in a case that the server returns a pre-application success response, the method further comprises:

[0017] obtaining a preset return time carried in the pre-application success response returned by the server; the preset return time is: the server dynamically obtains a current quota balance, and determines according to a difference between the current quota balance and a balance threshold, the difference is proportional to the preset return time;

[0018] in a case that the pre-application quota is not used within the preset return time, returning the pre-application quota to the server.

[0019] Optionally, in a case that the server returns a pre-application success response, the method further comprises:

[0020] obtaining a logical clock carried in the pre-application success response returned by the server, the logical clock is used to represent a time node at which the server returns the pre-application success response to the client;

[0021] determining a target logical clock allowing the user account to use the pre-application quota based on the logical clock;

[0022] in the target logical clock, providing the pre-application quota to the user account.

[0023] Optionally, after the sending the quota pre-application request to the server, the method further comprises:

[0024] obtaining a pre-application quota corresponding to the pre-application success response returned by the server; the pre-application quota is: in a case that a current quota balance of the server does not meet a quota demand of the operation instruction, a quota recalled by the server sending a pre-application recall request to a plurality of historical application clients;

[0025] The pre-application recall request is: the server divides the plurality of historical application clients into a plurality of recall groups according to a preset batch, and sequentially sends to the plurality of recall groups according to the recall priority of each of the plurality of recall groups until the quota of the plurality of recall groups recalled meets the quota requirement of the operation instruction.

[0026] The recall priority of each of the plurality of recall groups is determined according to the following steps:

[0027] According to the activity and / or quota usage frequency of the plurality of historical application clients, the activity coefficient of each of the plurality of recall groups is determined;

[0028] According to the activity coefficient of each of the plurality of recall groups, the recall priority of each of the plurality of recall groups is determined; the activity coefficient is inversely proportional to the recall priority.

[0029] Optionally, after the target logical clock is determined to allow the user account to use the pre-applied quota, the method further comprises:

[0030] Obtaining a current logical clock;

[0031] If the difference between the current logical clock and the target logical clock is greater than a clock threshold, the pre-applied quota is returned.

[0032] In a second aspect, the embodiments of the present disclosure provide a timestamp-based quota pre-application device applied to a client, and the device comprises:

[0033] A first determination module is configured to determine whether a local quota meets a quota requirement of an operation instruction triggered by a user account in response to the operation instruction;

[0034] A marking module is configured to mark a current time node as a first timestamp if the local quota does not meet the quota requirement of the operation instruction;

[0035] A second determination module is configured to determine whether to send a quota pre-application request to a server according to a size relationship between a time interval between the first timestamp and a second timestamp and a time interval threshold; the second timestamp represents a time when a pre-application failure response returned by the server is last received;

[0036] A third determination module is configured to determine whether to send a quota pre-application request to a server according to a size relationship between a time interval between the first timestamp and a second timestamp and a time interval threshold; the second timestamp represents a time when a pre-application failure response returned by the server is last received.

[0037] Optionally, the apparatus further comprises:

[0038] A pre-application module configured to send the quota pre-application request to the server in a case where a time interval between the first timestamp and the second timestamp is greater than the time interval threshold.

[0039] Optionally, the apparatus further comprises:

[0040] A clearing module configured to save a pre-application quota corresponding to the pre-application success response into the local quota and clear the first timestamp in a case where the server returns the pre-application success response.

[0041] An updating module configured to update the second timestamp as the first timestamp in a case where the server returns the pre-application failure response.

[0042] Optionally, the apparatus further comprises:

[0043] A first obtaining module configured to obtain a preset return time carried in the pre-application success response returned by the server; the preset return time is determined according to a difference between a current quota residual amount and a residual amount threshold, the difference is proportional to the preset return time, and the server dynamically obtains the current quota residual amount.

[0044] A return module configured to return the pre-application quota to the server in a case where the pre-application quota is not used within the preset return time.

[0045] Optionally, the apparatus further comprises:

[0046] A second obtaining module configured to obtain a logical clock carried in the pre-application success response returned by the server, the logical clock is used to represent a time node at which the server returns the pre-application success response to the client.

[0047] A fourth determining module configured to determine a target logical clock allowing the user account to use the pre-application quota based on the logical clock.

[0048] A providing module configured to provide the pre-application quota to the user account within the target logical clock.

[0049] Optionally, the apparatus further comprises:

[0050] The third obtaining module is configured to obtain a pre-application quota corresponding to the pre-application success response returned by the server; the pre-application quota is a quota recalled by the server from a plurality of historical application clients in a case where a current quota allowance of the server does not meet a quota requirement of the operation instruction;

[0051] The pre-application recall request is that the server divides the plurality of historical application clients into a plurality of recall groups according to a preset batch, and sequentially sends to the plurality of recall groups according to recall priorities of the plurality of recall groups respectively, until the quota recalled from the plurality of recall groups meets the quota requirement of the operation instruction.

[0052] The third obtaining module further includes:

[0053] The first sub-module is configured to determine an activity coefficient of each of the plurality of recall groups according to an activity and / or a quota usage frequency of the plurality of historical application clients.

[0054] The second sub-module is configured to determine a recall priority of each of the plurality of recall groups according to the activity coefficient of each of the plurality of recall groups; the activity coefficient is inversely proportional to the recall priority.

[0055] Optionally, after the target logical clock at which the user account is determined to be allowed to use the pre-application quota, the apparatus further includes:

[0056] The fourth obtaining module is configured to obtain a current logical clock.

[0057] The returning module is configured to return the pre-application quota in a case where a difference between the current logical clock and the target logical clock is greater than a clock threshold.

[0058] In a third aspect, an electronic device is provided, which includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, and when the computer program is executed by the processor, the steps of the timestamp-based quota pre-application method are implemented.

[0059] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the timestamp-based quota pre-application method are implemented.

[0060] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:

[0061] The disclosure avoids unnecessary quota pre-application requests by determining whether the local quota meets the quota requirement of the operation instruction. Only in the case of insufficient local quota, the subsequent operation will be performed. The time interval between the first timestamp and the second timestamp is marked and compared with the time interval threshold to determine whether to send a quota pre-application request to the server. The frequent request to the server is avoided, reducing the network pressure between the client and the server. The timestamp-based quota pre-application method of the disclosure reduces invalid quota pre-application requests, reduces the competition and overhead of system resources, and reduces the use of system resources. Under the same business pressure, the system resource overhead is effectively saved, and the saved network resources can meet the processing resource demand of more normal businesses, improving the system performance. BRIEF DESCRIPTION OF DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiment description will be briefly introduced.

[0063] Figure 1 is a step schematic diagram of a timestamp-based quota pre-application method provided by an embodiment of the disclosure;

[0064] Figure 2 is a timing schematic diagram of a timestamp-based quota pre-application method provided by an embodiment of the disclosure;

[0065] Figure 3 is a schematic diagram of a pre-application recall step provided by an embodiment of the disclosure;

[0066] Figure 4 is a structure block diagram of a timestamp-based quota pre-application device provided by an embodiment of the disclosure;

[0067] Figure 5 is a structure block diagram of an electronic device provided by an embodiment of the disclosure. DETAILED DESCRIPTION

[0068] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0069] The timestamp-based quota pre-application method provided by the present disclosure is applied to a client in a Client-Server architecture, and the client is a client program or a client node in a distributed file system. The client refers to one end of a user or an application program for communicating and interacting with a server through a network. In the distributed file system, the client is responsible for sending a request to the server and receiving a response of the server, so as to realize operations such as reading, writing, creating, and deleting a file. The client is also responsible for managing a local file cache, quota information, and the like, and interacting with the server for quota pre-application. Figure 1 is a step schematic diagram of a timestamp-based quota pre-application method provided by one embodiment of the present disclosure, as shown in Figure 1 The method comprises the following steps.

[0070] In step S101, in response to an operation instruction triggered by a user account, it is determined whether a local quota meets a quota requirement of the operation instruction.

[0071] In step S102, in a case where the local quota does not meet the quota requirement of the operation instruction, a current time node is marked as a first timestamp.

[0072] In step S103, according to a size relationship between a time interval between the first timestamp and a second timestamp and a time interval threshold value, it is determined whether to send a quota pre-application request to a server; the second timestamp represents a time when a pre-application failure response returned by the server is last received.

[0073] In step S104, in a case where the time interval between the first timestamp and the second timestamp is not greater than the time interval threshold value, prompt information representing quota shortage is returned to the user account.

[0074] S101, the client determines whether the local quota satisfies the quota requirement of the operation instruction triggered by the user account. When the user initiates an operation instruction (such as writing a file, creating a directory, etc.) on the client, the client first checks the file offset, length and local quota of the operation instruction to determine whether the local quota satisfies the quota requirement of the operation instruction. For example, assume that the user account initiates a write file operation instruction on the client, and the data needs to be written to the file offset of 100 and the length of 50 bytes. The client first checks the remaining amount of the local quota, and assume that the remaining amount of the local quota is 80 bytes. Then, the client compares the file offset and length of the operation instruction with the local quota. If the file offset plus the length is less than or equal to the local quota, it means that the local quota is sufficient to satisfy the quota requirement of the operation instruction. In this case, the client can directly execute the operation instruction to write data to the file. If the file offset plus the length is greater than the local quota, i.e. 100 + 50 > 80, it means that the local quota is insufficient to satisfy the quota requirement of the operation instruction, and then the client needs to start step S102 to prepare to apply for the quota required by the operation instruction to the server.

[0075] S102, in the case that the local quota does not satisfy the quota requirement of the operation instruction, i.e. in the case that the client checks that the local quota is insufficient, the current time node when this situation occurs is marked as the first timestamp. The first timestamp is an important mark, which is used to indicate to the client whether to send a quota pre-application request to the server in subsequent logical processing.

[0076] S103, the second timestamp is the time point when the client last received the pre-application failure response returned by the server. In other words, it marks the time node when the client last tried to obtain additional quota but failed. When the client needs to decide whether to send a quota pre-application request to the server, it calculates the time interval between the current time (the first timestamp) and the last pre-application failure time (the second timestamp). Then, the client compares the time interval with a time interval threshold, which is preset, for example, set to 1 minute, and set according to the actual situation of the system.

[0077] S104, if the time interval is less than the threshold, it means that the time since the last pre-application failure is not long enough, and the client directly returns a prompt information to the user account to inform the user account that the quota is insufficient at this time and needs to be waited to avoid repeatedly sending unnecessary pre-application requests to the server in the case of insufficient quota capacity.

[0078] Each time a request is sent to the server, it consumes a certain amount of network bandwidth and resources. If the client sends requests too frequently, it can cause network congestion, increase communication delay, and affect the overall performance of the system. By setting a time interval threshold, the time interval between the first timestamp and the second timestamp is judged based on the time interval threshold each time a pre-application request needs to be sent, which can ensure that the client will not send requests repeatedly within a certain period of time, thereby reducing unnecessary network communication overhead. The quota pre-application method based on timestamps provided by the present disclosure optimizes the communication interaction process with the server, improves the performance and stability of the system, and reduces unnecessary resource waste and communication overhead.

[0079] Illustratively, the method further comprises: in the case that the time interval between the first timestamp and the second timestamp is greater than the time interval threshold, sending the quota pre-application request to the server.

[0080] If the time interval is greater than the time interval threshold, it means that enough time has passed since the last pre-application failure, and the client can consider it to be the right time to try pre-application again. Therefore, it can send a new quota pre-application request to the server. Ensuring that the client obtains the required quota at the right time improves the resource utilization of the system.

[0081] Illustratively, after the sending of the quota pre-application request to the server, the method further comprises: in the case that the server returns a pre-application success response, saving the pre-application quota corresponding to the pre-application success response to the local quota, and clearing the first timestamp; in the case that the server returns the pre-application failure response, updating the second timestamp to the first timestamp.

[0082] When the server returns a pre-application success response, it indicates that the client has successfully obtained additional quota from the server. At this time, the client saves the pre-application quota corresponding to the pre-application success response to the local quota, and the client can allocate the quota required by the operation instruction of the user account from the local quota. At the same time, the client clears the first timestamp, which is to prepare for the next marking. After clearing, the first timestamp will start counting again. Conversely, if the server returns a pre-application failure response, it indicates that the client has failed to obtain additional quota. In this case, the client will not update the local quota because there is no new quota to use. The client will update the second timestamp to the same value as the first timestamp, i.e. the client will reset the second timestamp, because this pre-application failure has become a historical event and needs to be recorded by the second timestamp in order to calculate the time interval with the new first timestamp again when preparing for the next pre-application.

[0083] The quota and timestamp management strategy described above helps to effectively manage the quota and optimize the communication process, establishes a regular quota pre-application mechanism between the client and the server, thereby improving the efficiency and performance of the system, and reducing unnecessary network communication and server load.

[0084] Figure 2 is a timing diagram of a timestamp-based quota pre-application method provided by one embodiment of the present disclosure, as shown in Figure 2 The user account communicates with the client through a specific protocol. If the user account currently needs to perform a write operation (write), the client checks whether the local quota is sufficient according to the quota required by the write instruction. If the local quota capacity is insufficient, the client determines whether to send a quota pre-application request to the server according to the size relationship between the time interval between the first timestamp and the second timestamp and the time interval threshold. If the time interval between the first timestamp and the second timestamp is not greater than the time interval threshold, the user account is returned a prompt information indicating that the quota is insufficient. If the time interval between the first timestamp and the second timestamp is greater than the time interval threshold, the client sends a quota pre-application request to the server, and the pre-application quota corresponding to the pre-application success response is saved to the local quota, i.e., recorded in the local pre-application cache. At this time, the client can allocate the quota required by the write instruction to the user account from the local quota.

[0085] Exemplarily, in the case where the server returns a pre-application success response, the method further includes: obtaining a preset return time carried in the pre-application success response returned by the server; the preset return time is: the server dynamically obtains a current quota balance, and determines according to a difference between the current quota balance and a balance threshold, the difference is proportional to the preset return time; in the case where the pre-application quota is not used within the preset return time, the pre-application quota is returned to the server.

[0086] The preset return time is dynamically determined by the server according to the current quota balance, and the purpose is to allow the client to use the pre-applied quota within a reasonable time. The server calculates the difference between the current quota balance and the preset balance threshold, and determines the preset return time according to the difference. If the current quota balance is close to the balance threshold, it may mean that the system resources are relatively abundant, so the preset return time may be relatively long; on the contrary, if the difference is small, it means that the system resources are tight, and the preset return time may be short, so as to recover the unused quota faster for other requests. After receiving the pre-application success response, the client needs to start using the part of the quota before the preset return time to complete the corresponding operation or transaction. If the client fails to use the pre-applied quota within the preset return time, the quota should be returned to the server. This mechanism ensures efficient use of resources and avoids long-term occupation of resources that are not actually used, so that they can be reallocated to other clients in need.

[0087] The client returns the quota according to the preset return time, which is a proactive return mechanism. This mechanism aims to achieve dynamic management and efficient use of quota resources, encourages clients to use pre-applied resources as soon as possible after obtaining them, and returns them in time if not used, so as to ensure that system resources can be quickly reallocated when needed. This not only improves the overall response capability and resource utilization efficiency of the system, but also avoids service bottlenecks or congestion caused by long-term occupation of resources, ensuring the stability and reliability of the system.

[0088] Exemplarily, in the case that the server returns a pre-application success response, the method further comprises: obtaining a logical clock carried in the pre-application success response returned by the server, the logical clock being used to represent a time node at which the server returns the pre-application success response to the client; determining a target logical clock allowing the user account to use the pre-application quota based on the logical clock; and providing the pre-application quota to the user account within the target logical clock.

[0089] The present disclosure utilizes logical clock to manage and control the quota pre-application mechanism. In a distributed system, logical clock is a widely used method to maintain the order consistency of events, rather than relying on the actual physical time, which helps to solve the problem caused by clock bias. Logical clock is an abstract concept of time, which is used to identify the order of events in a distributed system. In this scenario, when the server approves the quota pre-application request of the client, a pre-application success response is returned, which contains a logical clock. This logical clock represents the time node when the server returns the pre-application success response, but it does not necessarily correspond to the real physical time, but an abstract representation for maintaining the order of events within the system. Based on the returned logical clock, the system determines a target logical clock, i.e. the time range in which the client is allowed to use the pre-application quota. The target logical clock is set based on the logical clock at the time of pre-application success, which defines a time window within which the user account can use the pre-application quota. The system provides the pre-application quota to the user account within the target logical clock. This means that only when the current logical clock of the system is within the target logical clock, the user account is allowed to use the pre-application quota. For example, if the logical clock carried in the pre-application success response is 10, the target logical clock can be determined according to the preset clock interval, which is not limited by the present disclosure. Assuming that the preset clock interval is 1 clock, then the determined target logical clock is a clock interval between 10 and 11, and only within this clock interval can the user account use the pre-application quota.

[0090] By controlling the allocation and use of quota through the mechanism of logical clock, it is ensured that the use of quota is in accordance with the predetermined logical order, thereby avoiding the confusion of quota management that may be caused by time synchronization problems. The purpose of using logical clock for quota pre-application management is to ensure that the quota is used within the specified time, and to ensure that its allocation and use can be carried out in a consistent and orderly manner in a distributed system. By binding the conditions of quota allocation and use to the logical clock, the system can effectively control the timing of the use of quota.

[0091] Exemplarily, after the sending of the quota pre-application request to the server, the method further comprises: obtaining a pre-application quota corresponding to a pre-application success response returned by the server; the pre-application quota is a quota recalled by the server from a plurality of historical application clients in a case that a current quota balance of the server does not meet a quota requirement of the operation instruction; wherein the pre-application recall request is: the server divides the plurality of historical application clients into a plurality of recall groups according to a preset batch, and sequentially sends the plurality of recall groups according to recall priorities of the plurality of recall groups respectively, until the quota recalled from the plurality of recall groups meets the quota requirement of the operation instruction.

[0092] The present disclosure also relates to a process of handling quota application and allocation in a distributed system, in particular a pre-application quota recall mechanism in a case of resource shortage. When the current quota balance of the server is insufficient, the server will start a recall mechanism, which is a passive process of returning quota. This mechanism involves dividing historical application clients into different recall groups according to a preset batch. Historical application clients are clients that have successfully applied for the quota in the past. Historical application clients are saved as a list in the server and are updated in real time. The server can retrieve and locate the corresponding historical application clients according to the list. Each recall group will be processed according to a certain priority order. The server sends a pre-application recall request to each group in turn according to the priority order of the recall groups. Recall groups with higher priority will receive the recall request first, thereby having the opportunity to release quota first. The server will continue to send recall requests until the total amount of quota recovered from each recall group meets the current operation instruction requirement. For example, assuming that the quota required for the operation instruction of a user account is successfully applied to 100 clients, the server can set the preset batch to 10, divide the 100 clients into 10 recall groups, and send recall requests to them according to the priority of each batch. The main purpose of this mechanism is to effectively allocate limited resources in the case of quota shortage, to ensure that important operations can be processed first, to help optimize resource allocation, to improve the overall efficiency and response capability of the system, and to ensure that critical tasks can continue to run in the case of resource shortage. Figure 3 is a schematic diagram of a pre-application recall step provided by an embodiment of the present disclosure, as Figure 3As shown, the first client (client1) gets a pre-application failure response returned by the server when making a quota pre-application request to the server. The server traverses two historical application clients (client2 and client3) for the quota initiated by the first client. Assuming that the two historical application clients are independent recall groups, i.e. there is only one historical application client in each group, the server needs to send a pre-application recall request to the two recall groups. When the recall group replies to the request, the recall group will return the recalled quota to the server for use by the first client.

[0093] The recall priority of each of the plurality of recall groups is determined according to the following steps: determining an activity coefficient of each of the plurality of recall groups according to the activity and / or quota usage frequency of the plurality of historical application clients; determining the recall priority of each of the plurality of recall groups according to the activity coefficient of each of the plurality of recall groups; the activity coefficient is inversely proportional to the recall priority.

[0094] First, the system analyzes the activity and quota usage frequency of multiple historical application clients. The activity refers to the degree of activity of the client within a period of time, and the quota usage frequency refers to the frequency of the client using the quota. Based on these indicators, the system calculates the activity coefficient of each recall group. The activity coefficient can be understood as the degree of activity of the client using the quota. According to the activity coefficient of each recall group, the system determines the recall priority of each recall group. The higher the activity coefficient of the recall group, the lower the recall priority, because they are considered to be more active or more important clients, and may need to retain more quotas. Conversely, the recall group with lower activity has a higher recall priority, indicating that the recall group is not active in the use of quotas, and the recall group is required to return the quota to avoid unnecessary occupation of the quota. Consider a cloud computing platform scenario. On this platform, clients can apply for different types of quotas (such as computing resources, storage resources, etc.) to meet the operation instructions of user accounts. The usage patterns of each client can be different, some can be high-frequency but short-term use, and some can be long-term stable use. The activity coefficient can be defined in the following three dimensions among the clients of the recall group: the number of requests within a period of time, the number of times the client requests the quota within a given period of time. The more times, the more active the client is within this period of time; the average occupation time of the quota, the average time from the application to the release of the quota applied by the client. The longer the occupation time, the higher the degree of dependence of the client on the resource; the change frequency of the quota usage: the change frequency of the client's quota usage, frequent changes indicate that the usage pattern of the client is more dynamic, and the demand for the quota is also more unpredictable. Exemplarily, the activity coefficient can be defined as a weighted sum, which includes the measurement of the above dimensions, and each dimension is given different weights according to its importance to resource usage. Considering multiple recall groups divided from multiple historical application clients, suppose there are two recall groups: recall group A and recall group B, recall group A requests the quota 20 times on average every day in the past month, the average occupation time of the quota is 4 hours, and the quota usage changes greatly every day. While client B requests the quota 5 times on average every day in the same period, the average occupation time of the quota is 24 hours, but its quota usage is relatively stable. According to the defined activity coefficient calculation method, it is found that recall group A has a higher activity coefficient because it shows a higher request frequency and dynamic usage pattern. Therefore, when resources are scarce, recall group B will have a higher recall priority, and its quota will be recovered first, because from the perspective of activity, their resource usage efficiency is lower.

[0095] The above recall mechanism ensures that the quota can avoid the long-term idle of the quota resource in the hands of some low-activity users, and improves the overall use efficiency of the resource.

[0096] Exemplarily, after the determination of the target logical clock allowing the user account to use the pre-apply quota, the method further comprises: obtaining a current logical clock; and returning the pre-apply quota in a case where a difference between the current logical clock and the target logical clock is greater than a clock threshold.

[0097] After the client sends the quota pre-apply request to the server, the present disclosure further provides a policy for managing pre-apply resource quotas, and uses a logical clock to determine when to release or return resource quotas that are no longer needed, so as to improve resource utilization and system flexibility. It is assumed that a pre-apply quota is set with a logical clock range, which is valid between logical clock 10 and 11, and the clock threshold is 3. This means that if the difference between the current logical clock and the last moment of the validity period of the quota (logical clock 11) exceeds 3, the client will automatically return the resource quota to the server. For example, the difference between the current logical clock (14) and the last moment of the validity period of the quota (11) is 3, which is equal to the clock threshold. According to the policy, when the difference is equal to the clock threshold, the return operation is not triggered. Therefore, the quota of the user is still retained at the logical clock 14; for example, the difference between the current logical clock (15) and the last moment of the validity period of the quota (11) is 4, which exceeds the clock threshold 3. According to the policy, the resource quota needs to be returned in this case. The system automatically performs the return operation, so that the resource quota can be used by other users or tasks.

[0098] Through this management policy based on the logical clock and the clock threshold, the system can flexibly recycle and reallocate resources, thereby improving the utilization of resources. This policy is particularly suitable for cloud computing platforms and large distributed systems that need to efficiently manage a large number of dynamically changing resources. It helps to prevent resources from being idle for a long time, and ensures that system resources are used efficiently and fairly.

[0099] Figure 4 is a structural block diagram of a timestamp-based quota pre-apply device provided by an embodiment of the present disclosure, which is applied to a client, such as Figure 4 As shown in the figure, the device comprises:

[0100] A first determination module 201 is configured to determine whether a local quota meets quota requirements of an operation instruction triggered by a user account in response to the operation instruction.

[0101] A marking module 202 is configured to mark a current time node as a first timestamp in a case where the local quota does not meet the quota requirements of the operation instruction.

[0102] The second determining module 203 is configured to determine whether to send the quota pre-application request to the server according to a size relationship between a time interval between the first timestamp and the second timestamp and a time interval threshold, wherein the second timestamp represents a time when the last pre-application failure response returned by the server is received.

[0103] The third determining module 204 is configured to determine whether to send the quota pre-application request to the server according to a size relationship between a time interval between the first timestamp and the second timestamp and a time interval threshold, wherein the second timestamp represents a time when the last pre-application failure response returned by the server is received.

[0104] Exemplarily, the apparatus further comprises:

[0105] The pre-application module is configured to send the quota pre-application request to the server when the time interval between the first timestamp and the second timestamp is greater than the time interval threshold.

[0106] Optionally, the apparatus further comprises:

[0107] The clearing module is configured to save the pre-application quota corresponding to the pre-application success response into the local quota and clear the first timestamp when the server returns the pre-application success response.

[0108] The updating module is configured to update the second timestamp as the first timestamp when the server returns the pre-application failure response.

[0109] Exemplarily, the apparatus further comprises:

[0110] The first obtaining module is configured to obtain a preset return time carried in the pre-application success response returned by the server, wherein the preset return time is determined by the server according to a difference between a current quota balance and a balance threshold, and the difference is proportional to the preset return time.

[0111] The return module is configured to return the pre-application quota to the server when the pre-application quota is not used within the preset return time.

[0112] Exemplarily, the apparatus further comprises:

[0113] The second obtaining module is configured to obtain a logical clock carried in the pre-application success response returned by the server, wherein the logical clock is used to represent a time node when the server returns the pre-application success response to the client.

[0114] The fourth determining module is configured to determine, based on the logical clock, a target logical clock that allows the user account to use the pre-requested quota;

[0115] A module is configured to provide the pre-requested quota to the user account within the target logical clock.

[0116] Exemplarily, the device further includes:

[0117] The third acquisition module is configured to acquire the pre-application quota corresponding to the pre-application success response returned by the server; the pre-application quota is the quota recalled by the server when the current quota balance of the server does not meet the quota requirement of the operation instruction, by sending a pre-application recall request to multiple historical application clients.

[0118] The pre-application recall request is made by the server dividing the multiple historical application clients into multiple recall groups according to a preset batch, and sending the request sequentially to the multiple recall groups according to their respective recall priorities, until the quota recalled from the multiple recall groups meets the quota requirements of the operation instruction.

[0119] The third acquisition module further includes:

[0120] The first submodule is configured to determine the activity coefficient of each of the multiple recall groups based on the activity level and / or quota usage frequency of the multiple historical application clients;

[0121] The second submodule is configured to determine the recall priority of each of the plurality of recall groups based on the activity coefficient of each of the plurality of recall groups; the activity coefficient is inversely proportional to the recall priority.

[0122] For example, after determining the target logical clock that allows the user account to use the pre-requested quota, the device further includes:

[0123] The fourth acquisition module is configured to acquire the current logical clock;

[0124] The return module is configured to return the pre-requested quota if the difference between the current logical clock and the target logical clock is greater than a clock threshold.

[0125] This disclosure also provides an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in one embodiment of the present disclosure, such as... Figure 5 As shown, it includes a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304.

[0126] a memory 303, configured to store a computer program;

[0127] a processor 301, configured to execute the program stored in the memory 303, and implement the timestamp-based quota pre-application method in any one of the above embodiments.

[0128] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or only one type of bus.

[0129] The communication interface is configured to communicate between the terminal and other devices.

[0130] The memory can include a Random Access Memory (RAM) and can also include a non-volatile memory, such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the aforementioned processor.

[0131] The processor mentioned above can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0132] The embodiment of the present disclosure further provides a computer readable storage medium, and the computer readable storage medium stores a computer program. The computer program is executed by a processor to implement each process of the quota pre-application method of the timestamp and achieve the same technical effects. Each embodiment in the specification is described in a progressive manner, and each embodiment mainly describes differences from other embodiments. The same or similar parts of each embodiment are cross-referenced.

[0133] Those skilled in the art should understand that the embodiments of the present disclosure can be provided as a method, device, or computer program product. Therefore, the embodiments of the present disclosure can adopt a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present disclosure can adopt a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program codes.

[0134] The embodiments of the present disclosure are described with reference to flowcharts and / or block diagrams of the method, terminal device (system), and computer program product according to the embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the computer or other programmable data processing terminal device produce a device for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks Figure 1 The functions specified in one or more flows and / or blocks

[0135] While preferred embodiments of the present disclosure have been described, those skilled in the art will appreciate that other modifications and changes can be made thereto without departing from the scope of the present disclosure. It is therefore intended that the appended claims encompass all such modifications and changes as fall within the scope of the present disclosure.

[0136] Finally, it should be noted that, in the present document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily implying any actual relationship or order between such entities or actions. Also, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0137] The above provides a timestamp-based quota pre-application method and device, electronic equipment and storage medium provided by the present disclosure, and the principle and implementation manner of the present disclosure are described by applying specific examples. The above description of the embodiments is only used to help understand the method and core idea of the present disclosure. Meanwhile, for those skilled in the art, according to the idea of the present disclosure, the specific implementation manner and application range can be changed. In summary, the content of the present description should not be understood as a limitation of the present disclosure.

Claims

1. A timestamp-based quota pre-application method, characterized in that, Applied to a client, the method includes: In response to an operation command triggered by a user account, determine whether the local quota meets the quota requirements of the operation command; If the local quota does not meet the quota requirements of the operation instruction, mark the current time node as the first timestamp; Based on the relationship between the time interval between the first and second timestamps and a time interval threshold, it is determined whether to send a quota pre-request request to the server; the second timestamp represents the time when the server last returned a pre-request failure response; If the time interval between the first timestamp and the second timestamp is not greater than the time interval threshold, a prompt message indicating insufficient quota is returned to the user account. After sending the quota pre-request request to the server, the method further includes: Obtain the pre-application quota corresponding to the pre-application success response returned by the server; the pre-application quota is the quota recalled by the server when the current quota balance of the server does not meet the quota requirement of the operation instruction, by sending a pre-application recall request to multiple historical application clients. The pre-application recall request is made by the server dividing the multiple historical application clients into multiple recall groups according to a preset batch, and sending the request sequentially to the multiple recall groups according to their respective recall priorities, until the quota recalled from the multiple recall groups meets the quota requirements of the operation instruction. The recall priority of each of the multiple recall groups is determined according to the following steps: The activity coefficients of each of the multiple recall groups are determined based on the activity level and / or quota usage frequency of the multiple historical application clients. The recall priority of each of the multiple recall groups is determined based on their respective activity coefficients; the activity coefficients are inversely proportional to the recall priority.

2. The method according to claim 1, characterized in that, The method further includes: If the time interval between the first timestamp and the second timestamp is greater than the time interval threshold, the quota pre-request request is sent to the server.

3. The method according to claim 2, characterized in that, After sending the quota pre-request request to the server, the method further includes: If the server returns a pre-application success response, the pre-application quota corresponding to the pre-application success response is saved to the local quota, and the first timestamp is cleared to zero; If the server returns a pre-application failure response, the second timestamp will be updated to the first timestamp.

4. The method according to claim 3, characterized in that, If the server returns a pre-application success response, the method further includes: The preset return time is obtained from the pre-application success response returned by the server; the preset return time is determined by the server dynamically obtaining the current quota balance and based on the difference between the current quota balance and the balance threshold, and the difference is proportional to the preset return time. If the pre-requested quota is not used within the preset return period, the pre-requested quota will be returned to the server.

5. The method according to claim 3, characterized in that, If the server returns a pre-application success response, the method further includes: Obtain the logical clock carried in the pre-application success response returned by the server, the logical clock being used to characterize the time node at which the server returns the pre-application success response to the client; Based on the logical clock, determine the target logical clock that allows the user account to use the pre-requested quota; Within the target logical clock, the pre-requested quota is provided to the user account.

6. The method according to claim 5, characterized in that, After determining the target logical clock that allows the user account to use the pre-requested quota, the method further includes: Get the current logical clock; If the difference between the current logical clock and the target logical clock is greater than a clock threshold, the pre-requested quota shall be returned.

7. A timestamp-based quota pre-application device, characterized in that, Applied to a client, the device includes: The first determining module is configured to determine whether the local quota meets the quota requirements of the operation command in response to the operation command triggered by the user account. The marking module is configured to mark the current time node as a first timestamp when the local quota does not meet the quota requirements of the operation instruction; The second determining module is configured to determine whether to send a quota pre-request request to the server based on the relationship between the time interval between the first timestamp and the second timestamp and a time interval threshold; the second timestamp represents the time when the server last returned a pre-request failure response; The third determining module is configured to determine whether to send a quota pre-request request to the server based on the relationship between the time interval between the first and second timestamps and a time interval threshold; the second timestamp represents the time when the server last returned a pre-request failure response; The device further includes: The third acquisition module is configured to acquire the pre-application quota corresponding to the pre-application success response returned by the server; the pre-application quota is the quota recalled by the server when the current quota balance of the server does not meet the quota requirement of the operation instruction, by sending a pre-application recall request to multiple historical application clients. The pre-application recall request is made by the server dividing the multiple historical application clients into multiple recall groups according to a preset batch, and sending the request sequentially to the multiple recall groups according to their respective recall priorities, until the quota recalled from the multiple recall groups meets the quota requirements of the operation instruction. The third acquisition module further includes: The first submodule is configured to determine the activity coefficient of each of the multiple recall groups based on the activity level and / or quota usage frequency of the multiple historical application clients; The second submodule is configured to determine the recall priority of each of the plurality of recall groups based on the activity coefficient of each of the plurality of recall groups; the activity coefficient is inversely proportional to the recall priority.

8. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the method as described in any one of claims 1-6.

Images