User allocation method and device based on a bucket queue, equipment and storage medium
By using a user allocation method based on a pooled queue, and by filtering and batch allocating user data using policy rules, the problems of lock contention and resource exhaustion in high-concurrency scenarios are solved, thereby improving the processing performance and response time of the user allocation system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN LEXIN SOFTWARE TECH CO LTD
- Filing Date
- 2026-03-17
- Publication Date
- 2026-06-30
AI Technical Summary
The existing user allocation system suffers from performance degradation in high-concurrency scenarios, and issues such as lock contention and resource exhaustion exist.
The user allocation method based on the pool queue is adopted. Target user data records are filtered through pre-configured policy rules, customer group identifiers are added and stored in the target pool queue, and the target pool counter is used to monitor and extract and allocate data in batches when the preset allocation trigger threshold is reached, thereby reducing high-frequency database operations.
It effectively alleviates lock contention and resource exhaustion issues, improves system processing performance and throughput in high-concurrency scenarios, and reduces system response time.
Smart Images
Figure CN122309138A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing technology, and in particular to a user allocation method, apparatus, device, and storage medium based on a pooled queue. Background Technology
[0002] In business scenarios such as internet marketing, customer acquisition, and customer service, user allocation systems are responsible for accurately distributing user data records to the corresponding business systems for processing. Existing technologies typically employ a real-time allocation model, meaning that the allocation operation is performed immediately after the user data record is obtained. While this processing mechanism can achieve a relatively fast single allocation response, it suffers from significant system stability defects when faced with sudden high-concurrency allocation demands.
[0003] Specifically, when the user allocation system encounters a surge of user data records within a short period, the real-time allocation mechanism requires immediate execution of a series of database operations, including querying, matching, and allocation, for each user data record. This continuously generates high-concurrency data access requests. Due to the lack of an effective buffer control mechanism, this approach easily leads to severe lock contention issues in core data tables, rapidly consuming database connection resources, significantly increasing system response time, and ultimately causing a sharp decline in system processing performance.
[0004] Therefore, how to effectively improve the processing performance of user allocation systems in high-concurrency scenarios has become a technical problem that urgently needs to be solved in this field. Summary of the Invention
[0005] This invention provides a user allocation method, apparatus, device, and storage medium based on a pooled queue to solve the problem of performance degradation in traditional user allocation systems under high-concurrency scenarios.
[0006] Firstly, a user allocation method based on a reservoir queue is provided, the method comprising: Receive multiple raw user data records pushed in real time from the upstream system; wherein each raw user data record is a set containing complete information about a user; According to the pre-configured policy rules, multiple original user data records are filtered to select original user data records that meet the preset allocation conditions as target user data records, and corresponding customer group identifiers are added to the target user data records. Based on the customer group identifier, the target user data records are stored in the corresponding target pool queue, and the target pool counter associated with the customer group identifier is updated synchronously; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue; Determine whether the current value of the target reservoir counter has reached a preset allocation trigger threshold; wherein, the preset allocation trigger threshold is associated with the customer group identifier; When the preset allocation trigger threshold is reached, all target user data records are extracted in batches from the corresponding target pool queue to generate the first target allocation data pool; All target user data records in the first target allocation data pool are automatically allocated to the corresponding business systems for processing.
[0007] Secondly, a user allocation device based on a reservoir queue is provided, the device comprising: The receiving module is used to receive multiple raw user data records pushed in real time by the upstream system; wherein each raw user data record is a set containing complete information of a user; The filtering module is used to filter multiple original user data records according to pre-configured policy rules, so as to select original user data records that meet the preset allocation conditions as target user data records, and add corresponding customer group identifiers to the target user data records. The storage module is used to store the target user data records into the corresponding target pool queue based on the customer group identifier, and synchronously update the target pool counter associated with the customer group identifier; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue; The first judgment module is used to determine whether the current value of the target reservoir counter has reached the preset allocation trigger threshold; wherein, the preset allocation trigger threshold is associated with the customer group identifier; The first generation module is used to extract all target user data records in batches from the corresponding target pool queue when the preset allocation trigger threshold is reached, and generate the first target allocation data pool. The first allocation module is used to automatically allocate all target user data records in the first target allocation data pool to the corresponding business system for processing.
[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the above-described user allocation method based on a pool queue.
[0009] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described user allocation method based on a pool queue.
[0010] In the aforementioned user allocation method, apparatus, device, and storage medium based on a pooled queue, firstly, after receiving multiple raw user data records pushed in real time from the upstream system, the records are filtered according to pre-configured policy rules to select target user data records that meet preset allocation conditions and add corresponding customer group identifiers to them. This process reduces invalid database operations in subsequent allocation stages by eliminating invalid data records that do not meet the allocation conditions; simultaneously, by introducing customer group identifiers, hierarchical classification and feature grouping of user data records are achieved, providing a clear rule basis for subsequent accurate buffering and differentiated allocation. Secondly, based on customer group identifiers, target user data records are stored in the corresponding target storage pool queue. This target storage pool queue serves as the core buffer layer of the system, handling the massive user data record input pushed from upstream in high-concurrency scenarios. It enables batch temporary storage and orderly release of data without directly triggering the downstream allocation process, effectively avoiding continuously generated high-concurrency data access requests. Simultaneously, by synchronously updating the target storage pool counter associated with the customer group identifier, the current number of target user data records in the corresponding target storage pool queue is accurately recorded, providing a real-time, quantitative basis for triggering allocation. Furthermore, the current value of the target storage pool counter is monitored. When it is determined that it has reached the preset allocation trigger threshold associated with the corresponding customer group identifier, all target user data records are extracted in batches from the corresponding target storage pool queue to generate the first target allocation data pool. This batch extraction mechanism transforms the high-frequency database operations triggered frequently by a single record in the traditional real-time allocation mode into low-frequency batch transaction processing. This not only reduces the number of database accesses in the "query-match-allocation" process but also effectively alleviates the lock contention problem of the core data table and reduces the occupation of database connection resources. Finally, all target user data records in the first target allocation data pool are automatically assigned to the corresponding business systems for processing, reducing the system load caused by invalid operations. Through the synergistic effect of the above steps, this solution effectively solves the lock contention and resource exhaustion problems in the traditional model, shortens the system response time, and improves the processing performance of the user allocation system in high-concurrency scenarios. Attached Figure Description
[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 This is a flowchart of a user allocation method based on a pool queue in one embodiment of the present invention; Figure 2This is another flowchart of a user allocation method based on a reservoir queue in one embodiment of the present invention; Figure 3 This is another flowchart of a user allocation method based on a reservoir queue in one embodiment of the present invention; Figure 4 This is another flowchart of a user allocation method based on a reservoir queue in one embodiment of the present invention; Figure 5 This is another flowchart of a user allocation method based on a reservoir queue in one embodiment of the present invention; Figure 6 This is another flowchart of a user allocation method based on a reservoir queue in one embodiment of the present invention; Figure 7 This is a schematic diagram of a user allocation device based on a pool queue in one embodiment of the present invention; Figure 8 This is another schematic diagram of a user allocation device based on a reservoir queue in one embodiment of the present invention; Figure 9 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation
[0013] The technical solutions of the embodiments of the present 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 the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0014] Firstly, such as Figure 1 As shown, a user allocation method based on a pool queue is provided, including the following steps: S101: Receive multiple raw user data records pushed in real time from the upstream system; each raw user data record is a set containing complete information about a user.
[0015] As an example, upstream systems may include, but are not limited to, financial systems, customer relationship management systems, advertising platforms, e-commerce platforms, etc. Each original user data record is a structured data collection containing complete information about a single user (complete user data), typically in formats such as JSON, XML, or Protocol Buffers.
[0016] The complete user information includes, but is not limited to, basic user information and behavioral information. Basic information may include the user's unique identifier, registration time, membership level, customer group affiliation, user tags, and linked mobile phone number; behavioral information may include the most recent active time, login frequency, browsing history, cumulative spending amount, and product preference tags.
[0017] It should be understood that the multiple original user data records in the embodiments of the present invention refer to two or more, and are not limited here.
[0018] S102: Based on the pre-configured policy rules, filter multiple original user data records to select those that meet the preset allocation conditions as target user data records, and add corresponding customer group identifiers to the target user data records.
[0019] As an example, pre-configured policy rules may include user attribute filtering rules and user behavior filtering rules. User attribute filtering rules set filtering conditions based on basic user information; user behavior filtering rules set filtering conditions based on user behavior information.
[0020] During implementation, business personnel can graphically configure the aforementioned policy rules using a policy canvas. The filtering process can be executed in a cascading manner: First, based on user attribute filtering rules, raw user data records that meet the basic conditions are selected as candidate user data records; second, the selected candidate user data records are further filtered based on user behavior filtering rules, ultimately resulting in raw user data records that simultaneously meet all preset allocation conditions, which are then used as target user data records. Further, based on the basic user information contained in the target user data records, their customer group classification is determined, and corresponding customer group identifiers are added to the target user data records according to the customer group classification.
[0021] S103: Based on the customer group identifier, store the target user data record in the corresponding target pool queue, and synchronously update the target pool counter associated with the customer group identifier; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue.
[0022] As an example, the customer group identifier is a feature label that marks the group to which the target user data record belongs, used to distinguish different business scenarios or service strategies; the target pool queue refers to a structured buffer queue divided in the persistence layer (e.g., relational database table) and / or memory layer (e.g., Redis List or Stream) according to the customer group identifier, used to temporarily store target user data records of the same customer group, so as to avoid direct impact on downstream business systems in high-concurrency push scenarios; the target pool counter is a counting tool that is bound to each customer group identifier, used to record the number of target user data records stored in the target pool queue in real time.
[0023] In practical implementation, queue routing can be performed based on the customer group identifier corresponding to the target user data record. For example, the target user data record for "Category A Customer Group" can be written to the "Category A Target Pool Queue". After successfully storing the user data record, a Lua script is executed through Redis to synchronously update the corresponding target pool counter, ensuring the atomicity of list writing and count increment. Taking "Category A Customer Group" as an example, when its target pool counter is initially 10, each time a new target user data record is written, the Lua script automatically executes the INCR (increment by 1) operation, updating its target pool counter to 11, thereby achieving synchronous consistency between data writing and count statistics. This atomic operation relies on the single-threaded nature of Redis, replacing the locking mechanism of traditional databases, which improves counting efficiency and ensures data consistency.
[0024] S104: Determine whether the current value of the target reservoir counter has reached the preset allocation trigger threshold; S105: When the preset allocation trigger threshold is reached, all target user data records are extracted in batches from the corresponding target pool queue to generate the first target allocation data pool.
[0025] As an example, the preset allocation trigger threshold is associated with the customer group identifier, meaning that the preset allocation trigger threshold is a pre-set measurement value or judgment condition based on the customer group classification. For example, for target user data records labeled as "Category A customer group", the preset allocation trigger threshold can be set to "50".
[0026] As an example, a real-time monitoring mechanism continuously determines whether the current value of each target pool counter has reached the preset allocation trigger threshold. When the preset allocation trigger threshold is reached, i.e., when the current value of the target pool counter reaches the preset allocation trigger threshold, all target user data records are extracted in batches from the corresponding target pool queue to generate the first target allocation data pool. Taking "Category A customer group" as an example, when the value of its corresponding target pool counter reaches the preset allocation trigger threshold of 50, the batch allocation process is immediately triggered: First, all 50 target user data records are extracted from the corresponding "Category A target pool queue" at once to generate the first target allocation data pool; then, the corresponding target pool counter is automatically reset to 0, preparing to start a new round of counting cycle. In this way, the high-frequency database read and write of traditional real-time single allocation is transformed into low-frequency batch operations, reducing the database access frequency of "query-match-allocation", alleviating lock contention of core data tables from the root, and reducing database connection resource consumption.
[0027] It's worth noting that the preset allocation trigger threshold can be dynamically adjusted by business personnel through the strategy canvas. For example, during peak business periods, business personnel can temporarily increase the preset allocation trigger threshold for "Category A customers" from 50 to 80 to improve the batch efficiency of a single allocation; while during off-peak periods, they can lower the preset allocation trigger threshold to 30 to increase the allocation frequency. This flexible threshold configuration mechanism can intelligently adjust the allocation strategy according to the actual business load and performance requirements, ensuring both the timeliness of allocation and optimizing the utilization of system resources.
[0028] S106: Automatically allocate all target user data records in the first target allocation data pool to the corresponding business systems for processing.
[0029] As an example, all target user data records with the same customer group identifier in the first target allocation data pool are uniformly allocated to the corresponding business system for processing. For instance, when the first target allocation data pool contains 50 target user data records marked as "Category A customer group," these 50 target user data records are pushed to the corresponding business system in batches for processing according to the preset mapping relationship between customer groups and business systems. This unified routing mechanism based on customer group identifiers ensures that users in the same customer group receive a consistent service experience, and significantly improves system throughput through batch processing, making resource allocation more accurate and efficient.
[0030] In summary, the solution provided by this embodiment of the invention firstly involves filtering multiple raw user data records pushed in real time from the upstream system according to pre-configured policy rules, selecting target user data records that meet preset allocation conditions, and adding corresponding customer group identifiers to them. This process reduces invalid database operations in subsequent allocation stages by eliminating invalid data records that do not meet the allocation conditions. Simultaneously, the introduction of customer group identifiers enables hierarchical classification and feature grouping of user data records, providing a clear rule basis for subsequent precise buffering and differentiated allocation. Secondly, based on the customer group identifiers, the target user data records are stored in the corresponding target pool queue. This target pool queue, as the core buffer layer of the system, is used to handle the massive user data record input pushed from the upstream in high-concurrency scenarios. It can achieve batch temporary storage and orderly release of data without directly triggering the downstream allocation process, thereby effectively avoiding continuously generated high-concurrency data access requests. At the same time, by synchronously updating the target pool counter associated with the customer group identifier, the current number of target user data records in the corresponding target pool queue is accurately recorded, providing a real-time, quantitative basis for triggering allocation. Furthermore, the current value of the target pool counter is monitored. When it is determined that the value has reached the preset allocation trigger threshold associated with the corresponding customer group identifier, all target user data records are extracted in batches from the corresponding target pool queue to generate the first target allocation data pool. This batch extraction mechanism transforms the high-frequency database operations triggered frequently by a single record in the traditional real-time allocation mode into low-frequency batch transaction processing. This not only reduces the number of database accesses during the "query-match-allocation" process but also effectively alleviates the lock contention problem of the core data table and reduces the occupation of database connection resources. Finally, all target user data records in the first target allocation data pool are automatically allocated to the corresponding business systems for processing, reducing the system load caused by invalid operations. Through the synergistic effect of the above steps, this solution effectively solves the lock contention and resource exhaustion problems in the traditional mode, shortens the system response time, and improves the processing performance of the user allocation system in high-concurrency scenarios.
[0031] In one embodiment, such as Figure 2 As shown, in step S102, which involves filtering multiple original user data records according to pre-configured policy rules to select original user data records that meet preset allocation conditions as target user data records, and adding corresponding customer group identifiers to the target user data records, the following steps are included: S121: Based on user attribute filtering rules, perform first-level filtering on the original user data records to select original user data records that meet the preset attribute conditions as candidate user data records. S122: Based on user behavior filtering rules, perform a second level of filtering on the selected candidate user data records to select candidate user data records that meet the preset behavior conditions as target user data records. S123: Determine the customer group category to which the target user data records belong; S124: Based on the customer group classification, query the predefined customer group identifier mapping table to obtain the customer group identifier; whereby the customer group identifier is used to indicate the customer group classification to which the target user belongs; S125: Add the corresponding customer group identifier to the target user data record.
[0032] As an example, for each raw user data record pushed in real time by the upstream system (each raw user data record represents a structured record of a single user), firstly, the raw user data record is subjected to a first-level filter based on the user attribute filtering rules pre-set in the configuration center. This involves verifying each basic information field in the raw user data record (including but not limited to user unique identifier, registration time, membership level, region, and user tags) to determine if it meets the preset attribute conditions. If not, the raw user data record is discarded or included in the non-candidate set. For raw user data records that pass the first-level filter, a second-level filter is performed based on the user behavior filtering rules pre-set in the configuration center. This involves filtering based on aggregated behavior data (including but not limited to recent active time, number of logins in the last N days, number of purchases in the last N days, page views, etc.). The system uses browsing / dwelling behavior and interaction events to determine whether preset behavior conditions are met. Only original user data records that simultaneously meet both user attribute filtering rules and user behavior filtering rules are identified as target user data records. Further, based on the user's basic information contained in the target user data record, the customer group category to which the target user data record belongs is determined (e.g., "high-net-worth clients," "newly registered users," "potential clients," etc.). Subsequently, a predefined customer group identifier mapping table is queried according to the customer group category to obtain the customer group identifier corresponding to that category (wherein, the customer group identifier includes at least a customer group type code and a priority field). Finally, the customer group identifier is appended as a field to the structured record of the target user data record, for example, inserting the field "customer_group_id=VIP001" into the record.
[0033] In this embodiment, a two-level filtering mechanism consisting of user attribute filtering rules and user behavior filtering rules can effectively filter out high-value, highly targeted user data records. By classifying and mapping the target user data records into customer groups, not only is hierarchical data management achieved, but also a clear grouping basis is provided for the subsequent construction of the pool queue and the execution of allocation strategies, thereby improving the allocation accuracy and operational efficiency of the system.
[0034] In one embodiment, such as Figure 3 As shown, in step S103, which involves storing target user data records into the corresponding target pool queue based on the customer group identifier and synchronously updating the target pool counter associated with the customer group identifier, the steps include: S131: Based on the customer group identifier corresponding to the target user data record, query the predefined pool mapping table to determine the corresponding target pool queue and target pool counter; S132: Store the target user data record into the target storage pool queue; S133: After storage is completed, send an atomic increment instruction to the target reservoir counter bound to the customer group identifier to increment the current value of the target reservoir counter by one.
[0035] As an example, the reservoir mapping table refers to a predefined mapping table maintained by the configuration center or persistent storage, used to map customer group identifiers to corresponding target reservoir queue identifiers and target reservoir counters.
[0036] As an example, firstly, based on the customer group identifier corresponding to the target user data record, a predefined pool mapping table is queried to determine the target pool queue and target pool counter corresponding to that customer group identifier. Then, the target user data record is stored in the corresponding target pool queue according to the query results. After completing the storage operation of the target user data record, an atomic increment instruction is sent to the target pool counter bound to that customer group identifier, increasing the current value of the target pool counter by 1. For example, when the target user data record belongs to "Customer Group A", the target user data record is stored in the "Target Pool Queue of Group A", and an INCR operation is performed on the "Target Pool Counter of Group A" by executing a Lua script, increasing the current value from 49 to 50, thereby ensuring the consistency and atomicity of the list storage and count update operations.
[0037] In one embodiment, such as Figure 4 As shown, it also includes the following steps: S107: When the preset allocation trigger threshold is not reached, determine whether the target user data record is the first target user data record stored in the corresponding target pool queue; S108: If it is the first target user data record, send an allocation task message with a preset delay time to the delayed storage pool queue and start a timer; wherein, the preset delay time is a time predetermined according to the customer group classification; S109: When the timer reaches the preset delay time, based on the allocation task message, extract all current target user data records from the corresponding target pool queue and generate a second target allocation data pool; S1010: Automatically allocate all target user data records in the second target allocation data pool to the corresponding business systems for processing.
[0038] As an example, when the current value of the target pool counter has not reached the preset allocation trigger threshold associated with the corresponding customer group identifier, firstly, it is determined whether the target user data record to be stored is the first target user data record stored in the corresponding target pool queue. For example, if there are currently no target user data records in the target pool queue for "Category A customer group", then the newly written target user data record is determined to be the first target user data record. If the determination result is the first target user data record, an allocation task message with a preset delay time is sent to the delayed pool queue, and a timer is started. The preset delay time is a time predetermined according to the customer group classification. For example, the preset delay time for "Category A customer group" can be 10 minutes, and the preset delay time for "Category B customer group" can be 5 minutes. Subsequently, when the timer reaches the preset delay time, based on the allocation task message, all current target user data records are extracted from the corresponding target pool queue to generate a second target allocation data pool. For example, if 30 target user data records are stored in the "Category A target pool queue" during the 10-minute delay, then these 30 target user data records are extracted all at once to generate the second target allocation data pool. Finally, all target user data records in the second target allocation data pool are automatically assigned to the corresponding business systems for processing; for example, the 30 target user data records marked as "Category A customer group" are pushed in batches to the corresponding "Category A business system" for processing. Through the above steps, even if the target pool counter does not reach the preset allocation trigger threshold, the target user data records can still be allocated on a timed basis based on the delay mechanism, ensuring the timeliness and integrity of the allocation, while reducing frequent access to system resources.
[0039] In one embodiment, such as Figure 5 As shown, after starting the timer, the following steps are also included: S108A: Start a timed task according to a preset cycle, and determine whether the timer has reached the preset delay time; S108B: When the preset delay time has not been reached, extract all current target user data records from the corresponding target pool queue as user data records to be allocated, and generate a data pool to be allocated. S108C: Update the status of all pending user data records in the pending data pool to "allocation in progress" and add an optimistic lock.
[0040] As an example, after starting the timer, firstly, a scheduled task is started at a preset period to determine if the timer has reached the preset delay time; for example, the preset period could be checking the timer status every 2 minutes. Secondly, if the timer has not reached the preset delay time, all current target users are extracted from the corresponding target pool queue as user data records to be allocated, and a data pool to be allocated is generated; for example, if the target pool queue for "Category A customer group" currently stores 20 target user data records, these 20 target user data records are extracted all at once to form the data pool to be allocated. Subsequently, the status of all user data records to be allocated in the data pool is updated to "allocated," and an optimistic lock is added to each user data record to ensure the consistency of data status and prevent concurrent conflicts during the allocation process; for example, for the aforementioned 20 target user data records, the status field in their structured records is updated from "allocated" to "allocated," and a corresponding optimistic lock flag is generated for data security control in subsequent batch allocation operations. Through the above steps, even if the timer has not reached the preset delay time, the target user data records can be periodically extracted and locked to ensure that the allocation operation is controllable and concurrently secure, thus preparing for the subsequent formal allocation process.
[0041] In one embodiment, such as Figure 6 As shown, in step S106, all target user data records in the first target allocation data pool are automatically allocated to the corresponding business systems for processing, including the following steps: S161: Determine the customer group identifier corresponding to the first target data pool; S162: Determine the service interface address of the business system corresponding to the customer group identifier based on the predefined customer group system routing table; S163: The first target allocation list is sent to the corresponding business system through the service interface address, so that the business system allocates all target user data records in the first target allocation data pool to the corresponding business tasks for processing according to the preset allocation strategy.
[0042] As an example, firstly, the customer group identifier corresponding to the first target allocation data pool is determined. For example, if the first target allocation data pool contains 50 target user data records marked as "Category A Customer Group", then the customer group identifier of the first target allocation data pool is determined to be "Category A Customer Group". Then, according to a predefined customer group system routing table, the service interface address of the business system corresponding to this customer group identifier is determined. For example, if the predefined routing table specifies "Category A Customer Group → Agent Allocation System → http: / / xxxxxA.api / allocate", then the service interface address of the corresponding business system is obtained. Next, the target user data records in the first target allocation data pool are sent to the corresponding business system through this service interface address, so that the business system allocates all target user data records in the first target allocation data pool to the corresponding business tasks for processing according to a preset allocation strategy.
[0043] Specifically, when the business system is a seat allocation system, the seat allocation system automatically assigns target user data records to idle target seats according to a preset allocation strategy. This includes the following steps: obtaining real-time status information of each business seat in the seat allocation system, including the skill and expertise matching degree of each business seat, the number of tasks currently pending, and the seat resource allocation weight; calculating the suitability score for each business seat to process target user data records based on the real-time status information; sorting each business seat according to the suitability score, and then, based on the sorting result, sequentially assigning the target user data records in the target allocation data pool to the corresponding business seats for processing. For example, assuming the first target allocation data pool contains 50 target user data records labeled "Category A customer group," when it is determined that the business system corresponding to this customer group is a seat allocation system, the seat allocation system will automatically assign these 50 target user data records to idle seats for processing based on the real-time status information of each business seat.
[0044] In one embodiment, to achieve real-time monitoring of target user data records in the target storage pool queue and the business system, the following steps are further included: querying the target storage pool counter associated with the target storage pool queue in real time using a pre-built Lua script to obtain the number of target user data records currently stored in the target storage pool queue; obtaining the allocation and processing status data of each target user data record in the business system; integrating the current value of the target storage pool counter with the allocation status data in the business system to generate a multi-dimensional data display chart; and visually presenting the real-time storage quantity of each target user data record in the target storage pool queue and its allocation and processing progress in the business system through the data display chart. Through the above monitoring mechanism, business personnel can grasp the status of each target user data record in the entire allocation chain in real time, ensuring the efficiency and controllability of the entire allocation process.
[0045] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0046] Secondly, a user allocation device based on a user pool queue is provided, which corresponds one-to-one with the user allocation method based on a user pool queue in the above embodiments. For example... Figure 7 As shown, the user allocation device based on the pool queue includes a receiving module 201, a filtering module 202, a storage module 203, a first judgment module 204, a first generation module 205, and a first allocation module 206. Detailed descriptions of each functional module are as follows: The receiving module 201 is used to receive multiple raw user data records pushed in real time by the upstream system; wherein each raw user data record is a set containing complete information of a user; The filtering module 202 is used to filter multiple original user data records according to pre-configured policy rules, so as to select original user data records that meet the preset allocation conditions as target user data records, and add corresponding customer group identifiers to the target user data records. The storage module 203 is used to store the target user data records into the corresponding target pool queue based on the customer group identifier, and synchronously update the target pool counter associated with the customer group identifier; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue; The first judgment module 204 is used to determine whether the current value of the target storage tank counter has reached the preset allocation trigger threshold; wherein, the preset allocation trigger threshold is associated with the customer group identifier; The first generation module 205 is used to extract all target user data records in batches from the corresponding target pool queue when the preset allocation trigger threshold is reached, and generate the first target allocation data pool. The first allocation module 206 is used to automatically allocate all target user data records in the first target allocation data pool to the corresponding business system for processing.
[0047] In one embodiment, the pre-configured policy rules include user attribute filtering rules and user behavior filtering rules; The user attribute filtering rule is a filtering condition set based on the user's basic information, and the user behavior filtering rule is a filtering condition set based on the user's behavior information.
[0048] In one embodiment, the filtering module 202 is further configured to: Based on the user attribute filtering rules, a first-level filtering is performed on multiple original user data records to select original user data records that meet the preset attribute conditions as candidate user data records. Based on the user behavior filtering rules, the selected candidate user data records are subjected to a second level of filtering to select candidate user data records that meet the preset behavior conditions as target user data records. Determine the customer group category to which the target user data records belong; Based on the customer group classification, a predefined customer group identifier mapping table is queried to obtain the customer group identifier; wherein, the customer group identifier is used to indicate the customer group classification to which the target user belongs; And add corresponding customer group identifiers to the target user data records.
[0049] In one embodiment, the storage module 203 is further configured to: Based on the customer group identifier corresponding to the target user data record, query the predefined pool mapping table to determine the corresponding target pool queue and target pool counter; The target user data records are stored in the target storage pool queue; After storage is completed, an atomic increment instruction is sent to the target reservoir counter bound to the customer group identifier to increment the current value of the target reservoir counter by one.
[0050] In one embodiment, such as Figure 8 As shown, the user allocation device further includes: The second judgment module 207 is used to determine whether the target user data record is the first target user data record stored in the corresponding target pool queue when the preset allocation trigger threshold is not reached. The sending module 208 is used to send an allocation task message with a preset delay time to the delayed storage pool queue if it is the first data record of the target user, and start a timer; wherein the preset delay time is a time predetermined according to the customer group classification. The second generation module 209 is used to extract all current target user data records from the corresponding target pool queue based on the allocation task message when the timer reaches the preset delay time, and generate a second target allocation data pool. The second allocation module 2010 automatically allocates all target user data records in the second target allocation data pool to the corresponding business systems for processing.
[0051] In one embodiment, such as Figure 8 As shown, the user allocation device further includes: The third judgment module 208A is used to start a timed task according to a preset period and determine whether the timer has reached the preset delay time. The third generation module 208B is used to extract all current target user data records from the corresponding target pool queue as user data records to be allocated when the preset delay time has not been reached, and to generate a data pool to be allocated. The update module 208C is used to update the status of all user data records to be allocated in the data pool to be allocated and add an optimistic lock.
[0052] In one embodiment, the first allocation module 206 is further configured to: Determine the customer group identifier corresponding to the first target allocated data pool; Based on the predefined customer group system routing table, determine the service interface address of the business system corresponding to the customer group identifier; The first target allocation list is sent to the corresponding business system through the service interface address, so that the business system automatically allocates all target user data records in the first target allocation data pool to the corresponding business tasks for processing according to the preset allocation strategy.
[0053] Specific limitations regarding the user allocation device based on a pooled queue can be found in the limitations of the user allocation method based on a pooled queue described above, and will not be repeated here. Each module in the aforementioned user allocation device based on a pooled queue can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0054] Thirdly, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data required for executing a pool-based user allocation method. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a pool-based user allocation method.
[0055] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the user allocation method based on a pooled queue as described in the above embodiment, such as steps S101-S1010. To avoid repetition, these steps will not be repeated here. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the user allocation device based on a pooled queue embodiment, such as the functions of the user allocation method based on a pooled queue described in steps S101-S1010. To avoid repetition, these steps will not be repeated here.
[0056] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the user allocation method based on a pooled queue in the above embodiments, such as steps S101-S1010. To avoid repetition, these steps will not be described again here. Alternatively, when executed by a processor, the computer program implements the functions of each module / unit in the above embodiment of the user allocation device based on a pooled queue, such as the functions of the user allocation method based on a pooled queue described in steps S101-S1010. To avoid repetition, these steps will not be described again here. The computer-readable storage medium can be non-volatile or volatile.
[0057] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0058] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0059] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A user allocation method based on a pooled queue, characterized in that, The method includes: Receive multiple raw user data records pushed in real time from the upstream system; wherein each raw user data record is a set containing complete information about a user; According to the pre-configured policy rules, multiple original user data records are filtered to select original user data records that meet the preset allocation conditions as target user data records, and corresponding customer group identifiers are added to the target user data records. Based on the customer group identifier, the target user data records are stored in the corresponding target pool queue, and the target pool counter associated with the customer group identifier is updated synchronously; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue; Determine whether the current value of the target reservoir counter has reached a preset allocation trigger threshold; wherein, the preset allocation trigger threshold is associated with the customer group identifier; When the preset allocation trigger threshold is reached, all target user data records are extracted in batches from the corresponding target pool queue to generate the first target allocation data pool; All target user data records in the first target allocation data pool are automatically allocated to the corresponding business systems for processing.
2. The user allocation method based on a pooled queue as described in claim 1, characterized in that, The pre-configured policy rules include user attribute filtering rules and user behavior filtering rules; The user attribute filtering rule is a filtering condition set based on the user's basic information, and the user behavior filtering rule is a filtering condition set based on the user's behavior information.
3. The user allocation method based on a pooled queue as described in claim 2, characterized in that, The process of filtering multiple original user data records according to pre-configured policy rules to select original user data records that meet preset allocation conditions as target user data records, and adding corresponding customer group identifiers to the target user data records, includes: Based on the user attribute filtering rules, a first-level filtering is performed on multiple original user data records to select original user data records that meet the preset attribute conditions as candidate user data records. Based on the user behavior filtering rules, the selected candidate user data records are subjected to a second level of filtering to select candidate user data records that meet the preset behavior conditions as target user data records. Determine the customer group category to which the target user data records belong; Based on the customer group classification, a predefined customer group identifier mapping table is queried to obtain the customer group identifier; wherein, the customer group identifier is used to indicate the customer group classification to which the target user belongs; And add corresponding customer group identifiers to the target user data records.
4. The user allocation method based on a pooled queue as described in claim 1, characterized in that, The step of storing the target user data record in the corresponding target pool queue based on the customer group identifier, and synchronously updating the target pool counter associated with the customer group identifier, includes: Based on the customer group identifier corresponding to the target user data record, query the predefined pool mapping table to determine the corresponding target pool queue and target pool counter; The target user data records are stored in the target storage pool queue; After storage is completed, an atomic increment instruction is sent to the target reservoir counter bound to the customer group identifier to increment the current value of the target reservoir counter by one.
5. The user allocation method based on a pooled queue as described in claim 1, characterized in that, The method further includes: When the preset allocation trigger threshold is not reached, it is determined whether the target user data record is the first target user data record stored in the corresponding target pool queue; If it is the first data record of the target user, then send an allocation task message with a preset delay time to the delayed storage pool queue and start a timer; wherein, the preset delay time is a time predetermined according to the customer group classification; When the timer reaches the preset delay time, based on the allocation task message, all current target user data records are extracted from the corresponding target pool queue to generate a second target allocation data pool; All target user data records in the second target allocation data pool are automatically allocated to the corresponding business systems for processing.
6. The user allocation method based on a pooled queue as described in claim 5, characterized in that, After starting the timer, the method further includes: A timed task is started according to a preset cycle, and it is determined whether the timer has reached the preset delay time. If the preset delay time has not been reached, all current target user data records are extracted from the corresponding target pool queue as user data records to be allocated, and a data pool to be allocated is generated. Update the status of all user data records to be allocated in the data pool to "allocation in progress" and add an optimistic lock.
7. The user allocation method based on a pooled queue as described in claim 1, characterized in that, The step of automatically allocating all target user data records in the first target allocation data pool to the corresponding business systems for processing includes: Determine the customer group identifier corresponding to the first target data pool; Based on the predefined customer group system routing table, determine the service interface address of the business system corresponding to the customer group identifier; The first target allocation list is sent to the corresponding business system through the service interface address, so that the business system automatically allocates all target user data records in the first target allocation data pool to the corresponding business tasks for processing according to the preset allocation strategy.
8. A user allocation device based on a pooled queue, characterized in that, The device includes: The receiving module is used to receive multiple raw user data records pushed in real time by the upstream system; wherein each raw user data record is a set containing complete information about a user; The filtering module is used to filter multiple original user data records according to pre-configured policy rules, so as to select original user data records that meet the preset allocation conditions as target user data records, and add corresponding customer group identifiers to the target user data records. The storage module is used to store the target user data records into the corresponding target pool queue based on the customer group identifier, and synchronously update the target pool counter associated with the customer group identifier; wherein, the target pool counter is used to record the number of target user data records currently stored in the corresponding target pool queue; The first judgment module is used to determine whether the current value of the target reservoir counter has reached the preset allocation trigger threshold; wherein, the preset allocation trigger threshold is associated with the customer group identifier; The first generation module is used to extract all target user data records in batches from the corresponding target pool queue when the preset allocation trigger threshold is reached, and generate the first target allocation data pool. The first allocation module is used to automatically allocate all target user data records in the first target allocation data pool to the corresponding business system for processing.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the user allocation method based on a pool queue as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the user allocation method based on the pool queue as described in any one of claims 1 to 7.