Resource dynamic allocation method, system, device and product in high concurrency scenario

Abstract

The application discloses a resource dynamic allocation method, system, device and product in a high concurrency scene, and relates to the field of resource allocation. First, a resource request initiated by a user is received, and it is judged whether the user has resource application qualifications. If the user has resource application qualifications, it is judged whether the resource request meets resource allocation probability conditions based on a dynamic probability interval matching algorithm. If the resource request meets the resource allocation probability conditions, the resource request is intercepted and verified through a five-layer risk control mechanism, otherwise the user is prompted that the resource allocation fails. If the resource request passes the interception and verification of the five-layer risk control mechanism, it is judged whether the current resource remaining quantity meets the resource request based on a three-level inventory architecture of total inventory-time period inventory-Redis real-time inventory. If yes, a double distributed lock is used to control a resource allocation concurrency process, target resources are issued to the user, and the three-level inventory is updated, so that the resource dynamic allocation is completed, and the resource allocation efficiency, stability and security are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of resource allocation, in particular to a resource dynamic allocation method, system, device and product in a high concurrency scenario. BACKGROUND

[0002] With the popularity of Internet applications, the demand for high concurrency, large data processing, data accuracy and system stability is increasingly prominent. However, the existing inventory resource allocation method exposes many problems in the running process. For example, the existing processing method generally depends on database query judgment for the basic interception function, lacks real-time and multi-dimensional protection, mainly uses relational databases (such as MySQL), and uses Redis for simple caching in some scenarios, lacking a hierarchical storage strategy. MySQL (MyStructured Query Language, My Structured 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 commonly known as an in-memory data structure storage system), NoSQL commonly known as "non-relational database". For example, the existing processing method has low efficiency for intercepting and cleaning data, unreasonable storage method, and insufficient processing request processing capacity. For high concurrency scenarios, there is a real-time processing delay for massive data (such as user requests and inventory data), and there is a concurrency control problem for high concurrency requests. Moreover, the existing processing method cannot efficiently identify and intercept malicious requests, resulting in the inability to guarantee system stability and data security. SUMMARY

[0003] The purpose of the present application is to provide a resource dynamic allocation method, system, device and product in a high concurrency scenario to improve resource allocation efficiency, stability and security.

[0004] To achieve the above purpose, the present application provides the following solutions.

[0005] In a first aspect, the present application provides a resource dynamic allocation method in a high concurrency scenario, comprising:

[0006] receiving a resource request initiated by a user, and determining whether the user has resource application qualifications;

[0007] If the user has resource application qualifications, determining whether the resource request meets resource allocation probability conditions based on a dynamic probability interval matching algorithm; if the user does not have resource application qualifications, prompting the user that he / she does not have resource application qualifications;

[0008] If the resource request meets the resource allocation probability condition, the five-layer risk control mechanism is used to intercept and check the resource request; if the resource request does not meet the resource allocation probability condition, the user is prompted that the resource allocation fails;

[0009] If the resource request passes the interception and check of the five-layer risk control mechanism, it is judged whether the current resource remaining amount 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 does not pass the interception and check of the five-layer risk control mechanism, the user is prompted that the resource allocation fails;

[0010] If the current resource remaining amount meets the resource request, a double distributed lock is used to control the resource allocation concurrency process, the target resource is issued to the user, and the three-level inventory is updated, thereby completing the resource dynamic allocation; if the current resource remaining amount does not meet the resource request, the user is prompted that the resource allocation fails.

[0011] Optionally, the method for judging whether the resource request meets the resource allocation probability condition based on the dynamic probability interval matching algorithm comprises the following steps.

[0012] A probability reference value is set, the allocation probability of each resource is converted into an integer, and the probability interval corresponding to each resource is calculated;

[0013] After receiving the resource request initiated by the user and determining that the user has the resource application qualification, a random number is generated in the numerical interval corresponding to the probability reference value, the random number is matched with the probability interval by using the dichotomy method, and it is determined whether the resource request matches the target resource;

[0014] If the resource request matches the target resource, it is determined that the resource request meets the resource allocation probability condition;

[0015] If the resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability condition, and the user is prompted that the resource allocation fails.

[0016] Optionally, the method for setting the probability reference value, converting the allocation probability of each resource into an integer, and calculating the probability interval corresponding to each resource comprises the following steps.

[0017] The probability reference value is set , the formula is used to convert the allocation probability of each resource into an integer; wherein represents the allocation probability of resource ; represents the integer after the probability value conversion;

[0018] The formula and are used to calculate the probability interval of each resource corresponding probability interval ; wherein representing resources start position in the probability interval; representing resources end position in the probability interval.

[0019] Optionally, the interception and verification of the resource request by the five-layer risk control mechanism specifically includes:

[0020] The first layer: calling a third-party risk control API to evaluate the user risk level by using the HTTPS protocol, storing the evaluation result to Redis, and setting the cache validity period to 5 minutes, and if the user is a risk control user, intercepting the resource request;

