Method for controlling concurrent user access and related apparatus

Abstract

The application relates to the field of data processing and discloses a user concurrent access control method and related device, which are used for improving the efficiency of user concurrent access. The method comprises the following steps: obtaining the access authority and priority of a plurality of target users, and performing token distribution on the plurality of target users according to the access authority and priority, so as to obtain the token quantity; obtaining at least one first token according to the token quantity corresponding to each target user, and caching the at least one first token to a preset token bucket, and setting the maximum capacity of the token bucket; when a target user accesses a shared resource, obtaining a target quantity of at least one second token from the token bucket; when the target user completes the access to the shared resource, releasing the at least one second token, and putting the at least one second token back into the token bucket; periodically checking the token quantity in the token bucket, and dynamically adjusting the token quantity and the acquisition rate of the token bucket according to the access state.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method and apparatus for controlling concurrent user access. Background Technology

[0002] In modern computer systems, multiple users often need to access shared resources simultaneously, such as databases and network services. To ensure system stability and security, these concurrent accesses must be effectively controlled. Common methods include using concurrency control mechanisms such as locks and semaphores, but these methods suffer from inefficiency and susceptibility to deadlocks. Summary of the Invention

[0003] This invention provides a method and related apparatus for controlling concurrent user access, which can improve the efficiency of concurrent user access.

[0004] The first aspect of the present invention provides a method for controlling concurrent user access, the method comprising:

[0005] Obtain access permissions and priorities for multiple target users, and allocate tokens to the multiple target users according to the access permissions and priorities to obtain the number of tokens corresponding to each target user;

[0006] Obtain at least one first token corresponding to the number of tokens for each target user, cache the at least one first token in a preset token bucket, and set the maximum capacity of the token bucket;

[0007] When the target user accesses the shared resource, at least one second token of the target number is obtained from the token bucket;

[0008] Once the target user has finished accessing the shared resource, the at least one second token is released and returned to the token bucket.

[0009] The number of tokens in the token bucket is checked periodically, and the number of tokens in the token bucket and the acquisition rate are dynamically adjusted according to the access status of the target user.

[0010] In conjunction with the first aspect, in a first embodiment of the first aspect of the present invention, the step of obtaining access permissions and priorities of multiple target users, and allocating tokens to the multiple target users according to the access permissions and priorities to obtain the number of tokens corresponding to each target user, includes:

[0011] Obtain access permissions and priorities for multiple target users, wherein the access permissions include low permissions and high permissions, and the priorities include high priority and low priority;

[0012] Tokens are allocated to the plurality of target users based on the access permissions and the priority.

[0013] When the target user has low permissions and high priority, allocate a first preset number of tokens.

[0014] When the target user has high privileges and low priority, allocate a second preset number of tokens.

[0015] In conjunction with the first aspect, in the second embodiment of the first aspect of the present invention, the step of obtaining at least one first token corresponding to the number of tokens for each target user, caching the at least one first token in a preset token bucket, and setting the maximum capacity of the token bucket includes:

[0016] Obtain at least one first token based on the number of tokens corresponding to each target user;

[0017] The at least one first token is cached in a preset token bucket, and the maximum concurrent access volume of the token bucket is obtained;

[0018] Set the maximum capacity of the token bucket based on the maximum concurrent access volume.

[0019] In conjunction with the first aspect, in a third embodiment of the first aspect of the present invention, the step of obtaining at least a target number of second tokens from the token bucket when the target user accesses the shared resource includes:

[0020] When the target user accesses the shared resources, the target user is allocated a number of tokens based on a preset token allocation strategy to obtain the target number;

[0021] Obtain the token acquisition frequency of the token bucket, and acquire at least one second token of the target number from the token bucket according to the token acquisition frequency.

[0022] In conjunction with the first aspect, in a fourth embodiment of the first aspect of the present invention, the step of releasing the at least one second token and returning the at least one second token to the token bucket after the target user completes access to the shared resource includes:

[0023] After the target user completes access to the shared resources, the at least one second token is matched with a retrieval strategy to obtain the target retrieval strategy.

[0024] Based on the target recycling strategy, the at least one second token is released;

[0025] Perform token lifecycle management on the at least one second token and put the at least one second token back into the token bucket.

