Resource dynamic allocation method, system, equipment and product in high-concurrency scene

Abstract

The invention discloses a resource dynamic allocation method, system, device and product in a high-concurrency scene, and relates to the field of resource allocation. Firstly, a resource request initiated by a user is received, and whether the user has resource application qualification is judged; if the user has the resource application qualification, judging whether the resource request meets a resource allocation probability condition or not based on a dynamic probability interval matching algorithm; if the resource distribution probability condition is met, intercepting and checking the resource request through a five-layer risk control mechanism, otherwise, prompting a user that resource distribution fails; if the resource request passes the interception verification of a five-layer risk control mechanism, judging whether the current resource surplus meets the resource request based on a three-level inventory architecture of total inventory-time period inventory-Redis real-time inventory; and if yes, controlling a resource allocation concurrence process by adopting a dual distributed lock, issuing target resources to the user, updating the three-level inventory, and completing dynamic resource allocation, thereby effectively improving the resource allocation efficiency, stability and security.

Description

Technical Field

[0001] This application relates to the field of resource allocation technology, and in particular to a method, system, device and product for dynamic resource allocation in high-concurrency scenarios. Background Technology

[0002] With the widespread adoption of internet applications, the demands for high concurrency, large-scale data processing, data accuracy, and system stability are increasingly prominent. However, existing inventory resource allocation methods have revealed numerous problems during operation. For example, the basic interception function of existing methods generally relies on database queries for judgment, lacking real-time performance and multi-dimensional protection. They primarily use relational databases (such as MySQL), with some scenarios using Redis for simple caching, and lack a tiered storage strategy. MySQL (MyStructured Query Language) is an open-source, relational, SQL-based database management system. Redis refers to Remote Dictionary Server, an open-source, in-memory, key-value NoSQL database (also often called an in-memory data structure storage system). NoSQL is often referred to as "non-relational database" in Chinese. Furthermore, existing methods are inefficient in intercepting and cleaning data, have inappropriate storage methods, and insufficient request processing capabilities. Real-time processing latency exists for massive amounts of data in high-concurrency scenarios (such as user requests and inventory data), and concurrency control challenges exist for high-concurrency requests. Moreover, existing methods cannot efficiently identify and intercept malicious requests, resulting in a failure to guarantee system stability and data security. Summary of the Invention

[0003] The purpose of this application is to provide a method, system, device, and product for dynamic resource allocation in high-concurrency scenarios, so as to improve resource allocation efficiency, stability, and security.

[0004] To achieve the above objectives, this application provides the following solution.

[0005] Firstly, this application provides a method for dynamic resource allocation in high-concurrency scenarios, including: Receive resource requests initiated by users and determine whether users are eligible to apply for resources; If the user is eligible to apply for resources, the system uses a dynamic probability interval matching algorithm to determine whether the resource request meets the resource allocation probability conditions; if the user is not eligible to apply for resources, the system will prompt the user that they are not eligible to apply for resources. If the resource request meets the resource allocation probability conditions, the resource request is intercepted and verified through a five-layer risk control mechanism; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed. If the resource request passes the interception and verification of the five-layer risk control mechanism, the remaining amount of resources is determined based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory to determine whether the current remaining amount of resources can meet the resource request; if the resource request fails the interception and verification of the five-layer risk control mechanism, the user is prompted that the resource allocation has failed. If the current remaining resources meet the resource request, a dual distributed lock is used to control the concurrent resource allocation process, the target resource is issued to the user, and the three-level inventory is updated to complete the dynamic allocation of resources; if the current remaining resources do not meet the resource request, the user is prompted that the resource allocation has failed.

[0006] Optionally, the step of determining whether the resource request meets the resource allocation probability condition based on the dynamic probability interval matching algorithm specifically includes: Set a probability baseline value, convert the allocation probability of each resource into an integer, and calculate the probability interval corresponding to each resource; After receiving a resource request initiated by a user and determining that the user is qualified to apply for the resource, a random number is generated within the numerical range corresponding to the probability benchmark value. The random number is then matched with the probability range using a binary search method to determine whether the resource request matches the target resource. If a resource request matches the target resource, then the resource request is determined to meet the resource allocation probability condition. If a resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability conditions, and the user is prompted that the resource allocation has failed.

[0007] Optionally, the setting of the probability benchmark value, which converts the allocation probability of each resource into an integer and calculates the probability interval corresponding to each resource, specifically includes: Set probability baseline value Using formula Convert the allocation probabilities of each resource into integers; where Representing resources The probability of allocation; Represents the integer after the probability value has been converted; Using formula and Calculate each resource Corresponding probability interval ;in Representing resources The starting position within the probability interval; Representing resources The end position within the probability interval.

[0008] Optionally, the interception and verification of the resource request through a five-layer risk control mechanism specifically includes: First layer: Call the third-party risk control API to assess the user's risk level using the HTTPS protocol, store the assessment results in Redis and set the cache validity period to 5 minutes, and block resource requests if the user is a risk control user; The second layer stores blacklisted users through Redis's hash structure, using user ID as the key and user's malicious behavior characteristics as the value. If the current user is a blacklisted user, resource requests are blocked. The third layer: Records the number of times a user's resource is allocated through a hash structure in Redis. After each allocation, the count is updated using the INCR command in Redis. If the count exceeds the maximum number of times a single user can acquire the resource, the resource request is blocked. The fourth layer: Obtain the user's geographical location through IP resolution and match it with the resource delivery area whitelist. If the user's geographical location is not in the whitelist, the resource request will be blocked. The fifth layer uses the token bucket algorithm to control the time window, setting the bucket capacity and token generation rate. If the number of resource requests exceeds the token generation rate, the resource requests are blocked. The five-layer risk control mechanism operates independently for interception and verification. If any layer fails verification, the resource allocation process is immediately terminated.

