A high-concurrency resource pre-occupancy and release control method and system

Abstract

The application relates to the technical field of high-concurrency data processing and concurrency control, and provides a high-concurrency resource pre-occupancy and release control method and system, version identification is generated in response to resource changes and is bound with available quantity cache keys, available quantity is deducted in response to allocation requests and an occupancy record with version identification and a valid period is written, a confirmation receiving mark independent of an occupancy state is written in response to a confirmation instruction to represent entering a confirmation link, if the confirmation receiving mark exists, the release is stopped in response to timeout detection, otherwise, if the occupancy record is still in a to-be-confirmed state, version consistency is checked, if the version is consistent, the occupancy record is migrated from the to-be-confirmed state to a released state and the available quantity is recovered, and if the version is inconsistent, only the occupancy record is released without recovery; through the double mechanisms of version identification binding and confirmation receiving mark, cross-version available quantity isolation and concurrent false release blocking are realized, abnormal increase of available quantity after resource configuration changes is avoided, and occupancy records that have entered the confirmation link are prevented from being released by a timeout release thread.

Description

Technical Field

[0001] This invention relates to the field of high-concurrency data processing and concurrency control technology, specifically to a method and system for high-concurrency resource pre-allocation and release control. Background Technology

[0002] Currently, in various high-concurrency resource allocation scenarios (such as ticketing, limited qualification issuance, flexible employment quotas, etc.), a combination of cache deduction and asynchronous database write-in is typically used to handle high-concurrency requests. However, when the attribute configuration of allocable resources or the upper limit of available quantity changes (e.g., resource closure, reopening, or quota adjustment), existing technologies often cannot effectively isolate the available quantity under different version states. Unconfirmed occupancy records from the old version, after timeout release, may have their available quantity restoration operations incorrectly applied to the available quantity cache of the new version, leading to an abnormal increase in the available quantity of the new version—a cross-version available quantity pollution problem. Furthermore, during asynchronous concurrent processing of occupancy confirmation and timeout release, due to the time-consuming confirmation process or message backlog, the timeout release thread may mistakenly release occupancy records that have entered the confirmation process during the gap between the confirmation thread starting processing and the state solidification being completed, causing available quantity dangling or inconsistent allocation results. Therefore, there is an urgent need for a high-concurrency resource pre-occupancy and release control method that can isolate cross-version available quantity pollution and prevent erroneous release in the asynchronous concurrent process.

[0003] In existing timeout release processes, periodic scanning or delayed queues are typically used to check whether records awaiting confirmation have expired. When a record times out, the system directly changes the occupied state to released and unconditionally restores the available value in the cache. This approach does not consider whether the record has entered the confirmation process or whether the resource version corresponding to the occupied record is still valid, resulting in a disconnect between the release operation and the actual state of the current resource.

[0004] Furthermore, in high-concurrency environments, confirmation requests and timeout release requests may arrive almost simultaneously. Without micro-level concurrency control flags, relying solely on macro-level occupancy status in the database for judgment can easily lead to the timeout release thread reading a still-pending-confirmation occupancy status before the confirmation thread has completed its status update. This can incorrectly trigger the release logic, causing records already in the confirmation process to be mistakenly released. Summary of the Invention

[0005] To address the issues of cross-version availability pollution and asynchronous concurrent accidental release in existing technologies, this application proposes a high-concurrency resource pre-allocation and release control method and system. By introducing resource version identifiers and acknowledgment receipt flags, version isolation of availability changes and blocking of concurrent conflicts in the acknowledgment link are achieved, thereby ensuring data consistency and state security in the high-concurrency pre-allocation link.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A high-concurrency resource pre-occupancy and release control method includes: in response to the initialization or configuration change of allocable resources, generating a version identifier and binding an available quantity cache key to the version identifier; in response to a resource allocation request, when the available quantity meets the deduction condition, generating an occupancy record identifier, performing a deduction operation on the available quantity cache key, and writing an occupancy record bound to the version identifier, the occupancy record having a pending confirmation state and a confirmation validity period; in response to a confirmation instruction carrying the occupancy record identifier, writing a confirmation reception flag, the confirmation reception flag being independent of the occupancy state and used to indicate that the confirmation processing link has been entered; in response to the occupancy record timeout, detecting the confirmation reception flag; if it exists, terminating the timeout release process; if it does not exist and is still in a pending confirmation state, verifying the consistency between its version identifier and the currently effective version identifier; if they are consistent, migrating the occupancy record from the pending confirmation state to the released state and performing an available quantity recovery operation on the bound available quantity cache key; if they are inconsistent, migrating the occupancy record to the released state without performing an available quantity recovery operation.

[0007] The above scheme achieves cross-version availability isolation by binding the available quantity cache key to the version identifier and verifying version consistency during timeout release, thus preventing the old version's allocation and release from polluting the new version's available quantity. At the same time, by using an acknowledgment receipt flag independent of the allocation status, the flag is written when the acknowledgment processing link starts, preventing the timeout release thread from mistakenly releasing records that have entered the acknowledgment link. In addition, by limiting the release process to records that are still in the pending acknowledgment state, a defense depth from concurrent interception to status verification is constructed, thereby ensuring the security of concurrent processing logic and data consistency.

[0008] Preferably, the available quantity cache key is determined by the resource identifier and the version identifier.

[0009] The above preferred solution ensures physical isolation of available quantities for different versions at the cache structure level by binding the available quantity cache key with both the resource identifier and the version identifier. This allows the available quantity recovery operation to accurately locate the cache key of the corresponding version, further enhancing the reliability of version isolation.

[0010] Preferably, when performing the timeout release process, if the presence of the confirmation receipt flag is detected, the timeout release process is aborted and the confirmation result is returned.

[0011] The above-mentioned preferred solution distinguishes between the micro-level confirmation receipt marker and the macro-level occupancy status. The micro-level mark is left as soon as the confirmation thread intervenes in the processing, so that the timeout release thread must check the micro-level mark when determining whether to perform the release. This effectively isolates the competition conflict of the asynchronous concurrent link for the same record. At the same time, by returning the confirmation processing result when the release is aborted, the caller can clearly know the current processing status of the record, avoiding the problem of uncertain caller status caused by no response return due to release abort.

[0012] Preferably, the generation trigger conditions for the version identifier include changes to the attribute configuration of the allocatable resource or changes to the available quantity limit; before performing the available quantity recovery operation, it is also necessary to verify whether the allocatable resource is still in an allocatable state, and the available quantity recovery operation is performed only when the allocatable resource is still in an allocatable state; the available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key, and the incremented value does not exceed the available quantity limit of the allocatable resource under the version identifier.

[0013] The above-mentioned preferred scheme clarifies the triggering timing of version changes, ensuring that any configuration changes that affect the fairness of available resource allocation can trigger version isolation. At the same time, by verifying whether the allocatable resources are still in an allocatable state before the recovery operation, it ensures that available resource recovery is only performed when the resources are still allocatable, avoiding the situation where available resources are incorrectly restored when resources are closed or paused. In addition, the upper limit constraint of the recovery operation is limited to prevent available resource overflow under concurrent abnormal conditions, thus ensuring the safety of the total amount of resource allocation.

[0014] Preferably, after writing the confirmation receipt flag, the occupancy record identifier is delivered to the asynchronous solidification queue. The asynchronous solidification program consumes the occupancy record identifier in the asynchronous solidification queue, checks whether the final allocation record already exists based on the unique index of the occupancy record identifier. If it does not exist and the occupancy status of the occupancy record is pending confirmation, the program writes to the final allocation record and updates the occupancy status of the occupancy record to confirmed. If it already exists, the program directly returns a confirmed result. When the confirmation process and the timeout release process compete for the same occupancy record identifier concurrently, the program makes a judgment based on the dual conditions of the occupancy status of the occupancy record and the confirmation receipt flag. If the confirmation receipt flag already exists, the program directly returns a confirmed result.

