Resource access method, device, electronic equipment and storage medium

文档序号:1941459 发布日期:2021-12-07 浏览:7次 中文

阅读说明:本技术 资源访问方法、装置、电子设备及存储介质 (Resource access method, device, electronic equipment and storage medium ) 是由 丰泽 王晓成 于 2020-09-01 设计创作,主要内容包括:本申请实施例提供一种资源访问方法、装置、电子设备及存储介质,包括:根据获取到的分布式锁,从令牌桶的数据中获取上一次令牌被提取的时间戳,令牌桶中包括链表,链表中存储了任意令牌被提取的时间戳,若根据上一次令牌被提取的时间戳确定出令牌桶存在可用令牌,则提取可用令牌,根据可用令牌对服务资源进行访问,通过采用链表对任意令牌被提取的时间戳进行存储,可以根据上一次令牌被提取的时间戳确定从令牌桶中提取可用令牌,避免相关技术中因无法准确确定令牌桶中是否存在可用令牌而导致的获取令牌失败,浪费资源等弊端,从而可以实现提取令牌的准确性和可靠性,进而可以实现提高对服务资源进行访问的效率和可靠性的技术效果。(An embodiment of the application provides a resource access method, a device, an electronic device and a storage medium, including: according to the obtained distributed lock, obtaining the timestamp of the last token extraction from the data of the token bucket, wherein the token bucket comprises a linked list, the linked list stores the timestamp of any token extraction, if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens, access to the service resource is made according to the available tokens, by storing the time stamp of any token extracted using a linked list, can determine to extract the available token from the token bucket according to the timestamp of the last token extraction, avoids the defects of failure in obtaining the token, resource waste and the like caused by the fact that whether the available token exists in the token bucket cannot be accurately determined in the related technology, thereby realizing the accuracy and reliability of extracting the token, and further, the technical effect of improving the efficiency and reliability of accessing the service resources can be realized.)

1. A method for resource access, the method comprising:

acquiring a timestamp of last token extraction from data of a token bucket according to a distributed lock acquired based on an access request for accessing service resources, wherein the token bucket comprises a linked list, and the linked list stores timestamps of any token extraction;

if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens;

and accessing the service resource according to the available token.

2. The method of claim 1, further comprising:

determining the length of the linked list;

and if it is determined that the token bucket has available tokens according to the timestamp from which the last token was extracted, extracting the available tokens includes: and if the length of the linked list is less than the preset current limiting times and if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens.

3. The method of claim 1, further comprising:

determining the length of the linked list;

if the length of the linked list is greater than or equal to the preset current limiting times, acquiring a timestamp stored in a header of the linked list;

and if it is determined that the token bucket has available tokens according to the timestamp from which the last token was extracted, extracting the available tokens includes: and if the difference value between the current time and the timestamp stored in the header is greater than the preset current limiting time, and if the token bucket has available tokens according to the timestamp extracted from the last token, extracting the available tokens.

4. The method according to any one of claims 1 to 3, further comprising:

and writing the timestamp of the current token extraction into the linked list as the current chain tail of the linked list.

5. The method of claim 4, further comprising:

determining an expiration time of the timestamp from which the current token was extracted;

and writing the timestamp from which the current token is extracted to the linked list comprises: and writing the timestamp of the current time token extraction and the expiration time of the timestamp of the current time token extraction into the linked list.

6. The method of claim 5, wherein determining an expiration time of the timestamp at which the current time token was extracted comprises:

determining whether the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time;

and if the timestamp of the current time token extraction is the timestamp written into the linked list for the first time, determining the first time as the expiration time of the timestamp of the current time token extraction.

7. The method of claim 6, wherein if the timestamp from which the current token is extracted is not the timestamp first written to the linked list, the method comprises:

acquiring the length from the head of the linked list to the tail of the current link;

and determining the expiration time of the timestamp extracted from the current token according to the length from the table head to the current chain tail.

8. The method of claim 7, wherein determining the expiration time of the timestamp from which the current token is extracted according to the length from the head of the table to the end of the current chain comprises:

and if the length from the head of the table to the tail of the current chain is less than or equal to the preset current limiting times, determining the second time as the expiration time of the timestamp for which the current token is extracted.

9. The method of claim 7, wherein determining the expiration time of the timestamp from which the current token is extracted according to the length from the head of the table to the end of the current chain comprises:

if the length from the gauge head to the current chain tail is greater than the preset current limiting times, acquiring a timestamp stored by the gauge head;

and if the difference between the current time and the timestamp stored in the header is greater than the preset current limiting time, determining the second time as the expiration time of the timestamp from which the current token is extracted.

10. The method of any one of claims 1 to 3, wherein extracting the available tokens if it is determined from the timestamp of the last token extraction that there are available tokens in the token bucket comprises:

and if the difference value between the current time and the timestamp of the last token extraction is greater than or equal to a preset time difference, determining and extracting the available token, wherein the time difference is determined according to the time of generating one token by the token bucket.

11. An apparatus for accessing a resource, the apparatus comprising:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring a timestamp of last token extraction from data of a token bucket according to a distributed lock acquired based on an access request for accessing service resources, the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction;