[0021] The second layer: storing blacklisted users in a hash structure of Redis, taking the user ID as the key and the user malicious behavior features as the value, and if the current user is a blacklisted user, intercepting the resource request;

[0022] The third layer: recording the number of times of user resource allocation in a hash structure of Redis, updating the count by using the INCR command of Redis after each allocation, and if the count exceeds the maximum number of acquisitions per user, intercepting the resource request;

[0023] The fourth layer: obtaining the geographic location of the user by IP resolution, matching with the white list of resource distribution area, and if the geographic location of the user is not in the white list, intercepting the resource request;

[0024] The fifth layer: using the token bucket algorithm to realize time window control, setting the bucket capacity and token generation rate, and if the number of resource requests exceeds the token generation rate, intercepting the resource request;

[0025] The interception and verification of the five-layer risk control mechanism are independently run, and if any layer of verification fails, the resource allocation process is immediately terminated.

[0026] Optionally, the three-level inventory architecture based on total inventory-time period inventory-Redis real-time inventory judges whether the current resource remaining quantity meets the resource request, specifically including:

[0027] Total inventory control: querying the total inventory limit based on the resource ID by using the row-level lock of the MySQL InnoDB engine, to ensure that the resource allocation of all time periods does not exceed the total inventory;

[0028] Time period inventory control: configuring the inventory quantity of each time period in the database table, realizing the automatic closing of the unissued inventory of the historical time period to the current time period by using the timer, and calculating the available amount of the current time period inventory = current time period inventory configuration amount + historical time period inventory balance;

[0029] Redis real-time inventory control: after each successful resource distribution, the real-time resource consumption quantity is updated through the atomic operation of Redis, and the current resource remaining quantity = the available quantity of the current period inventory - the real-time resource consumption quantity is calculated.

[0030] It is determined whether the current resource remaining quantity is greater than or equal to 1 portion. If yes, it is determined that the current resource remaining quantity meets the resource request. If no, it is determined that the current resource remaining quantity does not meet the resource request.

[0031] Optionally, the double distributed lock is used to control the resource allocation concurrency process, specifically including:

[0032] The double distributed lock is realized based on Redis, and the outer user resource allocation task lock and the inner resource inventory lock are created through the SETNX command and the expiration time of the lock is set.

[0033] The outer user resource allocation task lock is used to control the concurrent resource request of a single user, and the inner resource inventory lock is used to control the concurrent allocation of the same resource by multiple users.

[0034] Optionally, the resource includes cloud server resource, device resource and data resource; and the high concurrency scenario includes an e-commerce resource scheduling scenario, a cloud service resource distribution scenario, a device resource management scenario and a public service resource configuration scenario.

[0035] In a second aspect, the application provides a resource dynamic allocation system in a high concurrency scenario, including:

[0036] A resource application qualification judgment module is configured to receive a resource request initiated by a user and judge whether the user has resource application qualification;

[0037] A resource allocation probability condition judgment module is configured to judge whether the resource request meets resource allocation probability conditions based on a dynamic probability interval matching algorithm if the user has resource application qualification, and prompt the user that the user has no resource application qualification if the user does not have resource application qualification.

[0038] A multi-dimensional risk control protection module is configured to intercept and verify the resource request through a five-layer risk control mechanism if the resource request meets the resource allocation probability conditions, and prompt the user that the resource allocation fails if the resource request does not meet the resource allocation probability conditions.

[0039] A three-level inventory management module is configured to judge whether the current resource remaining quantity meets the resource request based on a three-level inventory architecture of total inventory-period inventory-Redis real-time inventory if the resource request passes the interception and verification of the five-layer risk control mechanism, and prompt the user that the resource allocation fails if the resource request does not pass the interception and verification of the five-layer risk control mechanism.

[0040] The double distributed lock concurrent control module is used to control the resource allocation concurrent process by using the double distributed lock if the current resource remaining amount meets the resource request, issue the target resource to the user, and update the three-level inventory to complete the resource dynamic allocation; if the current resource remaining amount does not meet the resource request, the user is prompted that the resource allocation fails.

[0041] In a third aspect, the present application provides an electronic device, comprising 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 in the high-concurrency scenario.

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

[0043] In a fourth aspect, the present application provides a computer program product comprising a computer program executable by a processor to implement the resource dynamic allocation method in the high-concurrency scenario.

[0044] According to the embodiments provided by the present application, the following technical effects are disclosed.

[0045] The resource dynamic allocation method, system, device and product in the high-concurrency scenario provided by the present application solve the problems of extensive traditional inventory resource management, low concurrent performance, and difficult expansion, and realize effective improvement of inventory utilization, improvement of concurrent processing capacity, and strict risk control, thereby improving the stability and reliability of the resource allocation process, ensuring the safety and fairness of the resource allocation process, realizing fine management and control of resource allocation, and improving the resource allocation efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0047] Figure 1 The flowchart of the resource dynamic allocation method in the high-concurrency scenario of the present application. DETAILED DESCRIPTION

[0048] With reference to the accompanying drawings, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of the present application.