[0015] The above-mentioned preferred solution decouples the confirmation reception and database write operations through an asynchronous solidified queue, thereby improving the interface response speed. At the same time, based on a unique index and dual condition judgment, it ensures idempotency in asynchronous consumption and concurrent competition scenarios, avoiding duplicate database writes or state confusion.

[0016] Preferably, the occupancy status of the occupancy record can only be migrated along a preset state migration path via atomic condition updates. The preset state migration path is a unidirectional irreversible path, which includes: a pending confirmation state that can migrate to a confirmed or released state; the confirmed and released states are final states, and migration from the final state to other states is not allowed; for repeated processing requests received from occupancy records that are already in the final state, the corresponding existing processing result is directly returned based on the occupancy status of the occupancy record, wherein if the occupancy status of the occupancy record is a confirmed state, a confirmed result is returned; if the occupancy status of the occupancy record is a released state, a released result is returned; when a confirmation processing request and a timeout release processing request concurrently compete for the same occupancy record identifier, if the occupancy record has already migrated from the pending confirmation state to the final state, the subsequent processing requests directly return the corresponding existing processing result based on the final state of the occupancy record, and no further state update or availability recovery operation is performed on the occupancy record.

[0017] The above-mentioned preferred scheme constructs an idempotent control framework at the macroscopic state machine level by limiting the unidirectional irreversible state transition path and the final state mechanism. This ensures that any subsequent concurrent request can only read the result based on the final state and cannot modify the state in reverse, effectively avoiding state overwriting and duplicate operations caused by concurrent conflicts.

[0018] Preferably, an effective deduplication index is constructed based on the user identifier, resource identifier, and version identifier to prevent the same user from holding multiple unconfirmed occupancy records under the same version identifier for the same allocable resource.

[0019] The above preferred solution, by introducing a deduplication index bound to a version identifier, restricts a single user from repeatedly occupying the same version of resources from the user perspective, avoiding the waste caused by multiple occupations due to network retries or concurrent clicks. Moreover, the deduplication index becomes invalid with version updates, so it does not affect users from reapplying for resources in the new version.

[0020] Preferably, the confirmation validity period is dynamically adjusted based on the current request intensity or remaining availability of the allocable resources; wherein, the current request intensity is determined based on the number of resource allocation requests received by the allocable resources within a preset time window, and the remaining availability is determined based on the ratio of the current value of the available quantity cache key to the upper limit of the available quantity of the allocable resources; when the current request intensity exceeds a preset intensity threshold or the ratio of the remaining availability is lower than a preset remaining threshold, the confirmation validity period is shortened; when the current request intensity does not exceed the preset intensity threshold and the ratio of the remaining availability is not lower than the preset remaining threshold, the confirmation validity period is extended.

[0021] The above-mentioned preferred solution dynamically adjusts the confirmation validity period, enabling the rapid release of unconfirmed occupancy to accelerate circulation during periods of intense resource competition, and providing users with more time for confirmation during periods of less intense resource competition, thereby optimizing the efficiency of resource allocation and user experience.

[0022] Preferably, when the atomic deduction operation of the available quantity cache key is successful but the occupancy record writing fails, the occupancy record identifier is not returned, and the available quantity recovery operation is immediately performed on the available quantity cache key. The available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key, the incremented value is equal to the deduction value of the atomic deduction operation, and the incremented value does not exceed the available quantity limit of the allocatable resource under the version identifier, so as to prevent the available quantity from overflowing.

[0023] The above preferred solution compensates for abnormal breakpoints in the asynchronous processing chain by immediately performing an upper limit-constrained undo and restore operation when there is a discrepancy between cache deduction and record writing, thus preventing the loss of available data due to record writing failure.

[0024] Furthermore, this invention also provides a high-concurrency resource pre-allocation and release control system, including a server, a cache storage unit, a database storage unit, and a message queue unit. The server is communicatively connected to the cache storage unit, the database storage unit, and the message queue unit, respectively. The server is internally configured with a resource initialization module, a pre-allocation control module, an acknowledgment receiving module, a state solidification module, a failure recovery module, and an anomaly repair module. Each module works collaboratively to execute any of the above-mentioned high-concurrency resource pre-allocation and release control methods.

[0025] The above system solution provides a complete hardware and software platform for the version isolation and concurrency control methods through the collaborative connection between the server and various storage and message units, ensuring the feasibility of the technical solution in a distributed high-concurrency environment.

[0026] Beneficial effects: 1. This invention binds the available quantity cache key to the version identifier and verifies the consistency between the version identifier carried by the occupation record and the currently effective version identifier when the timeout is released. If the version identifiers are inconsistent, only the record is released without restoring the available quantity of the current version. This cuts off the pollution path of the old version's occupation and release to the new version's available quantity from the version isolation level, avoiding the problem of abnormal increase in available quantity after resource configuration changes.

[0027] 2. This invention introduces a confirmation receipt flag independent of the macroscopic occupancy state. This microscopic flag is written when the confirmation processing link starts, so that the timeout release thread must check the existence of the flag before performing the release. If the flag exists, the release is stopped. If the flag does not exist and the occupancy record is still in the pending confirmation state, the release process is entered. This effectively prevents the timeout release thread from erroneously releasing occupancy records that have entered the confirmation link or have migrated to the final state, and ensures the data consistency of the asynchronous concurrent processing link.

[0028] 3. This invention constructs a dual idempotent control system from micro-marking to macro-state machine by limiting the unidirectional irreversible migration path and final state mechanism of the occupied state, combined with unique index and dual condition judgment. This effectively avoids state overwriting, repeated database writing and repeated recovery operations caused by concurrent conflicts, and improves the state security of high-concurrency pre-occupied links. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the high-concurrency resource pre-occupancy and release control system architecture according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall process of the high-concurrency resource pre-occupancy and release control method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the occupancy record state migration path according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the concurrent contention timing of the confirmation process and timeout release process in an embodiment of the present invention; Figure 5 This is a schematic diagram of the timeout release process in a version change scenario according to an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0032] Example 1 like Figure 2As shown, this embodiment provides a high-concurrency resource pre-allocation and release control method. This method constitutes the core closed loop of the entire technical solution. By establishing a dual defense depth of "version identifier binding available quantity" and "acknowledgment receipt flag blocking release," it effectively alleviates the problems of cross-version available quantity pollution and erroneous release of asynchronous concurrent links in high-concurrency scenarios. It should be understood that the following description is illustrative only and not restrictive, intended to provide clear implementation guidance for those skilled in the art, and should not be interpreted as an absolute limitation on the scope of protection.

[0033] In step S100, in response to the initialization or configuration change of allocable resources, a version identifier is generated, and the available quantity cache key is bound to the version identifier.