the extracting module is used for extracting the available token if the token bucket is determined to have the available token according to the timestamp of the last token extraction;

and the access module is used for accessing the service resource according to the available token.

12. The apparatus of claim 11, further comprising:

the first determining module is used for determining the length of the linked list;

and the extracting module is used for extracting the available token if the length of the linked list is less than the preset current limiting times and if the token bucket has the available token according to the timestamp of the last token extraction.

13. An electronic device, comprising: a memory, a processor;

a memory; a memory for storing the processor-executable instructions;

wherein the processor is configured to perform the method of any one of claims 1 to 10.

14. A computer-readable storage medium having computer-executable instructions stored thereon, which when executed by a processor, are configured to implement the method of any one of claims 1 to 10.

Technical Field

The embodiment of the application relates to the technical field of internet, in particular to a resource access method, a resource access device, electronic equipment and a storage medium.

Background

The gateway is an information exchange platform between networks, provides various interfaces to the outside, and provides services for users through various interfaces, such as services for service resource access, etc., but when providing service resources for users, the gateway may have network congestion, which may cause problems such as failure to normally provide service resource access for users.

In the prior art, a manner of setting a token bucket is mainly adopted to limit network access so as to avoid network congestion, for example, the token bucket may generate tokens at a certain rate, and a user may obtain service resources from the token bucket and provide the service resources based on a token receiving interface.

In the process of implementing the present application, the inventor finds that at least the following problems exist in the prior art: by the scheme in the prior art, whether the available tokens exist in the token bucket cannot be accurately determined, so that the reliability of the access of the user to the service resources is low.

Disclosure of Invention

The embodiment of the application provides a resource access method, a resource access device, an electronic device and a storage medium, which are used for solving the problem that the reliability of access of a user to a service resource is low.

In one aspect, an embodiment of the present application provides a resource access method, including:

acquiring a timestamp of last token extraction from data of a token bucket according to a distributed lock acquired based on an access request for accessing service resources, wherein the token bucket comprises a linked list, and the linked list stores timestamps of any token extraction;

if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens;

and accessing the service resource according to the available token.

In the embodiment of the application, since the token bucket includes the linked list, and the linked list stores the timestamp of any extracted token, the available token can be determined and extracted from the token bucket according to the timestamp of the last extracted token.

It is worth to be noted that the accuracy and convenience of determining the available token can be improved by extracting the timestamp, which is stored in the linked list and is extracted from the data of the token bucket, of the last token, and determining and extracting the available token based on the timestamp, so that the technical effect of improving the efficiency of subsequently accessing the service resource is improved.

That is to say, the embodiment of the present application stores the timestamp that any token was extracted by using the linked list, so that the server can conveniently and quickly obtain the timestamp that the last token was extracted from the data in the token bucket, and determine to extract the available token from the token bucket according to the timestamp that the last token was extracted, which can avoid the disadvantages of failure in obtaining the token and wasting resources of the server due to the fact that whether the available token exists in the token bucket cannot be accurately determined in the related art, thereby achieving the accuracy and reliability of extracting the token, and further achieving the technical effects of improving the efficiency and reliability of accessing the service resources by the server.

In some embodiments, the method further comprises:

determining the length of the linked list;

and if it is determined that the token bucket has available tokens according to the timestamp from which the last token was extracted, extracting the available tokens includes: and if the length of the linked list is less than the preset current limiting times and if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens.

In the embodiment of the application, before the available token is determined and extracted, the length of the linked list is compared with the current limiting times, if the length of the linked list is smaller than the current limiting times, it is indicated that the service resource can be continuously accessed in the current round of access process, the determination and the extraction of the available token can be executed, and the technical effect of improving the reliability and the accuracy of the extraction of the available token can be achieved by preferentially comparing the length of the linked list with the current limiting times.

In some embodiments, the method further comprises:

determining the length of the linked list;

if the length of the linked list is greater than or equal to the preset current limiting times, acquiring a timestamp stored in a header of the linked list;

and if it is determined that the token bucket has available tokens according to the timestamp from which the last token was extracted, extracting the available tokens includes: and if the difference value between the current time and the timestamp stored in the header is greater than the preset current limiting time, and if the token bucket has available tokens according to the timestamp extracted from the last token, extracting the available tokens.

In the embodiment of the application, if the length of the linked list is greater than or equal to the current limiting times, it is indicated that access to the service resources in the current round is possibly limited, that is, the access to the service resources in the current round has reached the upper limit in the current round, in order to further determine whether the access to the service resources in the current round is limited, the timestamp stored in the header can be acquired, if the difference between the current time and the timestamp stored in the header is greater than the current limiting time, it is indicated that access to the service resources in the next round is started, and then the available token is determined and extracted, so that the technical effects of high reliability and accuracy of the available token can be extracted.

In some embodiments, the method further comprises:

and writing the timestamp of the current token extraction into the linked list as the current chain tail of the linked list.

In the embodiment of the application, the timestamp extracted from the current token is written into the linked list, so that the technical effects of accuracy and reliability of subsequent determination and extraction of the available token can be improved.

In some embodiments, the method further comprises:

determining an expiration time of the timestamp from which the current token was extracted;