[0049] The present application provides a resource dynamic allocation method, system, device and product in a high concurrency scenario, which aims to break through the performance bottleneck in a high concurrency scenario, solve the data consistency problem, and eliminate inventory over-issuance and resource waste through a new combination and implementation of resource allocation probability calculation technology, multi-dimensional risk control protection mechanism, time period inventory management, double distributed lock concurrency control and other technical means, which can not only improve the stability and reliability of the resource allocation process, but also guarantee the safety and fairness of the resource allocation process, realize fine control of resource allocation, and improve resource allocation efficiency.

[0050] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application will be described in detail below with reference to the drawings and specific embodiments.

[0051] In an exemplary embodiment, as shown in Figure 1 A resource dynamic allocation method in a high concurrency scenario is provided, including the following steps 1 to 5.

[0052] Step 1: receiving a resource request initiated by a user, and determining whether the user has resource application qualifications.

[0053] The present application aims to provide 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 configuration. Therefore, the high-concurrency scenario targeted by the present application usually refers to e-commerce resource scheduling scenarios, cloud service resource distribution scenarios, device resource management scenarios, and public service resource configuration scenarios. The resources requested by the user can cover cloud server resources, device resources, and data resources.

[0054] After receiving a resource request initiated by a user, it is first determined whether the user has resource application qualifications. "The user has resource application qualifications" usually means that the user is a legal target group, and the application behavior matches the basic configuration of the resource (resource pool, resource type, attribute limit).

[0055] Step 2: If the user has resource application qualifications, it is determined whether the resource request meets the resource allocation probability condition based on a dynamic probability interval matching algorithm; if the user does not have resource application qualifications, the user is prompted that he / she does not have resource application qualifications.

[0056] If it is determined that the user has the resource application qualification, it is further judged whether the resource allocation meets the probability condition. The dynamic probability interval matching algorithm is used to judge whether the resource request meets the resource allocation probability condition, which specifically includes the following steps 2.1 to 2.4.

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

[0058] Set a probability reference value , and convert the allocation probability of each resource into an integer using the following formula:

[0059] (1);

[0060] Wherein, represents the allocation probability of resource , usually in percentage form; represents the integer after the probability value conversion. For example, set the probability reference value PROBABILITY_BASE=100000 (supporting 0.001% level precision), that is, the integer obtained by multiplying the resource allocation probability (percent) by the reference value PROBABILITY_BASE (100000), for example, 5% is converted to 5000.

[0061] On this basis, the probability interval (also called allocation interval) corresponding to each resource is calculated using formulas (2) and (3):

[0062] (2);

[0063] (3);

[0064] Wherein, represents the starting position of resource in the probability interval, which is an integer type and has a value range of 1~PROBABILITY_BASE; represents the end position of resource in the probability interval, which is also an integer type and has a value range of . That is, the probability interval corresponding to resource is .

[0065] Assume that there are three types of resources (resource 1, resource 2, and resource 3) and no allocation of resources, which correspond to Each resource covers the allocation interval 1-PROBABILITY_BASE according to the allocation probability, which is [1, 100000] in this example. The dynamic probability interval matching process is shown in Table 1.

[0066] Table 1 Dynamic probability interval matching

[0067]

[0068] Step 2.2: After receiving the user-initiated resource request and determining that the user has the resource application qualification, a random number is generated in the numerical interval corresponding to the probability benchmark value. The bisection method is used to match the random number with the probability interval to determine whether the resource request matches the target resource.

[0069] The dynamic probability interval matching algorithm of the present application first sets the probability benchmark value PROBABILITY_BASE = 100000 (supporting 0.001% level precision), converts the resource allocation probability (such as 1%) into an integer (such as 1000), and then calculates the probability interval of resource allocation through integer addition and subtraction. The interval boundaries are stored in an array . After obtaining a random number in the 1-100000 interval during the query, the random number is matched through the bisection method, reducing the single matching time from O(n) to O(log n). The random number belongs to the allocation interval, and the allocated resource is locked. Here, O(n) and O(log n) are "Big O notation" used in computer science to describe the time complexity of an algorithm. O(n) indicates that the running time of the algorithm increases linearly with the increase of the input size n. O(log n) indicates that the running time increases logarithmically with the increase of the input size n, which grows very slowly.