[0009] Optionally, the method of determining whether the current remaining resource quantity satisfies the resource request based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory specifically includes: Total inventory control: By using row-level locks in the MySQL InnoDB engine, the total inventory limit is queried based on the resource ID to ensure that resource allocation in all time periods does not exceed the total inventory. Time-based inventory control: Configure the inventory quantity for each time period in the database table, and use a timer to automatically carry over unissued inventory from historical time periods to the current time period. Calculate the available inventory for the current time period = configured inventory quantity for the current time period + inventory balance from historical time periods. Redis Real-time Inventory Control: After each successful resource allocation, the real-time resource consumption quantity is updated through Redis atomic operations, and the current remaining resource quantity is calculated as: Current available inventory quantity - Real-time resource consumption quantity. Determine whether the current remaining amount of resources is greater than or equal to 1 unit; if yes, determine that the current remaining amount of resources satisfies the resource request; if no, determine that the current remaining amount of resources does not satisfy the resource request.

[0010] Optionally, the method of using dual distributed locks to control the concurrent process of resource allocation specifically includes: The dual distributed lock is implemented based on Redis. It creates an outer user resource allocation task lock and an inner resource inventory lock using the SETNX command and sets the lock's expiration time. The outer user resource allocation task lock is used to control concurrent resource requests from a single user, while the inner resource inventory lock is used to control concurrent allocation of the same resource by multiple users.

[0011] Optionally, the resources include cloud server resources, device resources, and data resources; the high-concurrency scenarios include e-commerce resource scheduling scenarios, cloud service resource distribution scenarios, device resource management scenarios, and public service resource configuration scenarios.

[0012] Secondly, this application provides a dynamic resource allocation system for high-concurrency scenarios, including: The resource application eligibility assessment module is used to receive resource requests initiated by users and determine whether the users are eligible to apply for resources. The resource allocation probability condition judgment module is used to determine whether the resource request meets the resource allocation probability condition based on a dynamic probability interval matching algorithm if the user is eligible to apply for resources; if the user is not eligible to apply for resources, the module will prompt the user that they are not eligible to apply for resources. The multi-dimensional risk control and protection module is used to intercept and verify the resource request through a five-layer risk control mechanism if the resource request meets the resource allocation probability conditions; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed. The three-level inventory management module is used to determine whether the current remaining amount of resources meets the resource request if the resource request passes the interception and verification of the five-layer risk control mechanism, based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory; if the resource request fails the interception and verification of the five-layer risk control mechanism, the user is prompted that the resource allocation has failed. The dual distributed lock concurrency control module is used to control the concurrent resource allocation process using dual distributed locks if the current remaining resource quantity meets the resource request, to issue the target resource to the user, and update the three-level inventory to complete the dynamic allocation of resources; if the current remaining resource quantity does not meet the resource request, the user is prompted that the resource allocation has failed.

[0013] Thirdly, this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the resource dynamic allocation method under the high concurrency scenario.

[0014] Optionally, the memory is a non-transitory computer-readable storage medium.

[0015] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method for dynamic resource allocation in high-concurrency scenarios.

[0016] Based on the specific embodiments provided in this application, the following technical effects are disclosed.

[0017] This application provides a method, system, device, and product for dynamic resource allocation in high-concurrency scenarios. Through an innovative dynamic probability interval matching algorithm, a five-layer risk control mechanism, a three-level inventory architecture of "total inventory - time period inventory - Redis real-time inventory", and a dual distributed lock mechanism, it solves the problems of traditional inventory resource management such as extensiveness, low concurrency performance, and difficulty in expansion. It achieves effective improvement in inventory utilization, enhanced concurrency processing capabilities, and strict risk control. It not only improves the stability and reliability of the resource allocation process, but also ensures the security and fairness of the resource allocation process, realizes refined management of resource allocation, and improves resource allocation efficiency. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a method for dynamic resource allocation in high-concurrency scenarios according to this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] This application proposes a method, system, device, and product for dynamic resource allocation in high-concurrency scenarios. It aims to overcome performance bottlenecks in high-concurrency scenarios, solve data consistency problems, and prevent over-issuance of inventory and waste of resources by combining and implementing new technologies such as probabilistic calculation technology for resource allocation, multi-dimensional risk control protection mechanism, time-segmented inventory management, and dual distributed lock concurrency control. This not only improves the stability and reliability of the resource allocation process, but also ensures the security and fairness of the resource allocation process, realizes refined management and control of resource allocation, and improves resource allocation efficiency.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] In one exemplary embodiment, such as Figure 1 As shown, a method for dynamic resource allocation in high-concurrency scenarios is provided, including the following steps 1 to 5.

[0024] Step 1: Receive resource requests initiated by users and determine whether users are eligible to apply for resources.

[0025] This application aims to provide a high-performance, highly available full-stack solution for high-concurrency resource allocation scenarios (such as e-commerce resource scheduling, cloud service resource distribution, device resource management, and public service resource configuration). Therefore, the high-concurrency scenarios addressed in this application typically refer to e-commerce resource scheduling, cloud service resource distribution, device resource management, and public service resource configuration scenarios. The resources requested by users can cover cloud server resources, device resources, data resources, etc.

[0026] Upon receiving a resource request from a user, the first step is to determine whether the user is eligible to apply for the resource. "User is eligible to apply for the resource" typically means that the user belongs to a legitimate target group and that the application matches the basic configuration of the resource (resource pool, resource type, attribute restrictions).