and writing the timestamp from which the current token is extracted to the linked list comprises: and writing the timestamp of the current time token extraction and the expiration time of the timestamp of the current time token extraction into the linked list.

In the embodiment of the application, the data in the linked list can be smoothly deleted by writing the timestamp extracted from the current token and the expiration time of the timestamp extracted from the current token into the linked list, and the storage space of the linked list is released.

In some embodiments, said determining an expiration time of the timestamp from which the current time token was extracted comprises:

determining whether the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time;

and if the timestamp of the current time token extraction is the timestamp written into the linked list for the first time, determining the first time as the expiration time of the timestamp of the current time token extraction.

In the embodiment of the application, if the timestamp of the current token extraction is the timestamp written into the linked list for the first time, it is indicated that the service resource access is started in the current round, so that the first time can be used as the expiration time of the timestamp of the current token extraction, and the first time can be the current limiting time, and therefore the technical effects of determining the reliability and the accuracy of the expiration time of the timestamp of the current token extraction are achieved.

In some embodiments, if the timestamp from which the current token is extracted is not the timestamp first written to the linked list, the method comprises:

acquiring the length from the head of the linked list to the tail of the current link;

and determining the expiration time of the timestamp extracted from the current token according to the length from the table head to the current chain tail.

In the embodiment of the present application, if the timestamp from which the current token is extracted is not the timestamp written into the linked list for the first time, the expiration time of the timestamp from which the current token is extracted may be determined in a different manner from the above example, so as to achieve the technical effect of flexibility and diversity of determining the expiration time of the timestamp from which the current token is extracted.

In some embodiments, said determining an expiration time of the timestamp from which the current secondary token is extracted according to the length of the head of the table to the end of the current chain comprises:

and if the length from the head of the table to the tail of the current chain is less than or equal to the preset current limiting times, determining the second time as the expiration time of the timestamp for which the current token is extracted.

In this embodiment of the application, if the length from the head of the table to the end of the current chain is less than or equal to the current flow limiting number of times, which indicates that the service resource access in the current round has been opened and has not yet ended, the second time may be determined as the expiration time of the timestamp from which the current token is extracted, and the second time may be half of the current flow limiting time, and of course, may also be other times greater than, less than or equal to the current flow limiting time, so as to improve the access efficiency to the service resource.

In some embodiments, said determining an expiration time of the timestamp from which the current secondary token is extracted according to the length of the head of the table to the end of the current chain comprises:

if the length from the gauge head to the current chain tail is greater than the preset current limiting times, acquiring a timestamp stored by the gauge head;

and if the difference between the current time and the timestamp stored in the header is greater than the preset current limiting time, determining the second time as the expiration time of the timestamp from which the current token is extracted.

In this embodiment of the present application, if the length from the head to the tail of the current chain is greater than the current limiting number of times, a difference between the current time and the timestamp stored in the head of the table may be calculated, and if the difference is greater than the current limiting time, it indicates that the next round of service resource access has been started, and the second time may be determined as the expiration time of the timestamp from which the current token is extracted, so as to improve the access efficiency of the service resource.

In some embodiments, if it is determined from the timestamp of the last token extraction that there are available tokens in the token bucket, extracting the available tokens includes:

and if the difference value between the current time and the timestamp of the last token extraction is greater than or equal to a preset time difference, determining and extracting the available token, wherein the time difference is determined according to the time of generating one token by the token bucket.

In the embodiment of the application, a difference value between the current time and the timestamp from which the token was extracted last time is calculated, and when the difference value is greater than or equal to the time difference, it indicates that the available token has been generated in the token bucket, and the available token can be extracted from the token bucket, so that the technical effects of accuracy and reliability of determining and extracting the available token are improved.

On the other hand, an embodiment of the present application further provides a resource access apparatus, where the apparatus includes:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring a timestamp of last token extraction from data of a token bucket according to a distributed lock acquired based on an access request for accessing service resources, the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction;

the extracting module is used for extracting the available token if the token bucket is determined to have the available token according to the timestamp of the last token extraction;

and the access module is used for accessing the service resource according to the available token.

In some embodiments, the apparatus further comprises:

the first determining module is used for determining the length of the linked list;

and the extracting module is used for extracting the available token if the length of the linked list is less than the preset current limiting times and if the token bucket has the available token according to the timestamp of the last token extraction.

In some embodiments, the apparatus further comprises:

the first determining module is used for determining the length of the linked list;

the acquisition module is used for acquiring a timestamp stored in a header of the linked list if the length of the linked list is greater than or equal to the preset current limiting times;

and the extracting module is used for extracting the available token if the difference value between the current time and the timestamp stored in the header is greater than the preset current limiting time and if the token bucket has the available token according to the timestamp extracted from the last token.

In some embodiments, the apparatus further comprises:

and the writing module is used for writing the timestamp extracted from the current token into the linked list and taking the timestamp as the current chain tail of the linked list.

In some embodiments, the apparatus further comprises:

a second determining module, configured to determine an expiration time of the timestamp from which the current token was extracted;

and the writing module is used for writing the timestamp from which the current token is extracted and the expiration time of the timestamp from which the current token is extracted into the linked list.

In some embodiments, the second determining module is configured to determine whether the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time, and if the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time, determine the first time as the expiration time of the timestamp from which the current token is extracted.