[0026] In conjunction with the first aspect, in a fifth embodiment of the first aspect of the present invention, the step of periodically checking the number of tokens in the token bucket and dynamically adjusting the number of tokens in the token bucket and the acquisition rate according to the access status of the target user includes:

[0027] The number of tokens in the token bucket is checked periodically, and periodic check results are generated.

[0028] Collect monitoring metrics of the token bucket, and generate the access status of the target user based on the monitoring metrics;

[0029] The number of tokens in the token bucket and the acquisition rate are dynamically adjusted based on the access status.

[0030] A second aspect of the present invention provides a control device for concurrent user access, the control device comprising:

[0031] The acquisition module is used to acquire the access permissions and priorities of multiple target users, and to allocate tokens to the multiple target users according to the access permissions and priorities, so as to obtain the number of tokens corresponding to each target user;

[0032] The caching module is used to obtain at least one first token corresponding to each target user based on the number of tokens corresponding to each target user, cache the at least one first token in a preset token bucket, and set the maximum capacity of the token bucket;

[0033] The processing module is configured to obtain at least one target number of second tokens from the token bucket when the target user accesses the shared resource;

[0034] The release module is used to release the at least one second token and put the at least one second token back into the token bucket after the target user has finished accessing the shared resource;

[0035] The adjustment module is used to periodically check the number of tokens in the token bucket and dynamically adjust the number of tokens in the token bucket and the acquisition rate according to the access status of the target user.

[0036] A third aspect of the present invention provides a control device for concurrent user access, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the control device for concurrent user access to execute the aforementioned control method for concurrent user access.

[0037] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method for controlling concurrent user access.

[0038] The technical solution provided by this invention involves obtaining access permissions and priorities for multiple target users, allocating tokens to these users based on their access permissions and priorities to obtain a token quantity; acquiring at least one first token based on the token quantity corresponding to each target user, and caching this first token in a preset token bucket with a set maximum capacity; when a target user accesses a shared resource, acquiring at least one second token from the token bucket according to the target quantity; after the target user completes access to the shared resource, releasing the at least one second token and returning it to the token bucket; periodically checking the token quantity in the token bucket and dynamically adjusting the token quantity and acquisition rate based on the access status. This invention first allocates different quantities of tokens based on the access permissions and priorities of different users, then places these tokens into a token bucket, and limits the maximum number of tokens each user can acquire within a certain time. When a user needs to access a shared resource, they must acquire a sufficient number of tokens from the token bucket to access it. Because the number of tokens and the acquisition rate for each user are limited, it effectively avoids excessive resource consumption or a single user monopolizing resources for an extended period. It is simple to implement, highly efficient, and less prone to deadlocks. It supports dynamically adjusting the number of tokens and the acquisition rate to adapt to various user access needs. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of an embodiment of the user concurrent access control method in this invention;

[0040] Figure 2 This is a flowchart illustrating the setting of the maximum capacity of the token bucket in an embodiment of the present invention;

[0041] Figure 3 This is a flowchart illustrating the process of obtaining at least one second token of a target quantity in an embodiment of the present invention;

[0042] Figure 4 This is a flowchart illustrating the release of at least one second token in an embodiment of the present invention;

[0043] Figure 5 This is a schematic diagram of one embodiment of the control device for concurrent user access in this invention.

[0044] Figure 6This is a schematic diagram of one embodiment of the control device for concurrent user access in this invention. Detailed Implementation

[0045] This invention provides a method and related apparatus for controlling concurrent user access, aimed at improving the efficiency of concurrent user access. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0046] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the user concurrent access control method in this invention includes:

[0047] S101. Obtain the access permissions and priorities of multiple target users, and allocate tokens to multiple target users according to the access permissions and priorities to obtain the number of tokens corresponding to each target user;

[0048] It is understood that the executing entity of this invention can be a control device for concurrent user access, or it can be a terminal or a server; no specific limitation is made here. This embodiment of the invention will be described using a server as an example.

[0049] Specifically, the server allocates a different number of tokens to each user, based on their access permissions and priority. For each user in the system, the server determines the number of tokens they possess according to their access permissions and priority. Typically, users with higher access permissions and lower priority will be allocated fewer tokens, while users with lower access permissions and higher priority will be allocated more tokens. Specifically, in the concurrent access control method, this step involves how to allocate a different number of tokens to each user to ensure effective control of concurrent access during subsequent access processes, avoiding excessive resource consumption or situations where a single user monopolizes resources for an extended period.