[0027] Step 2: If the user is eligible to apply for resources, determine whether the resource request meets the resource allocation probability conditions based on the dynamic probability interval matching algorithm; if the user is not eligible to apply for resources, prompt the user that they are not eligible to apply for resources.

[0028] If it is determined that the user is eligible to apply for resources, the next step is to determine whether the resource allocation meets the probability conditions. The determination of whether the resource request meets the resource allocation probability conditions based on the dynamic probability interval matching algorithm specifically includes the following steps 2.1 to 2.4.

[0029] Step 2.1: Set a probability baseline value, convert the allocation probability of each resource into an integer, and calculate the probability interval corresponding to each resource.

[0030] Set probability baseline value The allocation probabilities of each resource are converted to integers using the following formula: (1); in, Representing resources The probability of allocation is usually expressed as a percentage; This represents the integer value after the probability value has been converted. For example, setting the probability baseline value PROBABILITY_BASE=100000 (supports 0.001% precision). This refers to the probability of resource allocation. The integer obtained by multiplying the percentage by the base value PROBABILITY_BASE (100000) is, for example, 5% is converted to 5000.

[0031] Based on this, the probability intervals (also known as allocation intervals) corresponding to each resource are calculated using formulas (2) and (3): (2); (3); in, Representing resources The starting position in the probability interval is an integer, with a value range of 1 to PROBABILITY_BASE; Representing resources The end position within the probability interval is also an integer, with a range of values. In other words, resources The corresponding probability interval is .

[0032] Suppose we now have three types of resources (resource 1, resource 2, resource 3) and no allocated resources, which correspond to... Each resource covers the allocation interval 1 to PROBABILITY_BASE according to the allocation probability. In this example, it is [1, 100000]. The dynamic probability interval matching process is shown in Table 1.

[0033] Table 1 Dynamic Probability Interval Matching

[0034] Step 2.2: After receiving a resource request initiated by a user and determining that the user is qualified to apply for the resource, a random number is generated within the numerical range corresponding to the probability benchmark value. The random number is then matched with the probability range using a binary search method to determine whether the resource request matches the target resource.

[0035] The dynamic probability interval matching algorithm of this application first sets the probability baseline value PROBABILITY_BASE=100000 (supporting 0.001% precision), converts the resource allocation probability (e.g., 1%) into an integer (e.g., 1000), and then calculates the probability interval of resource allocation through integer addition and subtraction, using an array to store the interval boundaries. During the query, a random number is obtained from the range 1-100000. A binary search method is then used to match this random number, reducing the time for a single match from O(n) to O(log n). The allocation interval to which the random number belongs is then determined, and the allocated resources are locked. Here, O(n) and O(log n) are "Big O notation" used in computer science to describe the time complexity of algorithms. O(n) indicates that the algorithm's running time increases linearly with the input size n. O(log n) indicates that the running time increases logarithmically with the input size n, and the growth is very slow.

[0036] Specifically, resource allocation probabilities are stored in real-time using Redis's Hash structure (key=resource:prob: resource pool ID, field = resource type ID). Redis is an open-source, in-memory data structure storage system that can be used as a database, cache, and message broker. The core logic of the Redis Hash structure is that it is a three-layer storage model of "top-level key - second-level field - bottom-level value," enabling "aggregated storage of the same type of data and precise operation on individual data." "key=resource:prob: resource pool ID" is used to locate the set of all resource probabilities for "a specific resource pool," where "key" is the top-level unique identifier in Redis, used to distinguish data from different scenarios and dimensions. In the scenario of "storing resource allocation probabilities," the core design of this key is to "precisely lock the probabilities of all resource types under a specific resource pool." The prefix "resource:prob:" is a business semantic naming convention defined by the developer, directly clarifying the core function of this Redis key—storing the allocation probability (prob, short for probability) of a resource. This naming convention allows for quick differentiation from other data types (e.g., "user allocation count" prefixed with "user:count:", "blacklist" prefixed with "user:blacklist:"), avoiding confusion between different business data. It also facilitates quick identification of data usage by development and operations personnel, reducing maintenance costs. The suffix "Resource Pool ID" is used to locate a specific resource pool. "Resource Pool ID" is a dynamic variable corresponding to the "smallest unit of resource aggregation management"—a resource pool is a collection of similar or related resources (e.g., "e-commerce 618 coupon resource pool", "enterprise cloud service basic resource pool", "device scheduling resource pool", etc.). Each resource pool has a unique ID (e.g., "pool_202406", "cloud_base_01"). Its function is to bind "resource allocation probability" to a "specific resource pool": resource probabilities in different resource pools need to be stored independently (e.g., the probability of "full discount coupon" in the "coupon resource pool" is unrelated to the probability of "cloud server" in the "cloud resource pool"). Using "Resource Pool ID" as a suffix ensures the uniqueness of the key, accurately locating "the probability data set of all resource types under a specific resource pool". "field = resource type ID" is used to locate the probability of "a specific resource type under a certain resource pool". "field" is a second-level unique identifier belonging to the top-level key in the Redis Hash structure, used to accurately locate the allocation probability of a specific resource type in "the probability set (corresponding to the top-level key) of the same resource pool".The "Resource Type ID" is the smallest unit identifier for resource classification, corresponding to the "resource_type" field in the subsequent total inventory table (bd_resource_info). Resource types are subcategories within a resource pool (e.g., under the "cloud_base_01 resource pool," resource types can be divided into "cloud server (type_001)," "cloud storage (type_002)," and "load balancer (type_003)"). Each resource type has a unique ID. Using the "Resource Type ID" as a field ensures that within the same resource pool (corresponding to the top-level key), the probability of each resource type has an independent storage location and does not interfere with each other (e.g., "type_001" corresponds to the probability of cloud server, and "type_002" corresponds to the probability of cloud storage).