[0070] In particular, the resource allocation probability is stored in the Hash structure of Redis (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 middleware. The core logic of the Redis Hash structure is that Redis Hash is a three-layer storage model of "top-level key-secondary field-bottom-level value", which can realize "aggregated storage of the same type of data and precise operation of individual data". "key = resource:prob: resource pool ID" is used to locate the probability set of all resources of "a certain resource pool", where "key" is the top-level unique identifier of data in Redis, used to distinguish data in different scenarios and different dimensions. In the scenario of "storing resource allocation probability", the core of the design of this key is to "accurately lock all resource type probabilities under a specific resource pool". The prefix "resource:prob:" is a business semantic naming specification defined by the developer, which directly and explicitly indicates the core role of the Redis key - storing "resource (resource) allocation probability (prob, the abbreviation of probability)". This naming method can quickly distinguish other types of data (such as "user allocation times" with the prefix "user:count:" and "blacklist" with the prefix "user:blacklist:") and avoid confusion between different business data, while facilitating the quick identification of data use by developers and maintenance 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 (such as "e-commerce 618 coupon resource pool", "enterprise cloud service basic resource pool", "device scheduling resource pool", etc.), each resource pool has a unique ID (such as "pool_202406", "cloud_base_01"). Its role is to bind "resource allocation probability" with "specific resource pool": the resource probabilities of different resource pools need to be stored independently (for example, the probability of "full-reduction coupons" in the "coupon resource pool" is irrelevant to the probability of "cloud servers" in the "cloud resource pool"), and by using "resource pool ID" as the suffix, the uniqueness of the key can be ensured, and the probability data set of "all resource types under a certain resource pool" can be accurately located. "field = resource type ID" is used to locate the probability of "a specific resource type under a certain resource pool". "field" is a secondary unique identifier in the Redis Hash structure that belongs to the top-level key, used to accurately locate the allocation probability of a specific resource type in the "probability set of the same resource pool (corresponding to the top-level key)"."Resource type ID" is the "minimum unit identification of resource classification", corresponding to the "resource_type" field in the subsequent total inventory table (bd_resource_info). The resource type is a subdivision classification within the resource pool (for example, under "cloud_base_01 resource pool", the resource type can be divided into "cloud server (type_001)", "cloud storage (type_002)", and "load balancing (type_003)"). Each resource type has a unique ID. Taking "resource type ID" as the field can ensure that each resource type has an independent storage location under the same resource pool (corresponding to the top-level key), and they do not interfere with each other (for example, "type_001" corresponds to the probability of cloud server, and "type_002" corresponds to the probability of cloud storage).

[0071] If the resource is changed, the resource allocation probability in the database is adjusted, and the background thread is synchronized to the local cache every 10 seconds. The parameter update does not need to restart the service, and the resource allocation situation can be changed. The design of "field=resource type ID" in this application is exactly suitable for the probability operation needs in high-concurrency scenarios. For example, reading probability: if you need to get the probability of "cloud server (type_001)" in "cloud_base_01 resource pool", you can directly use the HGET resource:prob:cloud_base_01 type_001 command to accurately read the value of the corresponding field (i.e. the probability value, such as the converted integer "1000" corresponding to 1%), without the need to traverse all the probability data of the entire resource pool. Update probability: if the probability of "cloud server" is adjusted from 1% to 2% (converted to integer 2000), you can directly update the value of this field using the HSET resource:prob:cloud_base_01 type_001 2000 command. The operation has strong atomicity, short time consumption, and does not affect the probability data of other resource types.

[0072] 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".

[0073] The following illustrates the dichotomy matching process. For example, in one example, a user initiates a resource request, first determines whether the user is eligible for resource application, then generates a random number randomInt in the range of 1-PROBABILITY_BASE, and then performs the following data test process.

[0074] Test 1: randomInt = 500→ check 500∈[1, 1000]→ match the resource allocation probability condition of resource 1, i.e. match the target resource, trigger the resource allocation process.

[0075] Test 2: randomInt = 3000→ check 3000∈[1001, 6000]→ match the resource allocation probability condition of resource 2, i.e. match the target resource, trigger the resource allocation process.

[0076] Test 3: randomInt = 8000→ check 8000∈[6001, 16000]→ match the resource allocation probability condition of resource 3, i.e. match the target resource, trigger the resource allocation process.

[0077] Test 4: randomInt = 50000→ check 50000∈[16001, 100000]→ no matching target resource, close the resource allocation process.

[0078] Step 2.3: If the resource request matches the target resource, it is determined that the resource request meets the resource allocation probability condition.

[0079] That is, if the random number randomInt is in a certain valid probability interval (e.g. the probability interval of resources 1, 2, and 3), it is considered that the resource request matches the target resource, and it is determined that the resource request meets the resource allocation probability condition. If the random number randomInt is in the probability interval of "no resource allocation", it is considered that the resource request does not match the target resource.

[0080] 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 condition, and the user is prompted that the resource allocation fails.

[0081] Step 3: If the resource request meets the resource allocation probability condition, the resource request is intercepted and verified by the five-layer risk control mechanism; if the resource request does not meet the resource allocation probability condition, the user is prompted that the resource allocation fails.

[0082] If the resource allocation meets the probability condition, it is further judged whether the multi-layer protection is met. The present application uses multi-dimensional risk control interception technology, and a multi-level risk control check mechanism is designed to ensure the security and fairness of the resource allocation task through a five-layer protection system. An incremental check strategy is adopted to filter layer by layer from probability verification to behavior analysis. The process of intercepting and checking the resource request through the five-layer risk control mechanism is as follows 3.1) to 3.5).

[0083] 3.1) First layer: Call third-party risk control API (Application Programming Interface, application programming interface) to evaluate user risk level using HTTPS protocol, store the evaluation result to Redis, and set the cache validity period to 5 minutes. If the user is a risk control user, intercept the resource request.