In some embodiments, if the extracted timestamp of the current token is not the timestamp written into the linked list for the first time, the second determining module is configured to obtain a length from a head of the linked list to the current tail of the linked list, and determine the expiration time of the extracted timestamp of the current token according to the length from the head of the linked list to the current tail of the linked list.

In some embodiments, the second determining module is configured to determine a second time as an expiration time of the timestamp from which the current token is extracted if the length from the head to the tail of the current chain is less than or equal to a preset current limit number.

In some embodiments, the second determining module is configured to, if the length from the head to the tail of the current chain is greater than a preset current limiting time, obtain a timestamp stored in the head, and if a difference between the current time and the timestamp stored in the head is greater than the preset current limiting time, determine the second time as an expiration time of the timestamp from which the current token is extracted.

In some embodiments, the extracting module is configured to determine and extract the available token if a difference between the current time and the timestamp of the last token extraction is greater than or equal to a preset time difference, where the time difference is determined according to a time when the token bucket generates one token.

On the other hand, an embodiment of the present application further provides an electronic device, including: a memory, a processor;

a memory; a memory for storing the processor-executable instructions;

wherein the processor is configured to perform the method of any of the embodiments above.

On the other hand, the embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-executable instructions are used to implement the method according to any one of the above embodiments.

An embodiment of the application provides a resource access method, a resource access device, an electronic device and a storage medium, which include: the method comprises the steps of obtaining a timestamp of last extracted token from data of a token bucket according to a distributed lock obtained based on an access request for accessing service resources, wherein the token bucket comprises a linked list, the linked list stores the timestamp of any extracted token, if the token bucket is determined to have the available token according to the timestamp of the last extracted token, the available token is extracted, accessing the service resources according to the available token, the linked list is adopted to store the timestamp of any extracted token, so that a server can conveniently and quickly obtain the timestamp of the last extracted token from the data of the token bucket, and determine to extract the available token from the token bucket according to the timestamp of the last extracted token, thereby avoiding failure in obtaining the token caused by the fact that whether the available token exists in the token bucket cannot be accurately determined by a server in the related technology, the method has the advantages that resources of the server are wasted, accuracy and reliability of token extraction can be achieved, and accordingly the technical effect of improving efficiency and reliability of server access to service resources can be achieved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1 is a schematic diagram of an application scenario of a resource access method according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating a resource access method according to an embodiment of the present application;

FIG. 3 is a schematic flowchart illustrating a resource access method according to another embodiment of the present application;

FIG. 4 is a schematic flow chart illustrating a resource access method according to another embodiment of the present application;

FIG. 5 is a flowchart illustrating a resource access method according to another embodiment of the present application;

FIG. 6 is a diagram of a resource access device according to an embodiment of the present application;

FIG. 7 is a diagram of a resource access device according to another embodiment of the present application;

fig. 8 is a schematic diagram of an electronic device according to an embodiment of the present application.

With the foregoing drawings in mind, certain embodiments of the disclosure have been shown and described in more detail below. These drawings and written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the concepts of the disclosure to those skilled in the art by reference to specific embodiments.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Referring to fig. 1, fig. 1 is a schematic view of an application scenario of a resource access method according to an embodiment of the present application.

As shown in fig. 1, an application scenario of the resource access method may include a gateway and a distributed cluster.

Among them, the Gateway (Gateway) may also be called an internetwork connector, or a protocol converter. The gateway is on the transport layer to implement network interconnection, and is a network interconnection device, for example, the gateway connects a plurality of servers (exemplarily shown in fig. 1 are 3 servers) in a distributed cluster as shown in fig. 1 to a network device (not shown in the figure).

The distributed cluster may comprise a plurality of servers as shown in fig. 1, of course, the distributed cluster may also comprise a plurality of terminal devices (not shown in the figure).

Among other things, the terminal equipment may be mobile terminals such as mobile phones (or so-called "cellular" phones) and computers with mobile terminals, e.g., portable, pocket, hand-held, computer-included, or vehicle-mounted mobile devices, that exchange language and/or data with a radio access network; the terminal device may also be a Personal Communication Service (PCS) phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a tablet computer, a Wireless modem (modem), a handheld device (handset), a laptop computer (laptop computer), a Machine Type Communication (MTC) terminal, or the like; the Terminal Device may also be referred to as a system, a Subscriber Unit (Subscriber Unit), a Subscriber Station (Subscriber Station), a Mobile Station (Mobile), a Remote Station (Remote Station), a Remote Terminal (Remote Terminal), an Access Terminal (Access Terminal), a User Terminal (User Terminal), a User Agent (User Agent), a User Device or User Equipment, etc., and is not limited herein.

It should be noted that the application scenario of the resource Access method according to the embodiment of the present application may be applicable to different network systems, such as three application scenarios, such as narrowband Band-Internet of Things (NB-IoT), Global System for Mobile Communications (GSM), Enhanced Data rate GSM Evolution (Enhanced Data rate for GSM Evolution), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (Code Division Multiple Access, CDMA2000), Time Division-synchronous Code Division Multiple Access (Time Division-Synchronization Code Division Multiple Access, TD-SCDMA), Long Term Evolution (Long Term Evolution, LTE), bluetooth System, WiFi System, and 5G Mobile communication System, such as umts, and the like.