[0037] If resources change, the resource allocation probability in the database is adjusted, and a background thread synchronizes it to the local cache every 10 seconds. Parameter updates do not require a service restart to change resource allocation. This "field=resource type ID" design perfectly suits the probability operation needs in high-concurrency scenarios. For example, reading probability: to obtain the probability of "cloud server (type_001)" in the "cloud_base_01 resource pool," the value of the corresponding field (i.e., the probability value, such as the converted integer "1000" corresponding to 1%) can be accurately read directly using the HGET resource:prob:cloud_base_01 type_001 command, without needing to traverse all probability data in the entire resource pool. Updating probability: if the probability of "cloud server" is adjusted from 1% to 2% (converted to the integer 2000), the value of this field can be directly updated using the HSET resource:prob:cloud_base_01 type_001 2000 command. This operation is highly atomic, has a short execution time, and does not affect the probability data of other resource types.

[0038] Example: Under key="resource:prob:cloud_base_01" (cloud_base_01 resource pool), field="type_001" (cloud server) corresponds to value="1000" (1%), and field="type_002" (cloud storage) corresponds to value="5000" (5%), forming a precise mapping of "resource pool - resource type - probability".

[0039] The following is an illustrative explanation of the binary matching process. For example, in one example, when a user initiates a resource request, after determining that the user is eligible to apply for the resource, a random number named randomInt is randomly generated within the range of 1 to PROBABILITY_BASE. Then, the following data testing process is executed.

[0040] Test 1: randomInt = 500 → Check 500∈[1, 1000] → Meets the resource allocation probability condition of resource 1, that is, the target resource is matched and the resource allocation process is triggered.

[0041] Test 2: randomInt = 3000 → Check 3000∈[1001, 6000] → Meets the resource allocation probability condition of resource 2, that is, the target resource is matched and the resource allocation process is triggered.

[0042] Test 3: randomInt = 8000 → Check 8000∈[6001, 16000] → Meets the resource allocation probability condition of resource 3, that is, the target resource is matched and the resource allocation process is triggered.

[0043] Test 4: randomInt = 50000 → Check 50000∈[16001, 100000] → No matching target resource was found, and the resource allocation process was closed.

[0044] Step 2.3: If the resource request matches the target resource, then the resource request is determined to meet the resource allocation probability condition.

[0045] That is, if the random number randomInt lies within a certain valid probability interval If the random number (randomInt) falls within the probability range of "no resource allocation", then the resource request is considered to have matched the target resource, and the resource request meets the resource allocation probability condition. If the random number (randomInt) falls within the probability range of "no resource allocation", then the resource request is considered not to have matched the target resource.

[0046] Step 2.4: If the resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability conditions, and the user is prompted that the resource allocation has failed.

[0047] Step 3: If the resource request meets the resource allocation probability conditions, the resource request is intercepted and verified through a five-layer risk control mechanism; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed.

[0048] If the resource allocation meets the probability conditions, further judgment is made as to whether multi-layer protection is satisfied. This application utilizes multi-dimensional risk control interception technology, and the designed multi-level risk control inspection mechanism ensures the security and fairness of resource allocation tasks through a five-layer protection system. A progressive inspection strategy is adopted, filtering layer by layer from probability verification to behavioral analysis. The process of intercepting and verifying the resource request through the five-layer risk control mechanism is as follows (3.1) to (3.5).

[0049] 3.1) First layer: Call the third-party risk control API (Application Programming Interface) to assess the user's risk level using the HTTPS protocol, store the assessment results in Redis and set the cache validity period to 5 minutes, and intercept resource requests if the user is a risk control user.

[0050] The first layer of the five-layer risk control mechanism is user risk restriction. It calls the risk control system interface to assess the user's risk level, specifically by calling a third-party risk control API using the HTTPS protocol. The API returns whether the user is a risk-controlled user, and the query result is stored in Redis with a 5-minute cache validity period, saving query time. If the user is indeed a risk-controlled user, the resource request is intercepted, and the user is notified of resource allocation failure. In risk control scenarios, a third-party risk control API (Application Programming Interface) specifically refers to the interface service exposed by a third-party risk control service provider, used to invoke its risk control capabilities (such as identity verification, credit scoring, and anti-fraud detection). HTTPS (Hypertext Transfer Protocol Secure) is a secure protocol for transferring hypertext.

[0051] 3.2) Second layer: Store blacklisted users through Redis's hash structure, with user ID as the key and user's malicious behavior characteristics as the value. If the current user is a blacklisted user, the resource request will be blocked.

[0052] The second layer of the five-layer risk control mechanism is the Redis blacklist restriction. By monitoring user resource request behavior in real time, behaviors such as "initiating resource requests multiple times in a short period of time and then canceling them" are marked as abnormal and regarded as blacklisted users. The user ID and behavior characteristics of the confirmed malicious requests are stored in Redis, using an efficient data structure (such as Hash) for storage. One key maps to a set of field-value pairs, with the user ID as the key and the behavior as the value. It has high memory utilization and can be queried quickly.

[0053] 3.3) The third layer: The number of times a user's resource is allocated is recorded through Redis's Hash structure. After each allocation, the count is updated through Redis's INCR command. If the count exceeds the maximum number of times a single user can obtain the resource, the resource request is intercepted.