[0084] The first layer of protection of the five-layer risk control mechanism is user risk limitation. The risk control system interface is called to evaluate the user risk level, that is, the third-party risk control API is called using the HTTPS protocol, and it is returned whether the user is a risk control user. The query result is stored in Redis, and the Redis cache validity period is 5 minutes, which saves the time of each query. When it is returned that the user is a risk control user, the resource request is intercepted and the user is prompted that the resource allocation fails. The third-party risk control API (Application Programming Interface, application programming interface) refers to the interface service provided by a third-party risk control service provider to the outside in the risk control scene, which is used to call its risk control capabilities (such as identity verification, credit scoring, anti-fraud detection, etc.). The HTTPS (HyperText Transfer Protocol Secure) protocol refers to the HyperText Transfer Protocol Secure.

[0085] 3.2) Second layer: Store blacklisted users in the Hash structure of Redis, with user ID as key and user malicious behavior features as value. If the current user is a blacklisted user, intercept the resource request.

[0086] The second layer of protection of the five-layer risk control mechanism is Redis blacklist limitation. The user resource request behavior is monitored in real time, and behaviors such as "canceling resource requests after multiple initiations in a short time" are marked as abnormal, and are regarded as blacklisted users. The user ID and behavior features of the malicious request confirmed are stored in Redis, and are stored using an efficient data structure (such as Hash). One key (key) is mapped to a field-value (field-value) pair set, the user ID is the key, and the behavior is the value. The memory utilization rate is high and can be quickly queried.

[0087] 3.3) The third layer: record the number of user resource allocation times through the Hash structure of Redis, update the count through the INCR command of Redis after each allocation, and intercept the resource request if the count exceeds the maximum number of single user acquisition.

[0088] The third layer of the five-layer risk control mechanism is the user resource allocation times limit. The user resource allocation times are stored in Redis using Hash (key=user:count: resource allocation task ID, field = user ID). After each resource allocation, the count is updated through Redis INCR, and the current allocated amount is obtained through Redis HGET to determine whether the user resource allocation times exceed the upper limit (the maximum number of single user acquisition). If it exceeds, the resource request is intercepted, and the user is prompted that the resource allocation fails. INCR is an atomic command provided by Redis. By treating Redis as an "atomic calculator", the number corresponding to a key is incremented by 1 using the INCR command, and the entire operation is single-threaded and non-interruptible, so no matter how many clients execute simultaneously, there will be no "read-modify-write" conflict. HGET is one of the Redis hash table commands, and the full spelling is "HGET key field". It is used to get the value of field from hash table key.

[0089] The core logic of the Hash data structure in Redis is as follows: Redis Hash is a three-layer storage structure of "key-field-value", and a key corresponds to a set of "field-value" key-value pairs, which can realize the aggregated storage and precise operation of the same type of data. "key" is the top-level unique identifier of data in Redis, which is used to distinguish data of different types and in different scenarios. In "key=user:count: resource allocation task ID", the prefix "user:count:" is a semantic naming specification defined by the developer, which directly indicates the core use of this Redis key - to store "user's resource allocation count". This naming method can quickly distinguish other types of data (such as "user:blacklist:" for risk control blacklist and "resource:prob:" for resource probability), facilitating system maintenance and data troubleshooting. The suffix "resource allocation task ID" is used to locate the specific task. "Resource allocation task ID" is a dynamic variable corresponding to the "task_id" field of the total inventory table (bd_resource_info) and the period inventory table (bd_resource_stat), and its function is to bind "user allocation count" with "specific task": the user count of different resource allocation tasks (such as "618 e-commerce coupon allocation task" and "enterprise cloud server scheduling task") needs to be stored separately to avoid data confusion. "field = user ID" is used to locate the allocation count of "a user" under the current task. "field" is a two-level unique identifier in the Redis Hash structure that belongs to the key, which is used to accurately locate the allocation count data of "a single user" in the "user count set of the same task".

[0090] 3.4) The fourth layer: through IP resolution to obtain the user's geographic location, and match with the resource deployment area whitelist, if the user's geographic location is not in the whitelist, then intercept the resource request.

[0091] The fourth layer of the five-layer risk control mechanism is regional restriction, which implements geographic location verification according to resource configuration, and prompts the user that the resource allocation fails if the user's geographic location does not meet the resource use area. The geographic fence checking mechanism realizes the regional deployment control of resources through IP precise resolution, and the specific method is as follows.

[0092] First, from HttpServletRequest to determine whether the X-Forwarded-For is empty, if not empty through Proxy-Client-IP extraction client IP address, the ip2region.xdb file is loaded into memory through Memory-Mapped File mode, the IP address is converted to 32-bit integer IP_int, using binary search algorithm in the index area positioning IP_int interval. Find the matching interval, according to the pointer offset to locate the data area, read 4 bytes of data block pointer from the data area, get the "country | province | city | operator" structured data. Subsequently, query the loading of the area whitelist allowed to participate in the province-city two-level accurate matching using streaming processing. When the user's location is not in the permitted range, the resource allocation process is immediately blocked and the user is prompted that the resource allocation fails. Through Redis cache optimization, the time consumption of regional check is controlled within 5ms. Also, by modifying the delivery area in the database, Redis can be updated without restarting the service.