It should be understood that the above examples are only used for exemplarily illustrating application scenarios of possible applications of the resource access method, and elements (such as a server and a gateway) that may be included in the application scenarios are not to be understood as limitations of the application scenarios of the resource access method, nor as limitations of the elements of the application scenarios of the resource access method.

For example, elements may be reduced accordingly in an application scenario, such as a portion of servers may be reduced, etc.

For another example, elements may be added in the application scene correspondingly, for example, a server may be added, and a network device may also be added.

And when the added element in the application scenario is a Network Device, the Network Device may be a Base Station, and the Base Station may be a Base Station (BTS) and/or a Base Station Controller in GSM or CDMA, a Base Station (NodeB, NB) and/or a Radio Network Controller (RNC) in WCDMA, an evolved Node B (eNB, or eNodeB) in LTE, or a relay Station or an access point, or a Base Station (gNB) in a 5G Network, a satellite, a Device-to-Device (D2D) communication, a Vehicle-to-X (V2X) communication, a Machine (Machine-to-Machine, M2M) communication, a Network Device that may assume functions of a Base Station in various future communications, and the like.

In the application scenario shown in fig. 1, each server may be connected to a gateway, and the gateway may provide various interfaces to the outside, that is, the gateway may provide various interfaces for each server and provide different services for each server through various interfaces, for example, the gateway provides access to service resources for each server through an interface (hereinafter referred to as interface a), that is, each server may access the service resources through interface a of the gateway.

Generally, the frequency of access of the interface a is limited, for example, the interface a can provide five thousand accesses in one second. When the number of access times of the interface a in one second is greater than five thousand times, a problem that the server cannot normally access to the interface a due to network congestion may occur, for example, when the number of access times of the interface a in one second is greater than five thousand times, access times exceeding five thousand times may be invalid access, and information such as access data initiated by the server may be lost.

For another example, the server may be a server supporting multiple threads, and the server may establish communication with each terminal device, receive an access request for a service resource initiated by each terminal device, and access the service resource to the interface a according to each thread.

In the related art, a generally adopted method is a token bucket throttling method, which generates tokens through a token bucket algorithm, and receives and accesses service resources provided by an interface a based on the generated tokens. For example, if a thread in the server acquires a token after acquiring the distributed lock, the thread may receive and access the service resource provided by interface a based on the acquired token.

However, with the token bucket throttling method in the related art, it may be that the server cannot accurately determine whether there is an available token in the token bucket, which results in low reliability of access to the service resource by each thread.

The inventor of the present application has obtained the inventive concept of the present application after creative efforts: the timestamp of each time a token is extracted is recorded by a linked list in the token bucket so that the server determines whether a token exists in the token bucket based on the timestamp.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

According to an aspect of the embodiments of the present application, the embodiments of the present application provide a resource access method, which may be applied to an application scenario as shown in fig. 1.

Referring to fig. 2, fig. 2 is a flowchart illustrating a resource access method according to an embodiment of the present application.

As shown in fig. 2, the method includes:

s101: and acquiring the timestamp of the last token extraction from the data of a token bucket according to the distributed lock acquired based on the access request for accessing the service resource, wherein the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction.

An execution subject of the resource access method in the embodiment of the present application may be a resource access device, and the resource access device may be a server as shown in fig. 1, and of course, the resource access device may also be a processor or a chip, etc. that can implement the resource access method in the embodiment of the present application, and the embodiment of the present application is not limited.

In the embodiments of the present application, an execution subject is exemplarily described as an example of a server.

Distributed locks are one way to control the synchronous access to shared resources among distributed clusters. Under the distributed model, the data has only one copy (or limitation), and the technology of the lock is needed to control the process number of modifying the data at a certain time.

In embodiments of the present application, distributed locks may be used to characterize a way to prevent interference with each other to ensure consistency when threads of respective corresponding access requests sent by multiple servers access one or a group of resources simultaneously. The thread is the smallest unit that the operating system can perform operation scheduling. A thread refers to a single sequential control flow in a process, where multiple threads can be executed in parallel, each thread executing a different task in parallel.

Among them, token bucket is a kind of flow control technology. In general, the token bucket works as follows: 1. tokens (Token) are put into the bucket at a certain rate; 2. each token allows the source to send a certain number of bits; 3. sending a packet, the traffic shaper deleting from the bucket the number of tokens equal to the packet size; 4. if there are not enough tokens to send a packet, the packet will wait until there are enough tokens or the packet is dropped; 5. the bucket has a certain capacity and if the bucket is full, newly added tokens are discarded.

That is, the token bucket may generate tokens at a constant rate, if the tokens are not consumed or the consumed rate is less than the generated rate, the tokens are continuously increased until the token bucket is full, the tokens generated later overflow from the token bucket, the maximum number of tokens retained in the token bucket never exceeds the size of the token bucket, the packet for obtaining the tokens is allowed to perform subsequent operations, and when the token consumption rate is greater than the token generation rate, the packet for not obtaining the tokens is discarded or enters the buffer queue.