[0054] The third layer of the five-layer risk control mechanism is a limit on the number of times a user can allocate resources. This is stored in Redis using a hash function (key=user:count: resource allocation task ID, field = user ID). After each resource allocation, Redis performs an INCR count and retrieves the currently allocated amount using Redis's HGET command. The system then checks if the user's resource allocation count has exceeded the limit (maximum number of times a single user can retrieve resources). If it does, the resource request is intercepted, and the user is notified that the resource allocation failed. INCR is an atomic command provided by Redis. By treating Redis as an "atomic calculator," this command increments the number corresponding to a given key by 1. The entire operation is single-threaded and uninterruptible, so no matter how many clients execute it simultaneously, there will be no "read-modify-write" conflict. HGET is one of Redis's hash table commands, specifically "HGET key field," used to retrieve the value of the field "field" from the hash table key.

[0055] The core logic of the Redis Hash data structure is as follows: Redis Hash is a three-layer storage structure of "key-field-value". Each key corresponds to a set of "field-value" key-value pairs, enabling aggregated storage and precise operations on the same type of data. The "key" is the top-level unique identifier for data in Redis, used to distinguish different types and scenarios of data. In "key=user:count: resource allocation task ID", the prefix "user:count:" is a semantic naming convention defined by the developers, directly indicating the core purpose of this Redis key—storing "the number of resource allocations (count) for a user". This naming method can quickly distinguish other types of data (such as "user:blacklist:" for risk control blacklists, and "resource:prob:" for resource probabilities), facilitating system maintenance and data retrieval. The suffix "resource allocation task ID" is used to locate the specific task. The "Resource Allocation Task ID" is a dynamic variable that corresponds to the "task_id" field in the subsequent total inventory table (bd_resource_info) and time-period inventory table (bd_resource_stat). Its purpose is to bind the "user allocation count" to the "specific task": user counts for different resource allocation tasks (such as "618 e-commerce coupon allocation task" and "enterprise cloud server scheduling task") need to be stored separately to avoid data confusion. "field = user ID" is used to locate the allocation count of a "specific user" under the current task. "field" is a second-level unique identifier belonging to the key in the Redis Hash structure, used to accurately locate the allocation count data of a "single user" within the "set of user counts for the same task".

[0056] 3.4) Fourth layer: Obtain the user's geographical location through IP resolution and match it with the resource delivery area whitelist. If the user's geographical location is not in the whitelist, the resource request will be blocked.

[0057] The fourth layer of the five-layer risk control mechanism is geographical restriction. It verifies the geographical location based on resource allocation; if the location does not match the resource usage area, the user is prompted that resource allocation has failed. The geofencing check mechanism uses precise IP resolution to achieve geographically targeted resource allocation control, as detailed below.

[0058] First, the `X-Forwarded-For` parameter in the `HttpServletRequest` is checked for null. If not, the client's IP address is extracted via `Proxy-Client-IP`. The `ip2region.xdb` file is loaded into memory using a Memory-Mapped File method, and the IP address is converted to a 32-bit integer `IP_int`. A binary search algorithm is used to locate the range containing `IP_int` in the index area. After finding the matching range, the data area is located based on the pointer offset. A 4-byte data block pointer is read from the data area to obtain the structured data of "Country|Province|City|Carrier". Then, the whitelist of allowed regions is queried and loaded, and streaming processing is used for precise matching at the province-city level. When a user's location is detected as outside the permitted range, the resource allocation process is immediately blocked, and the user is notified of resource allocation failure. Redis caching optimization keeps the region check time within 5ms. Furthermore, the deployment region can be modified in the database and updated via Redis without restarting the service.

[0059] "HttpServletRequest" is an interface in the Java Servlet specification, representing an HTTP request. It provides all request-related information, including the request line, request headers, parameters, cookies, body, and remote IP address. "X-Forwarded-For (XFF)" is an HTTP extension header field used when a user → proxy / load balancer → server is executed. The real user's IP address is appended to this header by the proxy, formatted as "X-Forwarded-For: real IP, proxy1IP, proxy2IP". The address before the first comma is the original client IP, followed by the intermediate proxy addresses. "Proxy-Client-IP" is another non-standard request header used by older proxies, similar in function to X-Forwarded-For, but storing only one IP address without a linked list. The ip2region.xdb file is an "IP → geolocation" database file released by the open-source project ip2region. Its internal structure is "header + index area (ordered IP range records) + data area (country|region|province / city|carrier text)". The Memory-Mapped File method refers to mapping disk files to virtual memory address space, allowing direct reading of disk contents like accessing an array, without using the read() system call.

[0060] The geofencing inspection mechanism used in this application differs from the traditional IP database. By preloading the ip2region.xdb binary data file into memory and utilizing its built-in vector indexing algorithm to perform a fast binary search on the client IP, it can return regional information in milliseconds, achieving a high efficiency of more than 100,000 matches per second.

[0061] 3.5) Fifth layer: The token bucket algorithm is used to implement time window control. The bucket capacity and token generation rate are set. If the number of resource requests exceeds the token generation rate, the resource requests are blocked.

[0062] The fifth layer of the five-layer risk control mechanism is a limit on the number of resource requests within a time window. This time window is implemented using the token bucket algorithm (Java Guava library). The specific algorithm is as follows: assuming a bucket capacity of 10,000 and a token generation rate of 5,000 per second, 5,000 resource requests are allowed per second; requests exceeding this limit are rejected. By controlling high-frequency operations through the time window and limiting the number of requests per second, exceeding this limit results in a direct notification of resource allocation failure to the user, mitigating the impact of high-concurrency traffic on system experience, ensuring the smooth operation of resource allocation tasks, and improving the overall user experience.

[0063] The above five-layer risk control mechanism operates independently and identifies issues rapidly. If any layer fails verification, the resource allocation process is immediately terminated. This layered defense architecture improves the risk interception rate, quickly filters out requests that do not require a response, maintains millisecond-level response speed, and increases the system's capacity to handle users.