[0050] S102. Obtain at least one first token corresponding to the number of tokens for each target user, cache at least one first token in a preset token bucket, and set the maximum capacity of the token bucket;

[0051] Specifically, the server places these tokens into a token bucket and sets the bucket's maximum capacity. In this step, all tokens assigned to users are placed into a token bucket, and the maximum capacity of the token bucket is set. The token bucket can be viewed as a token cache pool used to store all available tokens. The purpose of this step is to centrally manage all available tokens so that subsequent access processes can retrieve and release tokens from it.

[0052] S103. When the target user accesses the shared resource, obtain at least one second token of the target number from the token bucket;

[0053] Specifically, when a user needs to access a shared resource, a certain number of tokens are taken from the token bucket. If the number of tokens is insufficient, the user must wait for other users to release tokens. In this step, when a user needs to access a shared resource, it must acquire a certain number of tokens from the token bucket to do so. If the number of tokens is insufficient, the user must wait for other users to release tokens. Typically, each user can only acquire a certain number of tokens within a certain period to prevent one user from monopolizing too many tokens and preventing other users from accessing the shared resource. It should be noted that the purpose of this step—taking a certain number of tokens from the token bucket when a user needs to access a shared resource, and waiting for other users to release tokens—is to ensure that each user can obtain sufficient access permissions when accessing shared resources, while avoiding excessive resource consumption or a single user monopolizing resources for an extended period.

[0054] S104. After the target user completes access to the shared resource, at least one second token is released and at least one second token is put back into the token bucket.

[0055] Specifically, after a user completes access to a shared resource, they release the corresponding number of tokens and return them to the token bucket. In this step, when a user finishes accessing a shared resource, they need to release the corresponding number of tokens and return them to the token bucket so that other users can continue to access the shared resource. Specifically, when a user finishes accessing the shared resource, the used tokens are returned to the token bucket. The purpose of this step is to ensure that each user promptly releases their acquired access permissions after using the shared resource, so that other users can continue to access it.

[0056] S105. Periodically check the number of tokens in the token bucket and dynamically adjust the number of tokens in the token bucket and the acquisition rate according to the access status of the target user.

[0057] Specifically, the server periodically checks the number of tokens in the token bucket and dynamically adjusts the number of tokens and the acquisition rate based on user access patterns. In this step, the system needs to periodically check the number of tokens in the token bucket and dynamically adjust the number of tokens and the acquisition rate based on user access patterns. For example, if a user's access frequency is high and the duration is long, the system can increase the user's token count and acquisition rate to improve access efficiency. Conversely, if a user's access frequency is low or the duration is short, the system can decrease the user's token count and acquisition rate to conserve resources. Specifically, the server monitors the status of the token bucket to handle anomalies promptly. The purpose of this step is to ensure that the token bucket is always in a normal working state, avoiding system crashes or service unavailability due to excessive resource consumption or other issues.

[0058] In this embodiment of the invention, access permissions and priorities of multiple target users are obtained, and tokens are allocated to these users based on their access permissions and priorities to obtain a token quantity. At least one first token is obtained based on the token quantity corresponding to each target user, and this first token is cached in a preset token bucket with a set maximum capacity. When a target user accesses a shared resource, at least one second token of the target quantity is obtained from the token bucket. After the target user completes access to the shared resource, the at least one second token is released and returned to the token bucket. The token quantity in the token bucket is periodically checked, and the token quantity and acquisition rate are dynamically adjusted based on the access status. This invention first allocates different quantities of tokens based on the access permissions and priorities of different users, then places these tokens into a token bucket, and limits the maximum number of tokens each user can obtain within a certain time. When a user needs to access a shared resource, they must obtain a sufficient number of tokens from the token bucket to access it. Because the token quantity and acquisition rate for each user are limited, it effectively avoids excessive resource consumption or a single user monopolizing resources for an extended period. It is simple to implement, highly efficient, and less prone to deadlocks. It supports dynamically adjusting the number of tokens and the acquisition rate to adapt to various user access needs.

[0059] In one specific embodiment, the process of performing step S101 may specifically include the following steps:

[0060] (1) Obtain access permissions and priorities for multiple target users, where access permissions include: low permissions and high permissions, and priorities include: high priority and low priority;

[0061] (2) Assign tokens to multiple target users based on access permissions and priorities;

[0062] (3) When the target user has low permissions and high priority, allocate the first preset number of tokens;

[0063] (4) When the target user has high privileges and low priority, allocate the second preset number of tokens.

[0064] Specifically, before allocating tokens, the server needs to evaluate each user's access permissions and priorities. Access permissions typically refer to the range of resources a user can access, such as read and modify operations. Priority refers to the user's relative priority when multiple users access shared resources simultaneously. Generally, users with high access permissions and low priority will be allocated fewer tokens, while users with low access permissions and high priority will be allocated more tokens. A simple allocation method is to determine each user's initial token count based on their access permissions and priority, and then use a dynamic adjustment algorithm to continuously adjust each user's token count during subsequent accesses. In this method, users with high access permissions and low priority will be allocated fewer initial tokens, but as their access frequency increases, the system can gradually increase their token count to improve access efficiency. Conversely, users with low access permissions and high priority will be allocated more initial tokens, but if their access frequency begins to decrease, the system can gradually reduce their token count to save resources. In addition to allocation methods based on access permissions and priorities, other factors can be considered to determine each user's initial token count. For example, the number of times a user accesses resources over a past period, the duration of access, and bandwidth usage can all be considered to determine their token count. In this method, users who frequently access the system are allocated more tokens to improve their access efficiency, while users who access the system less frequently are allocated fewer tokens to conserve resources. This method requires statistical analysis of user access behavior and is more suitable for systems that need to run for extended periods. It is crucial to ensure that each user receives enough tokens to meet their access needs when allocating tokens. Otherwise, situations may arise where some users cannot access shared resources, affecting the normal operation of the system. Therefore, when allocating tokens, it is necessary to fully understand the users' access needs and allocate tokens reasonably based on the actual situation.

[0065] In one specific embodiment, such as Figure 2 As shown, the process of executing step S102 can specifically include the following steps:

[0066] S201. Obtain at least one first token corresponding to the number of tokens for each target user;

[0067] S202. Cache at least one first token into a preset token bucket and obtain the maximum concurrent access volume of the token bucket;

[0068] S203. Set the maximum capacity of the token bucket based on the maximum concurrent access volume.

[0069] Specifically, when implementing the token bucket algorithm, servers typically treat the token bucket as a queue, where each token represents a certain number of access rights. When a user needs to access a shared resource, they must acquire a certain number of tokens from the token bucket. If the number of tokens is insufficient, they must wait for other users to release tokens until they acquire a sufficient number. Several aspects need to be considered when designing the token bucket algorithm: The token bucket's capacity determines the upper limit of the number of tokens it can store. Generally, the token bucket's capacity should be able to meet the system's maximum concurrent access requirements and should be matched with the system's hardware configuration, network bandwidth, and other factors. If the token bucket's capacity is too small, the system will be unable to meet peak access demands; if the token bucket's capacity is too large, it will waste system resources. The token generation rate refers to how many new tokens the token bucket can generate per second. Generally, the token generation rate should match the system's processing capacity to ensure that the system can respond to user requests promptly. If the token generation rate is too slow, users will experience excessively long waiting times; if the token generation rate is too fast, it will waste system resources. The token consumption rate refers to how many tokens each user can consume per second. Ideally, the token consumption rate should match the system's processing capacity to ensure each user has sufficient access. If the token consumption rate is too slow, user access efficiency will be low; if the rate is too fast, resources will be over-consumed, affecting the normal operation of the system. The initial state of the token bucket includes parameters such as the number of tokens it contains and the generation rate. Before starting the system, the initial state of the token bucket needs to be set appropriately to meet the system's access demands. Typically, the initial state of the token bucket should have adequate buffering capacity to handle peak access during system startup. Overall, the token bucket algorithm is a highly effective concurrent access control method, widely used in many network services, financial transaction systems, and other fields. By properly setting the token bucket parameters, effective control over concurrent access from multiple users can be achieved, ensuring resource stability and security.

[0070] In one specific embodiment, such as Figure 3 As shown, the process of executing step S103 can specifically include the following steps:

[0071] S301. When a target user accesses a shared resource, the number of tokens is allocated to the target user based on a preset token allocation strategy to obtain the target number.

[0072] S302, Obtain the token acquisition frequency of the token bucket, and obtain at least one second token of the target number from the token bucket according to the token acquisition frequency.

[0073] Specifically, when implementing the above steps, the server needs to consider the following aspects: Token allocation strategy, which refers to how tokens are allocated from the token bucket to each user. Typically, the number of tokens a user should receive is determined based on factors such as access needs, priority, and historical access records. For example, for users who frequently access the system, the system can allocate more tokens to improve their access efficiency; for users with lower access permissions, the system can allocate fewer tokens to save resources. Token acquisition frequency, which refers to how many tokens each user can acquire per second. Typically, each user can only acquire a certain number of tokens within a certain period to prevent one user from monopolizing too many tokens and preventing other users from accessing shared resources. The system can dynamically adjust the acquisition frequency based on factors such as each user's access needs and historical access records to improve system resource utilization. Waiting queue management, where users need to enter a waiting queue when the number of tokens is insufficient. In the waiting queue, the waiting time and priority of each user need to be managed so that tokens can be allocated to higher-priority users in a timely manner when tokens become available. For example, first-in-first-out (FIFO) or priority-based waiting queue management algorithms can be used in the waiting queue to ensure that all users receive fair treatment. Timeout and retry mechanisms are necessary during the waiting process. If a user waits for too long or other abnormal situations occur, timeout and retry handling are required. For example, if a user's waiting time exceeds the preset maximum waiting time, the system can automatically remove them from the waiting queue and send a timeout notification. If a user experiences network failure or other abnormal situations while acquiring a token, the system can attempt to reacquire the token to improve the success rate of access. In summary, by properly configuring token allocation strategies, acquisition frequency, and managing waiting queues and timeout / retry mechanisms, the server can effectively control concurrent access and ensure system stability and security.

[0074] In one specific embodiment, such as Figure 4 As shown, the process of executing step S104 can specifically include the following steps:

[0075] S401. After the target user completes access to the shared resource, perform a retrieval policy matching on at least one second token to obtain the target retrieval policy.

[0076] S402. Based on the target recycling strategy, release at least one second token;

[0077] S403. Perform token lifecycle management on at least one second token and put at least one second token back into the token bucket.

[0078] Specifically, when implementing the above steps, the server needs to consider the following aspects: Token eviction strategy: This refers to how used tokens are returned to the token bucket. Typically, the number of tokens to eviction for each user can be determined based on factors such as the number of tokens used, access duration, and historical access records. For example, for users using fewer tokens and with shorter access times, the system can eviction all their tokens immediately; for users using more tokens and with longer access times, tokens can be evictioned in stages to avoid excessive resource consumption due to rapid eviction. Token release frequency: This refers to how many tokens each user can release per second. Typically, each user can only release a certain number of tokens within a certain period to prevent one user from excessively occupying token bucket resources, thus preventing other users from accessing shared resources. The system can dynamically adjust the release frequency based on each user's access needs and historical access records to improve system resource utilization. Token lifecycle management: This refers to how the generation, allocation, use, and eviction of tokens are managed to ensure that each token functions as expected. During token lifecycle management, attention must be paid to token state transitions, exception handling, and logging to ensure timely troubleshooting and repair of any issues. An exception handling mechanism is crucial because network failures, program crashes, and other anomalies may occur during token eviction. To prevent these anomalies from affecting system operation, appropriate exception handling mechanisms need to be designed. For example, in the event of a network failure, the system can cache unevictioned tokens and attempt to eviction again after network recovery; in the event of a program crash, the system can automatically restart the program and restore the token state based on the recorded runtime logs. In summary, by appropriately configuring token eviction policies, release frequencies, and implementing lifecycle management and exception handling mechanisms, the server can effectively manage the tokens in the token bucket, ensuring that each user's access permissions are promptly released after use, thereby guaranteeing system stability and security.

[0079] In one specific embodiment, the process of executing step S105 may specifically include the following steps:

[0080] (1) Periodically check the number of tokens in the token bucket and generate periodic check results;

[0081] (2) Collect the monitoring metrics of the token bucket and generate the access status of the target user based on the monitoring metrics;