[0093] Wherein "HttpServletRequest" is an interface in Java Servlet specification, representing an HTTP request, used to provide request line, request header, parameter, cookie, body, remote IP and all other information related to the request. "X-Forwarded-For (XFF)" is an HTTP extension header field, used when the user → proxy / load balancing → server, the real user IP will be appended to this header by the proxy, in the format of "X-Forwarded-For: Real IP, Proxy1 IP, Proxy2 IP"; among them, the address before the first comma is the original client IP, and the rest are intermediate proxies. "Proxy-Client-IP" is another non-standard but old generation of proxy request header, similar to X-Forwarded-For, only saves one IP, without a chain list. The ip2region.xdb file is an "IP→geographic location" database file published by the open source project ip2region, with the internal structure of "header + index area (ordered IP interval record) + data area (country | region | province | city | operator text)". Memory-Mapped File mode refers to mapping disk files to virtual memory address space, directly reading disk content like accessing arrays, without read( ) system call.

[0094] The above geo-fencing check mechanism adopted by the present application is different from the traditional IP library. By preloading the ip2region.xdb binary data file to the memory and using its built-in vector index algorithm to perform fast binary search on the client IP, the regional information can be returned within milliseconds, realizing efficient matching of more than 100,000 times per second.

[0095] 3.5) The fifth layer: the time window control is implemented by using the token bucket algorithm, the bucket capacity and the token generation rate are set, and if the number of resource requests exceeds the token generation rate, the resource request is intercepted.

[0096] The fifth layer of the five-layer risk control mechanism is the number of resource requests within the time window limit, and the time window is implemented by using the token bucket algorithm (Java Guava library). The specific algorithm process is as follows: assuming that the bucket capacity is 10000, the token generation rate is 5000 per second, that is, 5000 resource requests are allowed per second, and when the number exceeds, the request is rejected. By controlling the high-frequency operation through the time window, by limiting the number of requests per second, if the number exceeds, the user is directly prompted that the resource allocation fails, the impact of high-concurrency traffic on system experience is alleviated, the smooth operation of resource allocation tasks is ensured, and the overall user experience is improved.

[0097] The above five-layer risk control mechanism is independently run and quickly identified, and if any level of verification fails, the resource allocation process is immediately terminated. This layered defense architecture improves the risk interception rate, can quickly filter out requests that do not need to be responded to, while maintaining millisecond-level response speed, and increasing the system's carrying capacity for users.

[0098] Step 4: If the resource request passes the interception verification of the five-layer risk control mechanism, it is judged whether the current resource remaining 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 does not pass the interception verification of the five-layer risk control mechanism, the user is prompted that the resource allocation fails.

[0099] The application adopts a three-level inventory architecture design to achieve fine inventory control. Through the total and partial architecture of "total inventory-time period inventory-Redis real-time inventory", the number of resources is accurately controlled. The main process is to configure the available number of each resource in the total inventory table, to split the resources according to the time period in the time period inventory table, to configure the consumable resource quantity of each time period, and to compare the Redis consumption quantity with the total inventory quantity by real-time statistics of the consumption quantity in Redis.

[0100] The three-level inventory architecture based on total inventory-time period inventory-Redis real-time inventory judges whether the current resource remaining quantity meets the resource request, which specifically includes the following 4.1) to 4.4).

[0101] 4.1) Total inventory control: query the total inventory limit based on resource ID through the row-level lock of MySQL InnoDB engine, to ensure that the resource allocation of all time periods does not exceed the total inventory.

[0102] The first layer of the three-level inventory architecture is a total inventory control layer. The total inventory control layer uses the row-level lock (FOR UPDATE) of the MySQL InnoDB engine to query the inventory quantity of the resource through the resource ID. The InnoDB engine of MySQL is a transactional storage engine; the row-level lock (FOR UPDATE) is used to add a write lock to the found "row" to solve the "overselling / dirty read" problem when concurrent deduction. Specifically, the total inventory of the resource is maintained through the database table bd_resource_info. The key of this layer is to establish a global control benchmark, and all time period allocations will be within the total inventory limit to ensure that there will be no situation of issuing more than the total amount. The database uses the row-level lock mechanism to ensure the accuracy and consistency of the total inventory data in a concurrent environment. The structure of the resource total inventory table is shown in Table 2.

[0103] Table 2 Total inventory table

[0104]

[0105] 4.2) Time period inventory control: The inventory quantity of each time period is configured in the database table, and the automatic closing of the unissued inventory of the historical time period to the current time period is realized through the timer to calculate the "current time period inventory available quantity = current time period inventory configuration quantity + historical time period inventory balance".