[0064] Step 4: If the resource request passes the interception and verification of the five-layer risk control mechanism, determine whether the current remaining resource quantity meets the resource request based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory; if the resource request fails the interception and verification of the five-layer risk control mechanism, prompt the user that the resource allocation has failed.

[0065] This application employs a three-tier inventory architecture to achieve refined inventory control. Through a hierarchical structure of "total inventory - time-period inventory - Redis real-time inventory," precise control of resource quantities is achieved. The main process involves configuring the usable quantity of each resource in the total inventory table, splitting resources into time periods in the time-period inventory table, configuring the amount of resources that can be consumed in each time period, and using Redis to track consumption in real time, comparing the Redis consumption quantity with the total inventory quantity.

[0066] The method for determining whether the current remaining resource quantity satisfies the resource request based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory specifically includes the following steps (4.1) to (4.4).

[0067] 4.1) Total Inventory Control: By using row-level locks in the MySQL InnoDB engine, the total inventory limit is queried based on the resource ID to ensure that resource allocation in all time periods does not exceed the total inventory.

[0068] The first layer of the three-tier inventory architecture is the total inventory control layer. This layer uses row-level locking (FOR UPDATE) on the MySQL InnoDB engine to query the inventory quantity of resources by resource ID. MySQL's InnoDB engine is a transactional storage engine; row-level locking (FOR UPDATE) is used to add a write lock to the retrieved row, resolving the "overselling / dirty read" problem during concurrent deductions. Specifically, the total resource inventory is first maintained through the database table `bd_resource_info`. The key to this layer is establishing a global control baseline; all allocations during all time periods will be within the total inventory limit, ensuring that no over-allocation occurs. The database uses row-level locking to guarantee the accuracy and consistency of the total inventory data in a concurrent environment. The structure of the total resource inventory table is shown in Table 2 below.

[0069] Table 2 Total Inventory Quantity Table

[0070] 4.2) Time-based inventory control: Configure the inventory quantity for each time period in the database table, and use a timer to automatically carry over unissued inventory from historical time periods to the current time period, calculating "current time period available inventory = current time period configured inventory + historical time period inventory balance".

[0071] Building upon the overall inventory control layer, the second layer of the three-tier inventory architecture (the time-segment inventory control layer) enables refined control across time and space. Time-segmented inventory plans are configured in the `bd_resource_stat` table, allowing resource control based on time. For example, during peak traffic hours (10 AM - 12 PM), 800 units are allocated; during secondary peak hours (3 PM - 5 PM), 600 units are allocated; and the remaining 600 units are evenly distributed across the remaining time periods. The system automatically generates a time-segment inventory allocation table, recording key parameters such as the start and end times and available quantities for each time period.

[0072] When a resource is requested, the system first locates the time period to which the current time belongs and queries the remaining inventory. It then queries the Redis inventory balance, adds the current remaining inventory to the historical time period's inventory balance, and subtracts the current inventory issuance. The resulting remaining quantity is the number of resources currently available. A timer is used to automatically carry over unissued inventory resources from the previous time period to the next time period, preventing resource waste. The structure of the time-segmented inventory table `bd_resource_stat` is as follows.

[0073] Table 3. Inventory by Time Period

[0074] 4.3) Redis Real-time Inventory Control: After each successful resource allocation, the real-time resource consumption quantity is updated through Redis atomic operations, and "Current remaining resources (current available resources) = Current available inventory quantity - Real-time resource consumption quantity (current allocated quantity)" is calculated.

[0075] The third layer of the three-tier inventory architecture is the real-time verification layer. After each successful resource allocation, the corresponding resource consumption count is incremented by one in Redis. Finally, the current total number of resources is queried and compared with the real-time consumption of resources across the entire network recorded in Redis. If the current consumption is greater than or equal to the total number of resources, it is determined that the inventory is insufficient, and resource allocation is immediately blocked; otherwise, the subsequent resource allocation process continues.

[0076] 4.4) Determine whether the current remaining amount of resources is greater than or equal to 1 unit. If yes, determine that the current remaining amount of resources satisfies the resource request; otherwise, determine that the current remaining amount of resources does not satisfy the resource request.

[0077] For example, when a company user initiates a cloud server resource allocation request at 11:00 AM on Friday, the system first confirms that the current time period is "10:00-12:00". It checks the configured inventory level for this time period (800 units), the remaining inventory from the previous time period (150 units), and the Redis display showing that 90 units have been consumed. Therefore, the actual available quantity (current remaining resource) = (800 + 150) - 90 = 860 units. If the current remaining resource quantity (860 units) at the time of the request is ≥ 1 unit, the request is approved; otherwise, the resource request fails. This mechanism automatically associates time period keys to achieve inventory carryover, and combines Redis atomic operations to ensure data consistency under high concurrency, supporting inventory deployment strategies with minute-level precision.

[0078] Step 5: If the current remaining resources meet the resource request, use dual distributed locks to control the concurrent resource allocation process, issue the target resources to the user, update the three-level inventory, and complete the dynamic allocation of resources; if the current remaining resources do not meet the resource request, prompt the user that the resource allocation has failed.

[0079] The dual distributed lock is implemented based on Redis. It uses the SETNX command to create an outer user resource allocation task lock and an inner resource inventory lock, and sets expiration times for each lock. The outer user resource allocation task lock controls concurrent resource requests from a single user, while the inner resource inventory lock controls concurrent allocation of the same resource by multiple users. SETNX refers to the "SET if Not eXists" command provided by Redis. Utilizing SETNX's "create only if it doesn't exist" characteristic ensures that only one client can acquire the lock at a time, and the expiration time further prevents deadlocks.