[0034] Specifically, allocable resources refer to any virtual or physical object in the system that has a limited allocation quota and faces high concurrency requests, such as job openings on a flexible employment platform, performance seats in a ticketing system, and invitation codes in a limited-access qualification system. When the system detects a change in the underlying definition of these resources, it must trigger a version isolation mechanism. Attribute configuration changes include, but are not limited to, resource closure, reopening, and adjustments to access conditions; changes to the available quantity limit include, but are not limited to, increases or decreases in quotas, and expansion or contraction of capacity. A version identifier is a logical stamp used to distinguish different allocable states of a resource. Its specific form can be an incrementing sequence number, a timestamp version, a hash version, or a version identifier formed by combining the resource identifier and the change time. Binding the available quantity cache key to the version identifier has profound physical isolation significance. If the version identifier is not bound, the available quantity of all versions will share the same cache key. When resources already occupied under an older version are released due to timeout, the system will perform an available quantity restoration operation on this shared cache key, resulting in an increase in the available quantity value. However, the resources in effect at this time may already be under a new version (e.g., quotas have been reduced or resources have been shut down). This indiscriminate increase in value will incorrectly inject the available quantity of the old version into the available quantity pool of the new version, forming cross-version pollution and causing a serious data consistency problem due to the abnormal increase in the available quantity of the new version. By binding, the available quantity cache key forms a unique mapping with a specific version at the physical storage level, so that any deduction or restoration operation of available quantity is strictly restricted to the storage space of the corresponding version, blocking the path of cross-version pollution at the root. In addition, the binding of the available quantity cache key to the version identifier is not limited to the method of including the version identifier in the cache key naming structure, and can also be achieved through independent version mapping relationships or other association mechanisms.

[0035] Step S200: In response to the resource allocation request, when the available quantity meets the deduction conditions, an occupation record identifier is generated, a deduction operation is performed on the available quantity cache key, and an occupation record bound to the version identifier is written. The occupation record has a pending confirmation status and a confirmation validity period.

[0036] In this step, the occupancy record identifier is a globally unique serial number used to track the entire lifecycle of a single pre-occupancy request. Its generation algorithm typically combines resource identifier, version identifier, user identifier, timestamp, and random sequence to ensure uniqueness. Upon receiving a request, the system first reads the currently active version identifier and its bound available quantity cache key, determining whether the current value is greater than zero or meets a preset deduction threshold (i.e., deduction condition). The preset deduction threshold can be set according to the anti-overselling security margin requirements of the business scenario, for example, set to an integer multiple of the deduction value to reserve buffer space. After the condition is met, the system uses atomic operation instructions (such as atomic decrement instructions) provided by the caching system to execute the deduction, ensuring that overselling does not occur even under extremely high concurrency. There is a strict temporal relationship between atomic deduction and occupancy record writing: atomic deduction must be executed before occupancy record writing because deduction is the substantive action of available quantity occupancy; only successful deduction qualifies for writing a record. Writing a record is the authentication and persistence of the deduction action. In terms of interaction timing, the system first atomically deducts the available quantity in the cache storage unit, and then immediately writes an occupancy record to the database storage unit, initializing the occupancy status of the record to a pending confirmation state, while assigning a confirmation validity period (e.g., a dynamic time window of 30 to 180 seconds). This caching-then-database timing design avoids interface response delays caused by database row lock contention, and establishes a time benchmark for subsequent two-phase confirmation and timeout compensation by setting the pending confirmation state and validity period.

[0037] In step S300, in response to the confirmation instruction carrying the occupancy record identifier, a confirmation reception flag is written. The confirmation reception flag is independent of the occupancy status and is used to indicate that the confirmation processing link has been entered.

[0038] Specifically, the confirmation receipt flag is a micro-level concurrency control signal, typically existing as a lightweight cache key (e.g., using the occupancy record identifier as the key name and a Boolean flag as the value), and its write speed is extremely fast. It should be noted that the storage medium targeted by the operation of writing the confirmation receipt flag includes, but is not limited to, cache storage units; in other optional embodiments, it can also be written to other storage media with fast write characteristics. This embodiment deliberately distinguishes between the confirmation receipt flag and the occupancy status of the occupancy record, which is the core mechanism for preventing concurrency gap risks. The occupancy status (such as pending confirmation, confirmed, released) is a macro-level, persistent state result stored in the database, and its update requires time-consuming steps such as network transmission, database connection acquisition, and transaction commit; while the confirmation receipt flag is a micro-level, instantaneous concurrency imprint stored in the cache, enabling millisecond-level writes. In concurrent scenarios, after receiving the confirmation command, the confirmation thread needs to go through a series of time-consuming operations such as verification and database status updates before changing the occupancy status to confirmed. During this processing gap, if only the macroscopic occupancy status is relied upon to determine whether a record has been confirmed, the timeout release thread is highly susceptible to reading an occupancy status still pending confirmation at the moment before the confirmation thread has completed updating the database status. This could lead to the erroneous triggering of the release logic, causing records already in the confirmation chain to be released incorrectly. By introducing an confirmation reception flag independent of the occupancy status, the confirmation thread leaves a microscopic imprint in the cache the moment it begins processing. The timeout release thread must check this imprint before executing the release. If the imprint exists, it means that the confirmation thread has intervened, thus preventing erroneous timeout releases at the microscopic level and filling the concurrency gap vulnerability caused by the delay in macroscopic status updates.

[0039] In step S400, in response to the timeout of the occupancy record, a confirmation receipt flag is detected; if it exists, the timeout release process is terminated; if it does not exist and is still in the pending confirmation state, the consistency between its version identifier and the currently effective version identifier is verified; if they are consistent, the occupancy record is moved from the pending confirmation state to the released state, and the available quantity recovery operation is performed on the bound available quantity cache key; if they are inconsistent, the occupancy record is moved to the released state without performing the available quantity recovery operation.

[0040] In the timeout release process, when the system detects that a vacancy record has exceeded its confirmation validity period through a time wheel, delayed queue, or timed scanning mechanism, the timeout release process is triggered. This process first performs a defensive check: checking the existence of a confirmation receipt flag. If the flag exists, it means that although the validity period has expired, the confirmation thread has intervened within the validity period and left a micro-mark. At this time, the record has entered the confirmation processing chain, and the timeout release thread must unconditionally abort the release process, completely handing over processing rights to the confirmation thread to avoid concurrent conflicts. If the flag does not exist and the vacancy record is still in a pending confirmation state, it means that the record has indeed timed out and not been confirmed, and has not yet been migrated to the final state by other concurrent threads, and needs to be released. Even if the confirmation receipt flag does not exist, if the vacancy record has been migrated to a confirmed or released final state by the confirmation thread or the replenishment thread, the release operation should not be repeated. This condition, combined with atomic condition updates, constitutes a double defense. At this point, the system enters the version consistency check branch, which is the key defense against cross-version pollution paths. The system compares the version identifier bound when the vacancy record was created with the currently effective version identifier of the allocatable resource. If the two are consistent, it means that the resource configuration has not changed since the record was created, and the available quantity occupied by the record belongs to the current version. Therefore, the system migrates the occupied record from the pending confirmation state to the released state and performs an available quantity recovery operation on the available quantity cache key bound to the version identifier (e.g., incrementing the cache value by 1 or adding the corresponding deduction value), so that the available quantity returns to the resource pool for subsequent request allocation. If the two are inconsistent, it means that the resource has undergone a version change. In the case of inconsistent versions, the available quantity occupied under the old version no longer belongs to the allocation logic of the new version. At this time, the system only migrates the occupied record to the released state to clean up dirty data, but does not perform an available quantity recovery operation. This "release only, no recovery" strategy effectively blocks the pollution path of injecting additional values ​​into the new version's available quantity pool from the old version's occupied record, ensuring the safety of the new version's available quantity limit and avoiding the risk of abnormal overflow of available quantity after resource changes. In terms of the interaction sequence between the cache and the database, the system first migrates the occupied state in the database, and then performs the available quantity recovery operation in the cache, ensuring strict consistency between the state transition and the available quantity change.

[0041] Example 2 This embodiment, based on the closed loop established in Embodiment 1, further elaborates on the underlying implementation of the resource version isolation and recovery mechanism. It focuses on explaining how the physical structure of the available quantity cache key achieves version isolation, why the triggering logic for version changes must introduce a new version, and how the upper limit constraint of the available quantity recovery operation prevents data overflow under concurrent exceptions.