[0106] Based on the total inventory control layer, the second layer (time period inventory control layer) of the three-level inventory architecture realizes the fine regulation and control in the time and space dimensions. The time period inventory plan is configured in the bd_resource_stat table, and the resource is controlled according to the time through the configuration content. For example, 800 copies of resources are configured to be issued during the peak time period from 10 am to 12 pm, 600 copies of resources are configured to be issued during the sub-peak time period from 3 pm to 5 pm, and the remaining 600 copies of resources are evenly distributed in the remaining time periods. The system will automatically generate a time period inventory allocation table to record the start and end time of each time period, the number of available copies, and other key parameters.

[0107] When requesting a resource, the system first locates the time period interval to which the current time belongs and queries the inventory balance. The current inventory balance is added to the historical time period inventory balance, and then the current inventory issued is subtracted to obtain the remaining quantity as the current available resource number. The timer is used to calculate the allowed inventory resources of the last time period to automatically transfer to the next time period to avoid resource waste. The structure of the time period inventory table bd_resource_stat is as follows.

[0108] Table 3 Time period inventory table

[0109]

[0110] 4.3) Redis real-time inventory control: after each successful resource distribution, update the real-time resource consumption quantity through the atomic operation of Redis, and calculate the "current resource remaining quantity (current available resource number) = current period inventory available quantity - real-time resource consumption quantity (current distributed quantity)".

[0111] The third layer of the three-level inventory architecture is the real-time verification layer. After each successful resource distribution, the corresponding resource consumption times in Redis are increased by one. In the final query of the current resource total number, the real-time consumption quantity of the current resource in the whole network recorded in Redis is compared. If the current consumption quantity is greater than or equal to the resource total number, it is judged that the inventory is insufficient, and the resource allocation is immediately blocked. Otherwise, continue all subsequent resource allocation processes.

[0112] 4.4) Determine whether the current resource remaining quantity is greater than or equal to 1, if yes, determine that the current resource remaining quantity meets the resource request, if not, determine that the current resource remaining quantity does not meet the resource request.

[0113] For example, when a certain enterprise user initiates a cloud server resource allocation request at 11 o'clock on Friday morning, the system first confirms that it belongs to the "10-12 o'clock" period, checks the 800 inventory quantity configured for this time period, and finds that the last period has a balance of 150, and Redis shows that 90 have been consumed. Therefore, the actual available quantity (current resource remaining quantity) = (800+150)-90=860, if the current resource remaining quantity (860) ≥1, then release, otherwise the resource request fails. This mechanism realizes inventory settlement through time period keys, and ensures data consistency under high concurrency through Redis atomic operations, supporting minute-level precision inventory allocation strategy.

[0114] Step 5: If the current resource remaining quantity meets the resource request, use double distributed locks to control resource allocation concurrency process, distribute target resources to users, and update three-level inventory to complete resource dynamic allocation; if the current resource remaining quantity does not meet the resource request, prompt the user that the resource allocation fails.

[0115] The double distributed locks are realized based on Redis, and the outer user resource allocation task lock and the inner resource inventory lock are created through the SETNX command, and the expiration time of the lock is set. The outer user resource allocation task lock is used to control the concurrent resource request of a single user, and the inner resource inventory lock is used to control the concurrent allocation of the same resource by multiple users. SETNX refers to the "SET if Not eXists" command provided by Redis, which uses the "only create when not exist" feature of SETNX to ensure that only one client can get the lock at the same time, and the expiration time is used to prevent deadlock.

[0116] After the user's resource request is protected by the multi-layer protection, the current time period resource configuration, historical resource balance and current resource consumption are queried, and it is verified that the total number of distribution times is less than the total number of resources; when there is still surplus, the user is given resources, and the consumption number +1 is set, and the distribution of resources is ended.

[0117] The dynamic probability interval matching algorithm of the application realizes the accurate calculation of resource allocation probability in a high concurrency scenario through integer operation conversion of probability intervals and binary matching of random numbers; through the multi-layer protection of the user risk assessment interface, Redis blacklist storage, counter restriction, regional analysis algorithm and time window algorithm in the five-layer risk control mechanism, efficient and accurate identification and interception of abnormal requests are realized; the token bucket algorithm controls the resource request frequency based on "bucket capacity + token generation rate", which relieves the impact of high concurrency traffic; the time period inventory management adopts a three-level technical architecture of "total inventory-time period inventory-Redis real-time inventory", which controls the total inventory through database transactions, realizes the automatic closing of time period inventory through timing tasks, and maintains real-time inventory through Redis atomic operations, supporting minute-level precision dynamic allocation; based on Redis, a double distributed lock is realized, which uses nested distributed lock technology of user resource allocation task lock (outer layer) and resource inventory lock (inner layer), and through SETNX command and expiration time control, global lock competition is avoided.

[0118] The application solves the problems of extensive inventory management, low concurrency performance and difficult expansion of traditional systems through the innovative five-layer risk control system, time period inventory management and double distributed lock mechanism, realizes the technical effects of improving inventory utilization, improving system concurrency and strictly controlling risk control, and provides a full-stack solution with high performance and high availability for high-concurrency resource allocation scenarios (such as e-commerce resource scheduling, cloud service resource distribution, device resource management, public service resource configuration, etc.).