[0080] After a user's resource request passes through multiple layers of protection, the system queries the current time period's resource configuration, historical resource balance, and current resource consumption, and verifies that the total number of resource allocations is less than the total number of resources. If there are still resources remaining, the system allocates resources to the user, increments the consumption quantity by 1, and ends the process after resource allocation.

[0081] The dynamic probability interval matching algorithm in this application achieves accurate calculation of resource allocation probability in high-concurrency scenarios by converting probability intervals through integer operations and matching random numbers using binary search. Through a five-layer risk control mechanism, including user risk assessment interface, Redis blacklist storage, counter limits, regional resolution algorithm, and time window algorithm, it achieves efficient and accurate identification and interception of abnormal requests. The token bucket algorithm controls the frequency of resource requests based on "bucket capacity + token generation rate," mitigating the impact of high-concurrency traffic. The time-segmented inventory management adopts a three-level technical architecture of "total inventory - time-segment inventory - Redis real-time inventory," controlling the total inventory through database transactions, automatically carrying over time-segment inventory through scheduled tasks, and maintaining real-time inventory through Redis atomic operations, supporting dynamic allocation with minute-level precision. Based on Redis, a dual distributed lock is implemented, utilizing a nested distributed lock technology of user resource allocation task lock (outer layer) and resource inventory lock (inner layer), and avoiding global lock contention through the SETNX command and expiration time control.

[0082] This application, through its innovative five-layer risk control system, time-segmented inventory management, and dual distributed lock mechanism, completely solves the problems of traditional system inventory management such as extensiveness, low concurrency performance, and difficulty in expansion. It achieves technical effects such as improved inventory utilization, enhanced system concurrency capabilities, and stricter risk control, providing a high-performance and highly available full-stack solution for high-concurrency resource allocation scenarios (such as e-commerce resource scheduling, cloud service resource distribution, device resource management, and public service resource allocation).

[0083] In one exemplary embodiment, this application also provides a dynamic resource allocation system for high-concurrency scenarios, comprising: The resource application eligibility assessment module is used to receive resource requests initiated by users and determine whether the users are eligible to apply for resources. The resource allocation probability condition judgment module is used to determine whether the resource request meets the resource allocation probability condition based on a dynamic probability interval matching algorithm if the user is eligible to apply for resources; if the user is not eligible to apply for resources, the module will prompt the user that they are not eligible to apply for resources. The multi-dimensional risk control and protection module is used to intercept and verify the resource request through a five-layer risk control mechanism if the resource request meets the resource allocation probability conditions; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed. The three-level inventory management module is used to determine whether the current remaining amount of resources meets the resource request if the resource request passes the interception and verification of the five-layer risk control mechanism, based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory; if the resource request fails the interception and verification of the five-layer risk control mechanism, the user is prompted that the resource allocation has failed. The dual distributed lock concurrency control module is used to control the concurrent resource allocation process using dual distributed locks if the current remaining resource quantity meets the resource request, to issue the target resource to the user, and update the three-level inventory to complete the dynamic allocation of resources; if the current remaining resource quantity does not meet the resource request, the user is prompted that the resource allocation has failed.

[0084] Current inventory resource allocation methods / systems exhibit numerous problems during operation, such as the inability to reject invalid requests, reliance on MySQL for resource control, and lock contention caused by global locks in concurrency control, all of which degrade overall system performance. To address these issues, this application improves the request processing implementation by introducing a dynamic probability interval matching algorithm, a five-layer risk control mechanism, time-segmented inventory management, and dual distributed locks. This improves request filtering efficiency, effectively rejects invalid requests, significantly enhances the system's traffic handling capacity, increases system stability, achieves resource inventory control, prevents over-issuance, and maximizes resource allocation. This mechanism not only improves system flexibility but also enhances system stability, increasing competitiveness under market conditions.

[0085] In one exemplary embodiment, this application also provides an electronic device, which may be a server or a terminal. The electronic device includes a processor, a memory, an input / output interface, and a communication interface. The processor, memory, and input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the electronic device provides computing and control capabilities. The memory of the electronic device is a non-transitory computer-readable storage medium, including a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the electronic device is used for exchanging information between the processor and external devices. The communication interface of the electronic device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the aforementioned dynamic resource allocation method in high-concurrency scenarios.

[0086] In one exemplary embodiment, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method for dynamic resource allocation in high-concurrency scenarios.

[0087] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer program instructions. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any reference to memory or other media in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0088] It should be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0089] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0090] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for dynamic resource allocation in high-concurrency scenarios, characterized in that, include: Receive resource requests initiated by users and determine whether users are eligible to apply for resources; If the user is eligible to apply for resources, the system uses a dynamic probability interval matching algorithm to determine whether the resource request meets the resource allocation probability conditions; if the user is not eligible to apply for resources, the system will prompt the user that they are not eligible to apply for resources. If the resource request meets the resource allocation probability conditions, the resource request is intercepted and verified through a five-layer risk control mechanism; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed. If the resource request passes the interception and verification of the five-layer risk control mechanism, the remaining amount of resources is determined based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory to determine whether the current remaining amount of resources can meet the resource request. If the resource request fails to pass the interception and verification of the five-layer risk control mechanism, the user will be prompted that the resource allocation has failed. If the current remaining resources meet the resource request, a dual distributed lock is used to control the concurrent resource allocation process, the target resource is issued to the user, and the three-level inventory is updated to complete the dynamic allocation of resources; if the current remaining resources do not meet the resource request, the user is prompted that the resource allocation has failed.