[0042] Step S401, the available quantity cache key is determined by the resource identifier and the version identifier.

[0043] In the cache storage unit, the naming structure of the available quantity cache key is not determined solely by a single resource identifier, but rather by a concatenation logic of the resource identifier and the version identifier. This concatenation logic can employ various higher-level construction methods, such as delimiter concatenation, hash combination, or prefix-suffix stacking, as long as it ensures that the final generated cache key simultaneously contains both resource and version information. For example, when the resource identifier is J001 and the version identifier is V1, the cache key structure may be a specific string combination containing these two elements, but it should never be limited to a fixed format template. This key name structure, jointly determined by dual identifiers, ensures that the same allocatable resource in different versions is mapped to two completely independent storage nodes in the cache storage unit. Any read or write operation targeting the older version's available quantity cache key cannot physically access the newer version's available quantity cache key, thus strengthening the version isolation effect described in Example 1 from the storage structure level.

[0044] Step S402, the generation triggering conditions for the version identifier include changes to the attribute configuration of the allocable resources or changes to the available quantity limit.

[0045] From the perspective of triggering conditions, attribute configuration changes cover underlying definitional changes affecting resource allocation eligibility, such as resource closure, reopening, and adjustments to admission criteria; changes to the available capacity limit cover parameter changes directly affecting the total allocable amount, such as quota increases or decreases and capacity expansion or contraction. The reason these changes must trigger the generation of a new version is that any of these changes substantially alters the fairness benchmark or availability premise of resource allocation. For example, when the available capacity limit is reduced from 20 to 15, if a new version is not generated, the 5 quotas already occupied under the old version will still be replenished to the currently shared cache key after timeout release, causing the current actual available amount to exceed the 15-quota limit constraint, undermining the seriousness of the configuration change; similarly, when a resource is closed, if a new version is not generated, the timeout release and replenishment of the old version will cause the absurd phenomenon of increased available amount for the closed resource. By triggering a new version, the system logically declares the invalidity of the old version's allocation benchmark, thus decoupling the occupancy records under the old version from the current version both physically and logically.

[0046] Step S403, the available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key, and the incremented value does not exceed the available quantity limit of the allocatable resource under the version identifier.

[0047] At the implementation level, the specific form of the available quantity recovery operation is to increment the value stored in the cache key. The incremented value is usually equal to the decremented value of the initial atomic decrement operation (usually 1 in a typical single-occupancy scenario). However, this embodiment imposes a strict upper limit constraint on this increment operation: the incremented value must never exceed the available quantity limit of the allocatable resource under the corresponding version identifier. This overflow prevention mechanism is a key defense against concurrency anomalies. In a high-concurrency environment, multiple abnormal concurrency paths may lead to repeated recovery: for example, when the confirmation thread and the replenishment thread compete concurrently, if the replenishment thread accidentally triggers the recovery operation because it cannot read the confirmation receipt flag from the cache for a moment, the concurrency control mechanism then allows the confirmation thread to trigger the recovery again after the abnormal interruption; or, in the pre-occupancy cancellation scenario, if the cache decrement is successful but the record write fails, the recovery operation is immediately executed, and at this time, a timeout release thread also attempts to perform recovery on the same record. Without an upper limit constraint, these repeated recovery operations under concurrency anomalies will cause the value of the available quantity cache key to accumulate indefinitely, eventually far exceeding the actual allocatable total, causing serious overselling and data overflow. By introducing an upper limit constraint, even if a concurrent exception occurs and multiple recovery attempts are made, the available quantity will be truncated once it reaches the upper limit of this version. This mathematically guarantees the safe boundary of the available quantity and effectively avoids the risk of overflow.

[0048] Step S404: Before performing the availability recovery operation, it is necessary to verify whether the allocatable resource is still in an allocatable state. The availability recovery operation is performed only when the allocatable resource is still in an allocatable state.

[0049] Furthermore, even if the version consistency check passes (i.e., the version identifier carried by the occupancy record matches the currently effective version identifier), the system still needs to further verify the current configuration status of the allocatable resources before performing the availability recovery operation. This verification occurs after the version consistency check passes but before the availability recovery operation. The verification method is as follows: the system reads the current configuration status of the allocatable resources and determines whether the resources are still in an allocatable state (e.g., whether the resources are still open, whether allocation is still allowed, etc.). If the allocatable resources are still in an allocatable state, it means that the resources still have allocation significance. In this case, the availability recovery operation is performed to return the available resources to the resource pool for subsequent requests. If the allocatable resources are no longer in an allocatable state (e.g., the resources have been closed or paused), even if the version identifier matches, restoring the availability is meaningless—injecting available resources into a closed resource pool not only cannot be used by subsequent requests but may also cause data statistics chaos. In this case, the system only migrates the occupancy record to a released state to clean up dirty data, but does not perform the availability recovery operation. This verification mechanism, together with version consistency verification, forms a collaborative defense: version consistency verification isolates cross-version pollution, while allocable status verification prevents invalid recovery to unallocable resources. Together, they ensure the accuracy and rationality of available resource recovery operations.

[0050] Example 3 This embodiment, based on the version isolation and basic release logic established in Embodiment 1, further elaborates on the complete depth of the confirmation receipt mark to prevent concurrent false releases, focusing on explaining the dual defense system from micro-imprint interception to macro-state locking, as well as the collaborative operation mechanism of asynchronous solidified path and idempotent state transition framework.

[0051] Step S301: When performing timeout release processing, if the confirmation receipt flag is detected, the timeout release processing is stopped and the confirmation processing result is returned.

[0052] As described in Example 1, the occupancy status of the confirmation receive flag and the occupancy record are strictly distinguished as two different levels of concurrent control signals. The confirmation receive flag is stored in the cache as a micro-level concurrent imprint to achieve millisecond-level writing. This embodiment further elaborates on the storage implementation and detection timing details of the confirmation receive flag. In terms of storage structure, the confirmation receive flag uses the occupancy record identifier as the key name and a Boolean flag as the value. Its key name structure is consistent with the occupancy record identifier to ensure unique mapping. The lifecycle of this flag is bound to the confirmation processing window of the occupancy record: when the occupancy record is written, the confirmation receive flag is initialized to not exist; when the confirmation thread receives the confirmation instruction, the flag is atomically written to the cache; when the occupancy record finally migrates to the final state (confirmed or released), the flag can be automatically cleaned up according to the cache key expiration policy, or it can be actively deleted by the system after the final state migration to release cache space. In the detection logic of the timeout release thread, the detection of the confirmation flag takes precedence over the reading of the occupancy status. This priority design ensures that the timeout release thread can immediately stop the release and return the confirmation result when the flag is detected, without having to access the database storage unit to read the occupancy status. This reduces cross-system calls and avoids the risk of misjudgment caused by database status reading delays. Furthermore, there is a close timing relationship between writing the confirmation flag and delivering it to the asynchronous solidification queue: the queue delivery is executed only after the flag is successfully written. If the queue delivery fails, the flag still exists, and the timeout release thread will still be intercepted by the flag. In this case, the system can complete the final solidification by retrying the delivery or downgrading to synchronous database writing, ensuring that the flag's interception effectiveness is not lost due to delivery anomalies.

[0053] Step S302: After writing the confirmation receipt flag, the occupancy record identifier is delivered to the asynchronous solidification queue. The asynchronous solidification program consumes the occupancy record identifier in the asynchronous solidification queue, checks whether the final allocation record already exists based on the unique index of the occupancy record identifier. If it does not exist and the occupancy status of the occupancy record is pending confirmation, the program writes to the final allocation record and updates the occupancy status of the occupancy record to confirmed. If it already exists, the program directly returns the confirmed result. When the confirmation process and the timeout release process compete for the same occupancy record identifier concurrently, the program judges based on the dual conditions of the occupancy status of the occupancy record and the confirmation receipt flag. If the confirmation receipt flag already exists, the program directly returns the confirmed result.