[0119] In an exemplary embodiment, the application also provides a resource dynamic allocation system in a high concurrency scenario, comprising:

[0120] A resource application qualification judgment module is configured to receive a resource request initiated by a user, and judge whether the user has resource application qualification;

[0121] A resource allocation probability condition judgment module is configured to, if the user has resource application qualification, judge whether the resource request meets resource allocation probability conditions based on a dynamic probability interval matching algorithm; if the user does not have resource application qualification, the user is prompted that he / she does not have resource application qualification;

[0122] A multi-dimensional risk control protection module is configured to, if the resource request meets the resource allocation probability conditions, intercept and verify the resource request 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 fails.

[0123] a three-level inventory management module, configured to determine whether the current resource remaining amount meets the resource request based on a three-level inventory architecture of total inventory-time period inventory-Redis real-time inventory if the resource request passes the interception check of the five-layer risk control mechanism; and prompt a user of a resource allocation failure if the resource request does not pass the interception check of the five-layer risk control mechanism.

[0124] a dual-distributed lock concurrent control module, configured to control a resource allocation concurrent process by using a dual-distributed lock if the current resource remaining amount meets the resource request, issue a target resource to the user, and update the three-level inventory to complete resource dynamic allocation; and prompt the user of a resource allocation failure if the current resource remaining amount does not meet the resource request.

[0125] The current inventory resource allocation method / system exposes many problems in the running process, such as being unable to eliminate non-effective requests, relying on MYSQL for resource control, and using a global lock for concurrent control, which leads to lock competition and reduces the overall performance of the system. To this end, the application improves the request processing implementation, introduces a dynamic probability interval matching algorithm, a five-layer risk control mechanism, time period inventory management, and a dual-distributed lock, improves the request screening efficiency, effectively eliminates non-effective requests, effectively improves the system's traffic carrying capacity, increases the system stability, implements resource inventory control, ensures that the problem of over-issuance does not occur, and maximizes the issuance of resources. This mechanism not only improves the flexibility of the system, but also improves the stability of the system and increases the competitiveness in the market situation.

[0126] In an exemplary embodiment, the application also provides an electronic device, which can be a server or a terminal. The electronic device includes a processor, a memory, an input / output interface, and a communication interface. The processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the electronic device is configured to provide 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 an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The input / output interface of the electronic device is used to exchange information between the processor and external devices. The communication interface of the electronic device is used to communicate with external terminals through network connection. The computer program is executed by the processor to implement the resource dynamic allocation method in a high-concurrency scenario.

[0127] In one exemplary embodiment, the application also provides a computer program product comprising a computer program which, when executed by a processor, implements the resource dynamic allocation method in a high concurrency scenario.

[0128] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by computer program instruction related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiment methods. Any reference to memory or other medium in the embodiments provided by the application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0129] 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 for analysis, stored data, displayed data, etc.) involved in the application are information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0130] The technical features of the above embodiments can be combined arbitrarily. In order to make the description simple, all possible combinations of technical features in the above embodiments are not described, but as long as the combination of technical features does not exist contradictory, it should be considered as the scope of the present application.

[0131] The principles and implementation manners of the present application are described herein by using specific examples, and the above examples are only used to help understand the method of the present application and its core idea; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manners and application ranges will have changes. In conclusion, the content of the specification should not be understood as a limitation of the present 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. The step of determining whether a resource request meets the resource allocation probability conditions based on a dynamic probability interval matching algorithm specifically includes: A probability baseline value is set, the allocation probability of each resource is converted into an integer, and the probability interval corresponding to each resource is calculated. After receiving a resource request initiated by a user and determining that the user is eligible to apply for the resource, a random number is generated within the numerical interval corresponding to the probability baseline value. The random number is then matched with the probability interval using a binary search method to determine whether the resource request matches the target resource. If the resource request matches the target resource, it is determined that the resource request meets the resource allocation probability condition. If the resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability condition, and the user is prompted that the resource allocation has failed. 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.

2. The method for dynamic resource allocation in high-concurrency scenarios according to claim 1, 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.

3. The method for dynamic resource allocation in high-concurrency scenarios according to claim 1, 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.

4. The method for dynamic resource allocation in high-concurrency scenarios according to claim 3, 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.

5. The method for dynamic resource allocation in high-concurrency scenarios according to claim 4, 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.

6. 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 step of determining whether a resource request meets the resource allocation probability conditions based on a dynamic probability interval matching algorithm specifically includes: A probability baseline value is set, the allocation probability of each resource is converted into an integer, and the probability interval corresponding to each resource is calculated. After receiving a resource request initiated by a user and determining that the user is eligible to apply for the resource, a random number is generated within the numerical interval corresponding to the probability baseline value. The random number is then matched with the probability interval using a binary search method to determine whether the resource request matches the target resource. If the resource request matches the target resource, it is determined that the resource request meets the resource allocation probability condition. If the resource request does not match the target resource, it is determined that the resource request does not meet the resource allocation probability condition, and the user is prompted that the resource allocation has failed. 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.

7. 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 5.

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

9. 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 5.

Images