The linked list can be used for representing a storage structure used for storing data, and has certain storage domains, each storage domain is used for storing data, and the stored data in the storage domains can be cleared.

For example, in this embodiment of the present application, the linked list may be used to store a timestamp from which any token is extracted, that is, a storage domain in the linked list may store the timestamp from which any token is extracted, and when the storage domain stores the timestamp from which the token is extracted, the server may clear each timestamp stored in each storage domain.

In this step, each server needs to acquire a distributed lock before accessing the service resource, so as to ensure that only one server can modify the relevant information of the shared resource (i.e. the service resource accessed by each server) at a certain time.

In the embodiment of the present application, a manner for a server to acquire a distributed lock is not limited, for example, the server may be implemented based on a Redis cache, a redrlk, a ZooKeeper, a Consul, or the like.

In this step, after the server acquires the distributed lock, since the token bucket includes the linked list and the linked list stores the timestamp of any extracted token, the server may acquire the timestamp of the last extracted token from the data of the token bucket.

S102: and if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens.

Wherein the available tokens may be used to characterize the token bucket that there are tokens that can be extracted by the server.

The step may specifically include: and judging whether available tokens exist in the token bucket according to the timestamp of the last time of token extraction, and if so, extracting the available tokens from the token bucket.

The embodiment of the present application does not limit how to determine whether there is an available token in the token bucket, for example, the time may be calculated by a timestamp from which the token was extracted last time, so as to determine whether there is an available token in the token bucket; or a preset time stamp comparison table, and determining whether there is an available token in the token bucket according to the time stamp comparison table and the time stamp of the last time the token is extracted, and the like.

Based on the above analysis, the token bucket may generate tokens based on a certain rate, and the server may obtain the tokens from the token bucket after obtaining the distributed lock, so as to access the service resource based on the tokens, and when the rate of generating the tokens by the token bucket is less than the rate of extracting the tokens by the server, there may be no tokens in the token bucket for the server to obtain.

In the embodiment of the application, the linked list is included in the token bucket, and the linked list stores the timestamp of any extracted token, so that the server can determine and extract the available token from the token bucket according to the timestamp of the last extracted token.

It is worth to be noted that the accuracy and convenience of determining the available token can be improved by extracting the timestamp, which is stored in the linked list and is extracted from the data of the token bucket, of the last token, and determining and extracting the available token based on the timestamp, so that the technical effect of improving the efficiency of accessing the service resources by the subsequent server is improved.

S103: access to the service resource is made according to the available token.

In this step, when the server obtains the available token, access to the service resource may be made based on the available token.

Based on the above analysis, an embodiment of the present application provides a resource access method, including: the method comprises the steps of obtaining a timestamp of last extracted token from data of a token bucket according to a distributed lock obtained based on an access request for accessing service resources, wherein the token bucket comprises a linked list, the linked list stores the timestamp of any extracted token, if the token bucket is determined to have the available token according to the timestamp of the last extracted token, the available token is extracted, accessing the service resources according to the available token, the linked list is adopted to store the timestamp of any extracted token, so that a server can conveniently and quickly obtain the timestamp of the last extracted token from the data of the token bucket, and determine to extract the available token from the token bucket according to the timestamp of the last extracted token, thereby avoiding failure in obtaining the token caused by the fact that whether the available token exists in the token bucket cannot be accurately determined by a server in the related technology, the method has the advantages that resources of the server are wasted, accuracy and reliability of token extraction can be achieved, and accordingly the technical effect of improving efficiency and reliability of server access to service resources can be achieved.

To make it clearer for the reader how the server determines whether there are available tokens in the token bucket, the resource access of the embodiments of the present application is now explained in more detail with reference to fig. 3. Fig. 3 is a schematic flowchart of a resource access method according to another embodiment of the present application.

As shown in fig. 3, the method includes:

s201: and acquiring the timestamp of the last token extraction from the data of a token bucket according to the distributed lock acquired based on the access request for accessing the service resource, wherein the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction.

For the description of S201, reference may be made to S101, which is not described herein again.

S202: and if the current time and the timestamp of the last token extraction are greater than or equal to the preset time difference, determining and extracting the available token.

Wherein the time difference can be set by the server based on demand, history, trials, etc.

Wherein, this step can include: and the server calculates the difference between the current time and the timestamp of the last token extraction, judges whether the calculated difference is greater than or equal to the time difference, and determines that available tokens exist in the token bucket if the calculated difference is greater than or equal to the time difference.

In some embodiments, the calculated difference may also be smaller than the time difference, and the server determines that the calculated difference is smaller than the time difference, and may determine that there is no token available in the token bucket, and the server may enter the sleep state, and the time that the server is in the sleep state (hereinafter referred to as the sleep time) may be set based on a preset number of current limits, for example, 1000 accesses of the service resource may be provided within 1 seconds, and the server may set the sleep time to 5-10 milliseconds.

In the embodiment of the application, the server determines whether the available tokens exist in the token bucket through a comparison mode between two times (namely the current time and the timestamp for extracting the last token), so that the high efficiency and convenience for determining the available tokens can be realized, and convenience is provided for the follow-up server to access the service resources.

S203: and accessing the service resource according to the available token.

For the description of S203, reference may be made to S103, which is not described herein again.