[0054] After writing the confirmation flag, the system does not immediately perform the time-consuming database write operation. Instead, it delivers the occupancy record identifier to an asynchronous persistence queue (e.g., a distributed queue built on a message queue unit). When the asynchronous persistence queue delivery fails (e.g., due to queue capacity saturation or network interruption), the system can use retry delivery or fall back to synchronous database writing to ensure the final persistence of the occupancy record. This queue decoupling design has a significant effect on improving interface throughput: the response time of the confirmation interface is no longer limited by the database write latency; it only needs to complete the lightweight cache flag writing and queue delivery to return, significantly releasing the interface's concurrent processing capabilities. The asynchronous persistence program, as a background consumer, continuously pulls occupancy record identifiers from the asynchronous persistence queue and checks whether the final allocation record already exists in the database storage unit based on the unique index of the identifier. If it does not exist and the occupancy status of the occupancy record is still pending confirmation, the final allocation record is written and the occupancy status is updated to confirmed; if it already exists, the confirmed result is returned directly, avoiding duplicate database writes.

[0055] When the confirmation process and timeout release process concurrently compete for the same occupancy record identifier, the system makes a judgment based on both the occupancy status and the confirmation receipt flag. For example... Figure 4 As shown in the diagram, the following is a detailed description of the competition process between the confirmation thread and the replenishment thread using a sequence diagram: Assume that the occupied record R1 is currently in a pending confirmation state, and its confirmation validity period is about to expire. At time T1, the confirmation thread receives a confirmation instruction for R1 and immediately writes a confirmation receipt flag for R1 into the cache storage unit. At this time, the flag exists. At time T2, the replenishment thread is triggered due to R1's timeout. The replenishment thread first checks the confirmation receipt flag of R1 and finds that the flag already exists. Based on the dual condition judgment logic (state is pending confirmation + flag already exists), the replenishment thread determines that the confirmation thread has intervened, immediately stops the timeout release process, does not perform any state transition or available quantity recovery operation, and directly returns the confirmation processing result (e.g., returns a "confirmation processing" or "confirmed" prompt message). At time T3, the asynchronous persistence program of the confirmation thread consumes R1, checks the database and finds that the final allocation record does not exist and the state is pending confirmation. Therefore, it writes the final allocation record and updates the state to confirmed. Through this dual-condition judgment, even in extreme concurrency scenarios, the replenishment thread can be accurately intercepted by micro-marking, ensuring that records that have entered the confirmation link are not mistakenly released.

[0056] Step S303: The occupancy status of the occupancy record can only be migrated along a preset state migration path via atomic condition updates. The preset state migration path is a unidirectional irreversible path, which includes: a pending confirmation state that can migrate to a confirmed or released state; the confirmed and released states are final states, and migration from the final state to other states is not allowed; for repeated processing requests received from occupancy records that are already in the final state, the corresponding existing processing result is directly returned according to the occupancy status of the occupancy record, wherein if the occupancy status of the occupancy record is a confirmed state, a confirmed result is returned; if the occupancy status of the occupancy record is a released state, a released result is returned; when a confirmation processing request and a timeout release processing request concurrently compete for the same occupancy record identifier, if the occupancy record has already migrated from the pending confirmation state to the final state, the subsequent processing requests directly return the corresponding existing processing result based on the final state of the occupancy record, and no further state update or available quantity recovery operation is performed on the occupancy record.

[0057] This embodiment constructs an idempotent control framework at the macroscopic state machine level by defining a unidirectional, irreversible state transition path and a final state mechanism. For example... Figure 3 As shown, the preset state transition path is strictly limited: the pending confirmation state can only transition unidirectionally to the confirmed or released state. The confirmed and released states are defined as final states, and once a state is entered, it is locked and cannot transition to other states. This unidirectional irreversibility is achieved through atomic condition updates, that is, in database update operations, the prerequisite state condition is strictly limited to the pending confirmation state, ensuring that the update can only succeed if the current state meets the expectations. Any request attempting to transition backward from the final state will fail because the condition is not met.

[0058] For duplicate processing requests received on an already finalized occupancy record, the system directly returns the corresponding existing processing result based on the current occupancy status of the occupancy record, without performing any substantive state updates or availability restoration operations. For example, if the occupancy status is confirmed, the confirmed result is returned directly; if the occupancy status is released, the released result is returned directly. When a confirmation processing request and a timeout release processing request concurrently compete for the same occupancy record identifier, if the occupancy record has already transitioned from the pending confirmation state to the final state (e.g., the confirmation thread completed the state update first, transitioning the state to confirmed), subsequent timeout release processing requests directly return the existing processing result (returning the confirmed result) based on this final state, without performing state updates or availability restoration operations on the occupancy record. This idempotent mechanism of directly returning the final state ensures that any subsequent concurrent request can only read the result based on the final state and cannot modify the state in reverse, effectively avoiding state overwriting and duplicate operations caused by concurrent conflicts. Together with the micro-level confirmation reception flag, it forms a dual defense of "micro-level flag interception + macro-level state locking," effectively improving the state security of high-concurrency pre-occupancy links.

[0059] The aforementioned preset state transition paths are for illustrative purposes only and are not restrictive. In other alternative implementations, depending on the complexity of the business logic, intermediate states such as "anomaly locking" can be introduced into the state transition paths to handle more complex anomaly repair scenarios, as long as the irreversibility of the final state and the idempotent return mechanism are guaranteed.

[0060] Example 4 Based on the pre-occupancy and confirmation steps established in Example 1, this embodiment further expands the peripheral defense mechanism, focusing on explaining three features that enhance system robustness: effective deduplication of pre-occupancy, dynamic confirmation validity period, and pre-occupancy cancellation as a fallback, providing a multi-dimensional security defense for high-concurrency pre-occupancy links.

[0061] Step S201: Construct an effective deduplication index for occupancy based on the user identifier, resource identifier, and version identifier to prevent the same user from holding multiple unconfirmed occupancy records under the same version identifier for the same allocable resource.

[0062] The effective deduplication index is a composite unique constraint structure maintained by the system in the cache storage unit or database storage unit. Its construction logic must simultaneously include three dimensions: user identifier, resource identifier, and version identifier. This embodiment deliberately includes the version identifier in the construction condition of the deduplication index. This is necessary to deal with the deduplication failure scenario caused by resource version changes. If the deduplication index is only constructed by the user identifier and resource identifier without binding the version identifier, when the attribute configuration or available quantity limit of the allocatable resource changes and a new version identifier is generated, the deduplication index under the old version will still continue to be effective. At this time, if the user has a occupancy record that was held in the old version but has expired and been released, its deduplication index may not have been cleaned up in time. As a result, when the user re-initiates a resource allocation request in the new version, it will be incorrectly blocked by the deduplication index of the old version, thereby depriving the user of the legitimate qualification to re-apply in the new version. By binding the version identifier to the deduplication index, a version change means that the old version's deduplication index is physically invalidated. The system only constructs a new deduplication constraint for the currently effective new version identifier, thereby allowing users to re-initiate applications in the new version without being disturbed by the historical occupancy of the old version, ensuring the fairness and flexibility of resource allocation. The specific storage form of a deduplication index can be a specific combination of key names in the cache, or a composite unique index in a database table, as long as it can achieve mutual exclusion verification for the same user under the same resource and version.