[0082] (3) Adjust the number of tokens in the token bucket and the acquisition rate dynamically according to the access status.

[0083] Specifically, when implementing the above steps, the server needs to consider the following aspects: Monitoring metrics for the token bucket state. These metrics refer to specific indicators used to monitor various aspects of the token bucket's status. For example, they can monitor the current number of available tokens, token generation rate, token consumption rate, waiting queue length, response time, etc. By monitoring these metrics, problems in the token bucket can be identified in a timely manner, and corresponding measures can be taken to address them. Data collection and analysis. When monitoring the token bucket's status in real time, it is necessary to collect and analyze the data for each metric. Typically, data science techniques and artificial intelligence algorithms can be used for data analysis to uncover potential problems and anomalies. For example, machine learning algorithms can be used to predict future traffic and resource demands, thereby adjusting the token bucket's parameters and configuration based on the prediction results. Anomaly handling mechanisms. During the monitoring of the token bucket's status, some anomalies may occur, such as insufficient resources, network failures, and program crashes. To avoid these anomalies affecting the system, corresponding anomaly handling mechanisms need to be designed. For example, in the event of a network failure, the system can automatically switch to a backup server; when resources are insufficient, it can send alerts to users and reduce request frequency to conserve resources. Log recording and alarm mechanisms are crucial for monitoring the token bucket status. Changes in various metrics need to be recorded promptly, and the recorded data is used for troubleshooting and fault diagnosis. Simultaneously, appropriate alarm mechanisms need to be set up to promptly notify developers and system administrators in the event of serious problems. For example, multiple alarm methods such as email, SMS, and telephone can be configured to ensure timely receipt of alarm information anytime, anywhere. In summary, by properly configuring monitoring metrics, data analysis, anomaly handling mechanisms, and log recording and alarm mechanisms, the server can effectively monitor the token bucket status, ensuring the system can promptly detect and resolve problems, thereby improving system stability and security.

[0084] The control method for concurrent user access in the embodiments of the present invention has been described above. The control device for concurrent user access in the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 5 One embodiment of the user concurrent access control device in this invention includes:

[0085] The acquisition module 501 is used to acquire the access permissions and priorities of multiple target users, and to allocate tokens to the multiple target users according to the access permissions and priorities, so as to obtain the number of tokens corresponding to each target user;

[0086] The caching module 502 is used to obtain at least one first token corresponding to each target user based on the number of tokens corresponding to each target user, cache the at least one first token to a preset token bucket, and set the maximum capacity of the token bucket;

[0087] Processing module 503 is used to obtain at least one target number of second tokens from the token bucket when the target user accesses the shared resource;

[0088] Release module 504 is used to release the at least one second token and put the at least one second token back into the token bucket after the target user has finished accessing the shared resource;

[0089] The adjustment module 505 is used to periodically check the number of tokens in the token bucket and dynamically adjust the number of tokens and the acquisition rate of the token bucket according to the access status of the target user.

[0090] Through the collaborative operation of the aforementioned components, access permissions and priorities of multiple target users are acquired. Tokens are then allocated to these target users based on their access permissions and priorities, resulting in a token quantity. At least one first token is obtained based on the token quantity corresponding to each target user, and this first token is cached in a preset token bucket with a set maximum capacity. When a target user accesses a shared resource, at least one second token of the target quantity is obtained from the token bucket. After the target user completes access to the shared resource, at least one second token is released and returned to the token bucket. The token quantity in the token bucket is periodically checked, and the token quantity and acquisition rate are dynamically adjusted based on the access status. This invention first allocates different quantities of tokens based on the access permissions and priorities of different users, then places these tokens into a token bucket, and limits the maximum number of tokens each user can obtain within a certain time. When a user needs to access a shared resource, they must obtain a sufficient number of tokens from the token bucket to access it. Because the number of tokens and the acquisition rate for each user are limited, it effectively avoids excessive resource consumption or a single user monopolizing resources for an extended period. It is simple to implement, highly efficient, and less prone to deadlocks. It supports dynamically adjusting the number of tokens and the acquisition rate to adapt to various user access needs.