2. The method for dynamic resource allocation in high-concurrency scenarios according to claim 1, characterized in that, The step of determining whether a resource request meets the resource allocation probability conditions based on a dynamic probability interval matching algorithm specifically includes: Set a probability baseline value, convert the allocation probability of each resource into an integer, and calculate the probability interval corresponding to each resource; After receiving a resource request initiated by a user and determining that the user is qualified to apply for the resource, a random number is generated within the numerical range corresponding to the probability benchmark value. The random number is then matched with the probability range using a binary search method to determine whether the resource request matches the target resource. If a resource request matches the target resource, then the resource request is determined to meet the resource allocation probability condition. If a resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability conditions, and the user is prompted that the resource allocation has failed.

3. The method for dynamic resource allocation in high-concurrency scenarios according to claim 2, characterized in that, The setting of a probability benchmark value involves converting the allocation probability of each resource into an integer and calculating the probability interval corresponding to each resource, specifically including: Set probability baseline value Using formula Convert the allocation probabilities of each resource into integers; where Representing resources The probability of allocation; Represents the integer after the probability value has been converted; Using formula and Calculate each resource Corresponding probability interval ;in Representing resources The starting position within the probability interval; Representing resources The end position within the probability interval.

4. The method for dynamic resource allocation in high-concurrency scenarios according to claim 2, characterized in that, The five-layer risk control mechanism for intercepting and verifying resource requests specifically includes: First layer: Call the third-party risk control API to assess the user's risk level using the HTTPS protocol, store the assessment results in Redis and set the cache validity period to 5 minutes, and block resource requests if the user is a risk control user; The second layer stores blacklisted users through Redis's hash structure, using user ID as the key and user's malicious behavior characteristics as the value. If the current user is a blacklisted user, resource requests are blocked. The third layer: Records the number of times a user's resource is allocated through a hash structure in Redis. After each allocation, the count is updated using the INCR command in Redis. If the count exceeds the maximum number of times a single user can acquire the resource, the resource request is blocked. The fourth layer: Obtain the user's geographical location through IP resolution and match it with the resource delivery area whitelist. If the user's geographical location is not in the whitelist, the resource request will be blocked. The fifth layer uses the token bucket algorithm to control the time window, setting the bucket capacity and token generation rate. If the number of resource requests exceeds the token generation rate, the resource requests are blocked. The five-layer risk control mechanism operates independently for interception and verification. If any layer fails verification, the resource allocation process is immediately terminated.

5. The method for dynamic resource allocation in high-concurrency scenarios according to claim 4, characterized in that, The three-tier inventory architecture based on total inventory - time-period inventory - Redis real-time inventory determines whether the current remaining resource quantity meets the resource request, specifically including: Total inventory control: By using row-level locks in the MySQL InnoDB engine, the total inventory limit is queried based on the resource ID to ensure that resource allocation in all time periods does not exceed the total inventory. Time-based inventory control: Configure the inventory quantity for each time period in the database table, and use a timer to automatically carry over unissued inventory from historical time periods to the current time period. Calculate the available inventory for the current time period = configured inventory quantity for the current time period + inventory balance from historical time periods. Redis Real-time Inventory Control: After each successful resource allocation, the real-time resource consumption quantity is updated through Redis atomic operations, and the current remaining resource quantity is calculated as: Current available inventory quantity - Real-time resource consumption quantity. Determine whether the current remaining amount of resources is greater than or equal to 1 unit; if yes, determine that the current remaining amount of resources satisfies the resource request; if no, determine that the current remaining amount of resources does not satisfy the resource request.

6. The method for dynamic resource allocation in high-concurrency scenarios according to claim 5, characterized in that, The process of using dual distributed locks to control resource allocation concurrency specifically includes: The dual distributed lock is implemented based on Redis. It creates an outer user resource allocation task lock and an inner resource inventory lock using the SETNX command and sets the lock's expiration time. The outer user resource allocation task lock is used to control concurrent resource requests from a single user, while the inner resource inventory lock is used to control concurrent allocation of the same resource by multiple users.

7. A dynamic resource allocation system for high-concurrency scenarios, characterized in that, include: The resource application eligibility assessment module is used to receive resource requests initiated by users and determine whether the users are eligible to apply for resources. The resource allocation probability condition judgment module is used to determine whether the resource request meets the resource allocation probability condition based on a dynamic probability interval matching algorithm if the user is eligible to apply for resources; if the user is not eligible to apply for resources, the module will prompt the user that they are not eligible to apply for resources. The multi-dimensional risk control and protection module is used to intercept and verify the resource request through a five-layer risk control mechanism if the resource request meets the resource allocation probability conditions; if the resource request does not meet the resource allocation probability conditions, the user is prompted that the resource allocation has failed. The three-level inventory management module is used to determine whether the current remaining amount of resources can meet the resource request if the resource request passes the interception and verification of the five-layer risk control mechanism, based on the three-level inventory architecture of total inventory - time period inventory - Redis real-time inventory. If the resource request fails to pass the interception and verification of the five-layer risk control mechanism, the user will be prompted that the resource allocation has failed. The dual distributed lock concurrency control module is used to control the concurrent resource allocation process using dual distributed locks if the current remaining resource quantity meets the resource request, to issue the target resource to the user, and update the three-level inventory to complete the dynamic allocation of resources; if the current remaining resource quantity does not meet the resource request, the user is prompted that the resource allocation has failed.

8. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the resource dynamic allocation method for high-concurrency scenarios as described in any one of claims 1 to 6.

9. The electronic device according to claim 8, characterized in that, The memory is a non-transitory computer-readable storage medium.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the method for dynamic resource allocation in high-concurrency scenarios as described in any one of claims 1 to 6.

Images