[0063] Step S202: The confirmation validity period is dynamically adjusted based on the current request intensity or remaining availability of the allocable resources; wherein, the current request intensity is determined based on the number of resource allocation requests received by the allocable resources within a preset time window, and the remaining availability is determined based on the ratio of the current value of the available quantity cache key to the upper limit of the available quantity of the allocable resources; when the current request intensity exceeds a preset intensity threshold or the ratio of the remaining availability is lower than a preset remaining threshold, the confirmation validity period is shortened; when the current request intensity does not exceed the preset intensity threshold and the ratio of the remaining availability is not lower than the preset remaining threshold, the confirmation validity period is extended.

[0064] The validity period is not a fixed static value, but rather an adaptive time window that is dynamically adjusted based on the intensity of resource competition and the urgency of remaining capacity. The calculation logic for the current request density is as follows: within a preset time window (e.g., a sliding window of the last 10 to 60 seconds), the system counts the total number of resource allocation requests received for the allocatable resource. This number directly reflects the intensity of user competition for that resource. The calculation logic for remaining availability is as follows: the system reads the current value of the available capacity cache key in real time and compares it with the maximum available capacity of the allocatable resource under the current version identifier, obtaining a remaining rate between 0 and 1. This ratio directly reflects the degree of resource scarcity.

[0065] The system presets a high-density threshold and a remaining threshold as decision-making thresholds for dynamic adjustment. The high-density threshold is typically set to 50 to 200 requests per second, and the remaining threshold is typically set to 0.1 to 0.3. When the current request density exceeds the high-density threshold, it indicates intense competition, with many users waiting for available resources to be released; or when the ratio of available resources to remaining resources is lower than the remaining threshold, it indicates that the remaining available resources are extremely scarce. In these two urgent scenarios, the system shortens the confirmation validity period (e.g., from the usual 120 seconds to 30 to 60 seconds). The causal relationship is that shortening the validity period forces users to make confirmation decisions or abandon their requests more quickly, thereby accelerating the turnover efficiency of available resources, preventing scarce resources from being suspended for a long time by hesitant users, and improving the overall resource allocation efficiency and throughput. Conversely, when the request density does not exceed the density threshold and the remaining rate is not lower than the remaining threshold, it indicates that resource contention is mild and available resources are sufficient. In this case, the system extends the confirmation validity period (e.g., to 120 to 180 seconds) to give users more time to think and operate, preventing users from accidentally losing occupied resources due to network latency or slightly slow operation caused by a short validity period, thereby optimizing the user experience. The specific values ​​of the above thresholds and validity periods are for interpretation only and not restrictive. In actual applications, they can be flexibly configured according to the tolerance of different business scenarios.

[0066] Step S203: When the atomic deduction operation of the available quantity cache key is successful but the occupancy record writing fails, the occupancy record identifier is not returned, and the available quantity recovery operation is immediately performed on the available quantity cache key. The available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key. The incremented value is equal to the deduction value of the atomic deduction operation, and the incremented value does not exceed the available quantity limit of the allocatable resource under the version identifier, so as to prevent the available quantity from overflowing.

[0067] In a distributed, high-concurrency environment, the cache storage unit and the database storage unit are two independent physical systems. Operations between them cannot be contained in the same local transaction, thus inevitably leading to the risk of consistency disruption. A successful atomic deduction operation but a failed write of the occupancy record is a typical manifestation of this risk: the available quantity in the cache has been substantially deducted, but the database fails to generate a corresponding occupancy certificate, resulting in the available quantity being left idle, unable to be allocated by other users or reclaimed by the timeout release mechanism (because there is no occupancy record identifier for timeout detection). Faced with this abnormal scenario, this embodiment adopts an immediate reversal fallback strategy: the system does not return an occupancy record identifier to the user (because returning an invalid identifier would cause the subsequent confirmation chain to collapse if the record was not successfully written), but immediately performs an available quantity recovery operation on the available quantity cache key.

[0068] The recovery operation must meet two stringent constraints: First, the added value must be absolutely equal to the deducted value of the atomic deduction operation, typically 1. This is to accurately compensate for dangling available resources and prevent permanent deviations in available resources caused by mismatches between the recovered and deducted values ​​(i.e., the anti-dangling mechanism). Second, the added value must never exceed the available limit of the allocatable resource under the corresponding version identifier. This is to prevent overflow risks under concurrent exceptions (i.e., the overflow prevention mechanism). In high-concurrency environments, extreme race conditions may exist: for example, at the moment the system performs undo recovery, another concurrent request might successfully deduct the available resources of the same cache key, or a timed-out release thread might also be attempting to recover the record. Without an upper limit constraint, the cumulative effect of multiple recovery operations could lead to an infinite accumulation of available resources, far exceeding the actual allocatable total, causing severe overselling. By introducing an upper limit constraint, even if multiple recovery operations occur due to concurrent exceptions, the available resources are truncated once they reach the upper limit of the version, thus mathematically guaranteeing a safe boundary for the available resources and effectively avoiding overflow risks. This upper limit-constrained undo and restore operation follows the same anti-overflow mechanism as the available quantity restore operation during timeout release described in Example 2, and the two logically form a unified defense closed loop.

[0069] Example 5 To more intuitively demonstrate the operational effectiveness and defense mechanism of the present invention's technical solution in a real high-concurrency environment, this embodiment applies the higher-level concepts from the aforementioned embodiments to a complete simulation of a high-concurrency job quota grabbing scenario on a flexible employment platform. This scenario is merely illustrative and not restrictive, intended to help those skilled in the art better understand the collaborative operation mechanism of version isolation and confirmation receipt markers, and should not be interpreted as an absolute limitation on the scope of protection based on the specific business parameters in this embodiment.

[0070] In this scenario, allocable resources are specified as "daily-settlement warehouse sorting positions," the maximum available resources are specified as 20 people, version identifiers are specified as V1 and V2, and user identifiers are specified as worker IDs. The entire simulation process is as follows: Step S501, Job Posting Initialization. An employer posts a daily-paid warehouse sorting job on the flexible staffing platform, setting an initial available capacity limit of 20 people. In response to the initialization of allocable resources, the platform server generates a version identifier V1 and binds the available capacity cache key of this allocable resource to the version identifier V1. At this time, the available capacity cache key is jointly determined by the resource identifier (e.g., job identifier J001) and the version identifier V1, and its initial value in the cache storage unit is 20. Simultaneously, the server constructs an initial structure of a valid, deduplicated index based on the user identifier, resource identifier, and version identifier V1, preparing to receive subsequent high-concurrency requests.

[0071] Step S502: Concurrent Application by Multiple Workers. After a job posting, a large number of workers simultaneously initiate resource allocation requests for the same job within a very short period. Upon receiving a resource allocation request for the available resource, the platform server generates an occupancy record identifier for each worker who passes the deduplication check. When the current value of the available quantity cache key meets the deduction condition (i.e., the current value is greater than 0), the server performs a deduction operation on the available quantity cache key. After a successful atomic deduction, the server writes an occupancy record bound to the version identifier V1. This occupancy record has a pending confirmation status and a confirmation validity period. In this scenario, due to intense job application competition, the current request density exceeds a preset density threshold. The system shortens the confirmation validity period to 60 seconds based on the current request density of the available resource. If, during this stage, an extreme anomaly occurs where the atomic deduction operation of the available quantity cache key succeeds but the occupancy record writing fails, the server does not return an occupancy record identifier. Instead, it immediately performs an available quantity recovery operation on the available quantity cache key, increasing the value by the same amount as the deducted value, and ensuring that the increase does not exceed the available quantity limit of 20 under version V1, to prevent available quantity overflow.