Referring to fig. 4, fig. 4 is a schematic flowchart illustrating a resource access method according to another embodiment of the present application.

As shown in fig. 4, the method includes:

s301: and acquiring the timestamp of the last token extraction from the data of a token bucket according to the distributed lock acquired based on the access request for accessing the service resource, wherein the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction.

For the description of S301, reference may be made to 101, which is not described herein again.

S302: and if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens.

For the description of S302, refer to S102 and also refer to S202, which are not described herein again.

S303: and writing the timestamp extracted from the current token into the linked list and taking the timestamp as the current chain tail of the linked list.

Similarly, the timestamp of the current time when the token is extracted is a relative concept, and can be used to characterize the timestamp of the time when the server extracts the token from the token bucket.

The current chain end is also a relative concept, and may be used to characterize a storage domain in the linked list, where the timestamp from which the token was extracted is newly stored.

That is to say, in the embodiment of the present application, when the server extracts a token from the token bucket, the time for extracting the token may be determined, and the determined time stamp for extracting the token is written into the storage domain in the linked list, and the storage domain in which the time stamp extracted from the current token is stored may be the current tail of the linked list.

S304: access to the service resource is made according to the available token.

For the description of S304, reference may be made to S103, which is not described herein again.

It should be noted that, in the embodiment of the present application, the execution sequence between each of S303 and S304 is not limited, that is, S303 may be preferentially executed and then S304 may be executed in the order set forth in the above example; or the step S304 can be executed preferentially, and then the step S303 is executed; s303 and S304 may also be performed simultaneously.

Referring to fig. 5, fig. 5 is a schematic flowchart illustrating a resource access method according to another embodiment of the present application.

As shown in fig. 5, the method includes:

s401: and acquiring the timestamp of the last token extraction from the data of a token bucket according to the distributed lock acquired based on the access request for accessing the service resource, wherein the token bucket comprises a linked list, and the linked list stores the timestamp of any token extraction.

For a description of S401, reference may be made to 101, which is not described herein again.

S402: and if the token bucket has available tokens according to the timestamp of the last token extraction, extracting the available tokens.

For the description of S402, refer to S102 and also refer to S202, which are not described herein again.

S403: the expiration time of the timestamp from which the current token was extracted is determined.

In some embodiments, S403 may include:

s4031: judging whether the timestamp extracted from the current token is the timestamp written into the linked list for the first time, if so (namely the timestamp extracted from the current token is the timestamp written into the linked list for the first time), executing S4032; if not, (i.e., the timestamp from which the current token is extracted is not the timestamp written into the linked list for the first time), S4033 is executed.

S4032: the first time is determined as the expiration time of the timestamp from which the current token was extracted.

In some embodiments, the current limit time may be determined as a first time, i.e. the current limit time may be determined as the expiry time of the timestamp from which the current token was extracted.

It should be noted that, if the timestamp extracted from the current token is the timestamp written into the linked list for the first time, it indicates that the access of the server based on the service resource of the current token is the first access, and indicates that the current limiting time starts to be timed, so the first time may be set as the current limiting time, and the first time is determined as the expiration time of the timestamp extracted from the current token.

S4033: and acquiring the length from the head of the linked list to the tail of the current linked list.

Where the header may be used to characterize the first memory field of the linked list.

The total length of the linked list may be used to represent the maximum current limiting times, and therefore, the length from the head to the current tail in the embodiment of the present application may be used to represent the current limiting times recorded from the head to the tail.

S4034: and determining the expiration time of the timestamp extracted by the current secondary token according to the length from the head of the table to the tail of the current chain.

In some embodiments, S4034 may include:

s40341: judging whether the length from the head of the meter to the current chain tail is less than or equal to the current limiting times, if so, executing S4342; if not (i.e. the length from the head to the tail of the current chain is greater than the current limit times), then S40343 is executed.

S40342: the second time is determined as the expiration time of the timestamp from which the current token was extracted.

The first time is the same as or different from the second time, and the first time and the second time have no necessary relationship.

In some embodiments, half of the current limit time may be determined as the expiration time of the timestamp from which the current token was extracted.

S40343: and acquiring the timestamp stored in the header.

Wherein, the timestamp stored in the header can be used for representing the timestamp of a certain token extracted from the header.

S40344: the difference between the current time and the time stamp stored in the header is calculated.

S40345: judging whether the difference value obtained by calculation in the S40344 is larger than the current limiting time, if so, executing the S40346; if not, the available token is not obtained, and the process is ended.

S40346: the second time is determined as the expiration time of the timestamp from which the current token was extracted.

S404: and writing the timestamp of the current time token extraction and the expiration time of the timestamp of the current time token extraction into the linked list.

That is to say, in the embodiment of the present application, after determining the expiration time of the timestamp extracted by the current-time token based on the above method, the server may identify the timestamp extracted by the current-time token, and the identification may be understood as a process of storing the expiration time and the timestamp extracted by the current-time token in the same storage domain, that is, the server stores the timestamp extracted by the current-time token and the timestamp corresponding to the timestamp extracted by the current-time token in the same storage domain of the linked list.

S405: access to the service resource is made according to the available token.

For the description of S405, reference may be made to S103, which is not described herein again.