[0091] above Figure 5 The control device for concurrent user access in the embodiments of the present invention will be described in detail from the perspective of modular functional entities. The control device for concurrent user access in the embodiments of the present invention will be described in detail from the perspective of hardware processing.

[0092] Figure 6This is a schematic diagram of the structure of a user concurrent access control device 600 provided in an embodiment of the present invention. The user concurrent access control device 600 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 610 (e.g., one or more processors) and a memory 620, and one or more storage media 630 (e.g., one or more mass storage devices) storing application programs 633 or data 632. The memory 620 and storage media 630 can be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the user concurrent access control device 600. Furthermore, the processor 610 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the user concurrent access control device 600.

[0093] The control device 600 for concurrent user access may also include one or more power supplies 640, one or more wired or wireless network interfaces 650, one or more input / output interfaces 660, and / or one or more operating systems 631, such as Windows Server, MacOS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 6 The illustrated control device structure for concurrent user access does not constitute a limitation on the control device for concurrent user access. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0094] The present invention also provides a control device for concurrent user access, the control device for concurrent user access includes a memory and a processor, the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the steps of the control method for concurrent user access in the above embodiments.

[0095] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the user concurrent access control method.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0098] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for controlling concurrent user access, characterized in that, The method for controlling concurrent user access includes: The method involves acquiring access permissions and priorities for multiple target users, and allocating tokens to these users based on the access permissions and priorities to obtain a token quantity for each target user. Specifically, this includes: acquiring access permissions and priorities for multiple target users, where the access permissions include low and high permissions, and the priorities include high and low priorities; allocating tokens to the multiple target users based on the access permissions and priorities; allocating a first preset token quantity when a target user has low permissions and high priorities; and allocating a second preset token quantity when a target user has high permissions and low priorities. Obtain at least one first token corresponding to the number of tokens for each target user, cache the at least one first token in a preset token bucket, and set the maximum capacity of the token bucket; specifically, this includes: obtaining at least one first token corresponding to the number of tokens for each target user; caching the at least one first token in a preset token bucket and obtaining the maximum concurrent access volume of the token bucket; and setting the maximum capacity of the token bucket based on the maximum concurrent access volume. When the target user accesses the shared resource, at least one second token of the target quantity is obtained from the token bucket; specifically, this includes: when the target user accesses the shared resource, the token quantity is allocated to the target user based on a preset token allocation strategy to obtain the target quantity; the token acquisition frequency of the token bucket is obtained, and at least one second token of the target quantity is obtained from the token bucket according to the token acquisition frequency; After the target user completes access to the shared resource, the at least one second token is released and returned to the token bucket; specifically, this includes: after the target user completes access to the shared resource, performing a recycling strategy matching on the at least one second token to obtain a target recycling strategy; releasing the at least one second token based on the target recycling strategy; performing token lifecycle management on the at least one second token and returning the at least one second token to the token bucket; The token count in the token bucket is periodically checked, and the token count and acquisition rate in the token bucket are dynamically adjusted according to the access status of the target user. Specifically, this includes: periodically checking the token count in the token bucket and generating periodic check results; collecting monitoring metrics of the token bucket and generating the access status of the target user based on the monitoring metrics; and dynamically adjusting the token count and acquisition rate in the token bucket according to the access status.

2. A control device for concurrent user access, characterized in that, For executing the user concurrent access control method as described in claim 1, the user concurrent access control device includes: The acquisition module is used to acquire the access permissions and priorities of multiple target users, and to allocate tokens to the multiple target users according to the access permissions and priorities, so as to obtain the number of tokens corresponding to each target user; The caching module is used to obtain at least one first token corresponding to each target user based on the number of tokens corresponding to each target user, cache the at least one first token in a preset token bucket, and set the maximum capacity of the token bucket; The processing module is configured to obtain at least one target number of second tokens from the token bucket when the target user accesses the shared resource; The release module is used to release the at least one second token and put the at least one second token back into the token bucket after the target user has finished accessing the shared resource; The adjustment module is used to periodically check the number of tokens in the token bucket and dynamically adjust the number of tokens and the acquisition rate of the token bucket according to the access status of the target user.

3. A control device for concurrent user access, characterized in that, The control device for concurrent user access includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the user concurrent access control device to execute the user concurrent access control method as described in claim 1.

4. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements the user concurrent access control method as described in claim 1.

Images