[0072] Step S503: Worker confirms within 60 seconds. Within the 60-second confirmation period, a worker initiates a confirmation command via their terminal, carrying an occupancy record identifier. The platform server, upon receiving the confirmation command carrying the occupancy record identifier, writes a confirmation receipt flag. This flag is independent of the occupancy status of the occupancy record and indicates that the occupancy record has entered the confirmation processing chain. After writing the flag, the server delivers the occupancy record identifier to the asynchronous solidification queue. The background asynchronous solidification program consumes this queue and checks whether the final allocation record already exists based on the unique index of the occupancy record identifier. If it does not exist and the occupancy status is pending confirmation, it writes the final allocation record and updates the occupancy status to confirmed. At this point, the occupancy record migrates unidirectionally from the pending confirmation state to the final confirmed state along a preset state migration path, and the quota allocation result is finally solidified.

[0073] Step S504: Worker fails to confirm within 60 seconds. Another worker fails to initiate a confirmation command after the 60-second confirmation validity period expires. The platform server responds to the fact that the occupancy record has exceeded the confirmation validity period and triggers the timeout release process. The server first checks the existence of the confirmation receipt flag. Since the worker has not confirmed, the confirmation receipt flag does not exist and the occupancy record is still in the pending confirmation state. Subsequently, the server verifies the consistency between the version identifier V1 carried by the occupancy record and the currently effective version identifier; at this time, the job position has not changed, and the version identifiers are consistent. The system migrates the occupancy record from the pending confirmation state to the released state and performs an available quantity restoration operation (incrementing the value by 1) on the available quantity cache key bound to the version identifier V1, and the increased value does not exceed the available quantity limit of 20 under version V1. The released quota returns to the resource pool for other workers to register, achieving safe replenishment under the condition of version consistency.

[0074] Step S505: Employer adjusts quota mid-process. During the application rush, due to business adjustments, the employer decides to reduce the available quota for the daily-settlement warehouse sorting position from 20 to 15 people. The platform server responds to the change in the available quota limit by generating a new version identifier V2 and binding the available quota cache key to version identifier V2. At this point, the currently effective version identifier changes to V2, the available quota cache key value corresponding to the new version V2 is initialized to 15, and the available quota cache key of the old version V1 is logically frozen and isolated. Simultaneously, due to the version identifier change, the effective deduplication index under the old version V1 becomes invalid, allowing workers to reapply under the new version V2.

[0075] Step S506: Release timeout records under older version V1. (e.g.) Figure 5 As shown, after the version is changed to V2, the system detects that a occupancy record created under the old version V1 has exceeded its confirmation validity period, and its confirmation receipt flag is missing, and the occupancy record is still in a pending confirmation state. The server verifies the consistency between the version identifier V1 carried by the occupancy record and the currently effective version identifier V2, and finds that they are inconsistent. This scenario falls within the coverage of the condition "if the version identifiers are inconsistent". At this time, the system only migrates the occupancy record from the pending confirmation state to the released state to clean up the dirty data, without performing an available capacity restoration operation. This "release only, no restoration" strategy is consistent with the version consistency verification mechanism described in Example 1, ensuring the security of the available capacity limit of 15 people under the new version V2. Although this example uses quota reduction as an example, if the employer increases the quota or closes and restarts a position, it will also trigger a version identifier change. The timeout release under the old version follows the isolation logic of "release only, no restoration to the new version" to ensure the seriousness of the available capacity limit of each version.

[0076] As can be seen from the above complete deduction, in real high-concurrency job quota application scenarios, this invention effectively isolates the risk of cross-version pollution caused by employers adjusting quotas midway through the physical binding of version identifiers and version consistency verification during release; it effectively prevents erroneous release when the confirmation thread and the replenishment thread compete concurrently by micro-blocking the confirmation and receipt markers; and it further enhances the robustness of the system under extreme high concurrency and abnormal network conditions through multiple perimeter defenses such as deduplication indexing, dynamic validity period, and pre-occupancy cancellation as a fallback, thus achieving data consistency and state security in the resource allocation link.

[0077] Example 6 like Figure 1 As shown, this embodiment provides a high-concurrency resource pre-allocation and release control system. This system provides a complete hardware and software runtime environment for the high-concurrency resource pre-allocation and release control methods described in the foregoing embodiments, ensuring the feasibility of the technical solution in a distributed high-concurrency environment. The system architecture described below is illustrative only and not restrictive, intended to provide clear physical deployment guidance for those skilled in the art, and should not be interpreted as an absolute limitation on the scope of protection by interpreting the specific module divisions or connection methods in the embodiments.

[0078] The high-concurrency resource pre-allocation and release control system includes a server, a cache storage unit, a database storage unit, and a message queue unit. The server is communicatively connected to the cache storage unit, the database storage unit, and the message queue unit, respectively. The server is internally configured with a resource initialization module, a pre-allocation control module, an acknowledgment receiving module, a state solidification module, a failure recovery module, and an anomaly repair module. Each module works in concert to execute the aforementioned high-concurrency resource pre-allocation and release control method.

[0079] At the physical deployment level, servers, as core computing nodes, typically consist of high-performance multi-core processors, large-capacity memory, and redundant power supplies, connected to network interface cards via high-speed internal buses. Externally, servers establish communication connections with cache storage units, database storage units, and message queue units through standard network interfaces (such as Ethernet or Fibre Channel interfaces). Cache storage units are typically deployed as independent distributed cache clusters (e.g., clusters built on in-memory databases), interacting with the server via cache communication protocols for millisecond-level data exchange, specifically designed to handle high-frequency read and write operations. Database storage units are typically deployed as relational database clusters (e.g., clusters built on a master-slave architecture), interacting with the server via database connection protocols, responsible for persistent storage and transaction consistency guarantees. Message queue units are typically deployed as distributed message middleware (e.g., clusters built on a publish-subscribe model), interacting with the server via message communication protocols, responsible for asynchronous decoupling and traffic shaping.

[0080] At the logical function level, to enhance the sense of presence and execution precision, the server can be further divided into multiple collaboratively operating software modules. The resource initialization module is responsible for responding to the initialization or configuration changes of allocable resources, generating a version identifier, and instructing the cache storage unit to bind the available quantity cache key of the allocable resource to the version identifier. The pre-occupancy control module is responsible for responding to a resource allocation request for the allocable resource, generating an occupancy record identifier, and, when determining that the current value of the available quantity cache key meets the deduction condition, instructing the cache storage unit to perform a deduction operation on the available quantity cache key, and subsequently instructing the database storage unit to write the occupancy record bound to the version identifier. This occupancy record has a pending confirmation status and a confirmation validity period. Simultaneously, the pre-occupancy control module is also responsible for instructing the cache storage unit or database storage unit to construct an effective occupancy deduplication index based on the user identifier, resource identifier, and version identifier, preventing the same user from simultaneously holding multiple unconfirmed occupancy records under the same version identifier for the same allocable resource; and dynamically adjusting the confirmation validity period based on the current request intensity or remaining available quantity of the allocable resource. The confirmation receiving module is responsible for responding to the received confirmation instruction carrying the occupancy record identifier by instructing the cache storage unit to write a confirmation receiving flag. This flag is independent of the occupancy status of the occupancy record and is used to indicate that the occupancy record has entered the confirmation processing chain. After writing the flag, the module delivers the occupancy record identifier to the asynchronous persistence queue carried by the message queue unit. The status persistence module, acting as a background consumer, is responsible for consuming the occupancy record identifier from the message queue unit. Based on the unique index of the occupancy record identifier, it checks whether the final allocation record already exists in the database storage unit. If it does not exist and the occupancy status of the occupancy record is pending confirmation, it writes the final allocation record and updates the occupancy status of the occupancy record to confirmed. If it already exists, it directly returns a confirmed result. The failure recovery module is responsible for responding to situations where the occupied record exceeds the confirmation validity period. It instructs the cache storage unit to check the existence of the confirmation receipt flag. If the confirmation receipt flag exists, the timeout release process is terminated. If the confirmation receipt flag does not exist and the occupied record is still in a pending confirmation state, the module verifies the consistency between the version identifier carried by the occupied record in the database storage unit and the currently effective version identifier. If the version identifiers match, the occupied record is moved from the pending confirmation state to the released state, and the cache storage unit is instructed to perform an availability recovery operation on the availability cache key bound to the version identifier. If the version identifiers do not match, the occupied record is only moved to the released state without performing an availability recovery operation. When performing the availability recovery operation, the failure recovery module ensures that the increased value does not exceed the available limit of the allocatable resource under the version identifier.The anomaly repair module is responsible for not returning the occupation record identifier when the atomic deduction operation of the available quantity cache key is successful but the occupancy record writing fails. Instead, it immediately instructs the cache storage unit to perform an available quantity recovery operation on the available quantity cache key. The increased value is equal to the deduction value of the atomic deduction operation, and the increased value does not exceed the available quantity limit of the allocatable resource under the version identifier, so as to prevent available quantity overflow.