According to another aspect of the embodiments of the present application, a resource access apparatus is further provided, configured to execute the resource access method according to any of the foregoing embodiments, for example, execute the resource access method shown in any of fig. 2, fig. 3, fig. 4, and fig. 5.

Referring to fig. 6, fig. 6 is a schematic diagram of a resource access device according to an embodiment of the present application.

As shown in fig. 6, the apparatus includes:

an obtaining module 11, configured to obtain, according to a distributed lock obtained based on an access request for accessing a service resource, a timestamp from which a token was extracted last time from data in a token bucket, where the token bucket includes a linked list, and the linked list stores timestamps from which any token was extracted;

an extracting module 12, configured to extract an available token from the token bucket if it is determined that the available token exists in the token bucket according to the timestamp from which the last token is extracted;

and an access module 13, configured to access the service resource according to the available token.

As can be seen in conjunction with fig. 7, in some embodiments, the apparatus further comprises:

a first determining module 14, configured to determine a length of the linked list;

and the extracting module 12 is configured to extract the available token if the length of the linked list is less than a preset current limiting time and if it is determined that the available token exists in the token bucket according to the timestamp from which the previous token is extracted.

As can be seen in conjunction with fig. 7, in some embodiments, the apparatus further comprises:

a first determining module 14, configured to determine a length of the linked list;

the obtaining module 11 is configured to obtain a timestamp stored in a header of the linked list if the length of the linked list is greater than or equal to a preset current limiting time;

and the extracting module 12 is configured to extract the available token if the difference between the current time and the timestamp stored in the header is greater than a preset current-limiting time, and if it is determined that the available token exists in the token bucket according to the timestamp from which the last token is extracted.

As can be seen in conjunction with fig. 7, in some embodiments, the apparatus further comprises:

and a writing module 15, configured to write the timestamp extracted from the current token into the linked list, where the timestamp is used as a current tail of the linked list.

As can be seen in conjunction with fig. 7, in some embodiments, the apparatus further comprises:

a second determining module 16, configured to determine an expiration time of the timestamp from which the current token is extracted;

the writing module 15 is configured to write the timestamp from which the current token is extracted and the expiration time of the timestamp from which the current token is extracted into the linked list.

In some embodiments, the second determining module 16 is configured to determine whether the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time, and if the timestamp from which the current token is extracted is the timestamp written into the linked list for the first time, determine the first time as the expiration time of the timestamp from which the current token is extracted.

In some embodiments, if the extracted timestamp of the current token is not the timestamp written into the linked list for the first time, the second determining module 16 is configured to obtain the length from the head to the tail of the linked list, and determine the expiration time of the extracted timestamp of the current token according to the length from the head to the tail of the current link.

In some embodiments, the second determining module 16 is configured to determine a second time as an expiration time of the timestamp from which the current token is extracted if the length from the head to the tail of the current chain is less than or equal to a preset current limit number.

In some embodiments, the second determining module 16 is configured to obtain a timestamp stored in the header if the length from the header to the current end of the chain is greater than a preset current limiting time, and determine the second time as an expiration time of the timestamp from which the current token is extracted if a difference between the current time and the timestamp stored in the header is greater than the preset current limiting time.

In some embodiments, the extracting module 12 is configured to determine that the available token exists if a difference between the current time and the timestamp of the last token extraction is greater than or equal to a preset time difference, where the time difference is determined according to the time when the token bucket generates one token.

On the other hand, the embodiment of the application also provides an electronic device and a computer readable storage medium.

Referring to fig. 8, fig. 8 is a schematic view of an electronic device according to an embodiment of the disclosure.

As shown in fig. 8, is a block diagram of an electronic device according to an embodiment of the application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of embodiments of the present application described and/or claimed herein.

As shown in fig. 8, the electronic apparatus includes: one or more processors 101, memory 102, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). Fig. 8 illustrates an example of one processor 101.

The memory 102 is a non-transitory computer readable storage medium provided by the embodiments of the present application. The memory stores instructions executable by at least one processor, so that the at least one processor executes the resource access method provided by the embodiment of the application. The non-transitory computer readable storage medium of the embodiments of the present application stores computer instructions for causing a computer to execute the resource access method provided by the embodiments of the present application.

Memory 102, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules in embodiments of the present application. The processor 101 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 102, that is, implements the resource access method in the above-described method embodiments.

The memory 102 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the electronic device, and the like. Further, the memory 102 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, memory 102 may optionally include memory located remotely from processor 101, which may be connected to an electronic device via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, Block-chain-Based Service Networks (BSNs), mobile communication networks, and combinations thereof.

The electronic device may further include: an input device 103 and an output device 104. The processor 101, the memory 102, the input device 103, and the output device 104 may be connected by a bus or other means, and fig. 8 illustrates the connection by a bus as an example.

The input device 103 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the electronic apparatus, such as a touch screen, keypad, mouse, track pad, touch pad, pointer stick, one or more mouse buttons, track ball, joystick, or other input device. The output devices 104 may include a display device, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here 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 a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Block-chain-Based Service Networks (BSNs), Wide Area Networks (WANs), and the internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

21页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:基于令牌桶的限流方法、装置、计算设备及介质

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!