[0081] Through the refined division of the internal modules of the server and the collaborative connection of various external storage and message units, the system architecture of this embodiment precisely maps the core logic in the aforementioned method essentials, such as version isolation, confirmation of receipt to prevent accidental release due to concurrency, asynchronous persistence, idempotent state migration, effective occupancy and deduplication, dynamic validity period adjustment and pre-occupancy cancellation fallback, to specific hardware interactions and software execution paths. This constructs a complete closed loop from micro-level concurrency control to macro-level data persistence, providing reliable structural support and functional guarantees for the implementation of high-concurrency resource pre-occupancy and release control methods in a distributed environment.

[0082] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. The version identifier generation algorithm, the concatenation logic of the available quantity cache key, the dynamic adjustment threshold and duration range for confirming validity period, the specific technical selection of various storage media and middleware, and the intermediate states that may be introduced in the state transition path described in the foregoing embodiments are all merely illustrative examples provided to help those skilled in the art understand the technical solution of the present invention, and are not absolute limitations on the scope of protection of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention, such as using other forms of version stamps, other concurrent control stamp writing media, or other equivalent idempotent state machine models, should all be covered within the scope of protection of the present invention.

Claims

1. A method for controlling the pre-occupancy and release of high-concurrency resources, characterized in that, include: In response to the initialization or configuration change of allocable resources, a version identifier is generated, and the available quantity cache key is bound to the version identifier; In response to a resource allocation request, when the available quantity meets the deduction conditions, an occupation record identifier is generated, a deduction operation is performed on the available quantity cache key, and an occupation record bound to the version identifier is written. The occupation record has a pending confirmation status and a confirmation validity period. In response to the confirmation instruction carrying the occupancy record identifier, a confirmation reception flag is written. The confirmation reception flag is independent of the occupancy status and is used to indicate that the confirmation processing link has been entered. In response to the timeout of the occupancy record, a confirmation receipt flag is detected; If it exists, then abort the timeout release process; If it does not exist and is still in the pending confirmation state, then verify the consistency between its version identifier and the currently effective version identifier; if they are consistent, then move the occupied record from the pending confirmation state to the released state, and perform an available quantity recovery operation on the bound available quantity cache key. If there is a discrepancy, the occupied record will be migrated to a released state without performing an available recovery operation.

2. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, The available cache key is determined by the resource identifier and the version identifier.

3. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, If the confirmation receipt flag is detected during the timeout release process, the timeout release process is aborted and the confirmation result is returned.

4. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, The generation trigger conditions for the version identifier include changes to the attribute configuration of the allocable resource or changes to the available quantity limit. Before performing the available quantity recovery operation, it is also necessary to verify whether the allocable resource is still in an allocable state. The available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key, and the incremented value does not exceed the available quantity limit of the allocable resource under the version identifier.

5. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, After writing the confirmation receipt flag, the occupancy record identifier is delivered to the asynchronous solidification queue. The asynchronous solidification program consumes the occupancy record identifier in the asynchronous solidification queue, checks whether the final allocation record already exists based on the unique index of the occupancy record identifier. If it does not exist and the occupancy status of the occupancy record is pending confirmation, it writes to the final allocation record and updates the occupancy status of the occupancy record to confirmed. If it already exists, it directly returns the confirmed result. When the confirmation process and the timeout release process compete for the same occupancy record identifier concurrently, the determination is made based on the dual conditions of the occupancy status of the occupancy record and the confirmation receipt flag. If the confirmation receipt flag already exists, it directly returns the confirmed result.

6. The high-concurrency resource pre-allocation and release control method according to claim 3, characterized in that, The occupancy status of the occupancy record can only be migrated along a preset state migration path through atomic condition updates. The preset state migration path is a unidirectional irreversible path. The preset state migration path includes: the pending confirmation state can be migrated to the confirmed state or the released state. The confirmed state and the released state are final states and migration from the final state to other states is not allowed. For a repeated processing request received for an occupied record that is already in the final state, the corresponding existing processing result is returned directly according to the occupied state of the occupied record. Specifically, if the occupied state of the occupied record is confirmed, a confirmed result is returned; if the occupied state of the occupied record is released, a released result is returned. When a confirmation request and a timeout release request compete for the same occupancy record identifier concurrently, if the occupancy record has already transitioned from the pending confirmation state to the final state, the subsequent processing request will directly return the corresponding existing processing result based on the final state of the occupancy record, and will no longer perform state update or availability recovery operations on the occupancy record.

7. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, An effective deduplication index is constructed based on the user identifier, resource identifier, and version identifier to prevent the same user from holding multiple unconfirmed occupancy records under the same version identifier for the same allocable resource.

8. The high-concurrency resource pre-allocation and release control method according to claim 1, characterized in that, The confirmation validity period is dynamically adjusted based on the current request intensity or remaining availability of the allocable resources; The current request density is determined based on the number of resource allocation requests received by the allocable resources within a preset time window, and the remaining availability is determined based on the ratio of the current value of the availability cache key to the upper limit of the available availability of the allocable resources. When the current request density exceeds a preset density threshold or the ratio of remaining available resources is lower than a preset remaining threshold, the confirmation validity period is shortened; when the current request density does not exceed the preset density threshold and the ratio of remaining available resources is not lower than the preset remaining threshold, the confirmation validity period is extended.

9. The high-concurrency resource pre-allocation and release control method according to claim 2, characterized in that, When the atomic deduction operation of the available quantity cache key is successful but the writing of the occupied record fails, the occupied record identifier is not returned, and the available quantity recovery operation is immediately performed on the available quantity cache key; The available quantity recovery operation is to perform an increment operation on the value of the available quantity cache key. The incremented value is equal to the decremented value of the atomic decrement operation, and the incremented value does not exceed the available quantity limit of the allocatable resource under the version identifier, so as to prevent the available quantity from overflowing.

10. A high-concurrency resource pre-allocation and release control system, comprising a server, a cache storage unit, a database storage unit, and a message queue unit, characterized in that, The server is communicatively connected to the cache storage unit, the database storage unit, and the message queue unit, respectively. The server is internally configured with a resource initialization module, a pre-occupancy control module, an acknowledgment receiving module, a state solidification module, a failure recovery module, and an anomaly repair module. Each module works in concert to execute the high-concurrency resource pre-occupancy and release control method according to any one of claims 1 to 9.

Images