Traffic distribution method and apparatus, terminal device, and storage medium

Abstract

The application is suitable for the computer technical field, and provides a traffic distribution method and device, terminal equipment and storage medium, the method comprises the following steps: in response to a traffic operation request for a target experiment, obtaining time attribute information of the target experiment and state attribute information of a distribution unit, wherein the distribution unit is obtained based on total traffic division, and the state attribute information is determined based on whether the distribution unit has been allocated to any experiment; according to the type of the traffic operation request and the time attribute information of the target experiment, different allocation control logics are executed on the distribution units with different state attribute information. The application can improve the isolation in the experiment traffic distribution process, reduce the risk of cross contamination of observation samples, and avoid the reallocation of user groups caused by the expansion and contraction of experiments.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a traffic allocation method, apparatus, terminal device, and storage medium. Background Technology

[0002] In online experiments of internet products (such as A / B testing), to verify the effectiveness of different strategy versions, platforms typically use traffic allocation mechanisms to distribute user access requests to different experiment groups. A common practice is to divide the total traffic into multiple hash buckets and assign a set of contiguous bucket ranges to each experiment, thereby controlling the traffic share of each experiment.

[0003] When an experiment needs to adjust its traffic scale, the platform dynamically changes the range of hash buckets used by the experiment. For example, after an experiment shrinks, some hash buckets are released, and when other experiments expand, these released hash buckets are directly used. Since the released hash buckets have already carried the user groups of previous experiments, if they are reused improperly, it will cause users to be redistributed between different experiments. This unexpected migration of user groups between different experiments will cause the observation samples of each experiment to overlap and cross-contaminate, destroying the independence of experimental data and affecting the reliability of experimental conclusions.

[0004] Therefore, improving the isolation during the experimental traffic allocation process, reducing the risk of cross-contamination of observation samples, and avoiding the redistribution of user groups due to experimental scaling are issues that need to be considered. Summary of the Invention

[0005] This application provides a traffic allocation method, apparatus, terminal device, and storage medium, which can improve the isolation during the experimental traffic allocation process, reduce the risk of cross-contamination of observation samples, and avoid the redistribution of user groups due to experimental expansion or contraction.

[0006] In a first aspect, embodiments of this application provide a traffic allocation method, including: In response to a traffic operation request for a target experiment, the time attribute information of the target experiment and the status attribute information of the allocation unit are obtained, wherein the allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. Based on the type of the traffic operation request and the time attribute information of the target experiment, differentiated allocation control logic is executed for allocation units with different state attribute information.

[0007] In one possible implementation of the first aspect, the state attribute information of the allocation unit includes a pure idle state that has never been allocated and a historical idle state that has been allocated and released. The step of executing differentiated allocation control logic for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment includes: When the traffic operation request is a traffic expansion request for an existing first experiment, the allocation is selected from the allocation units that are in a clean and idle state, and the use of allocation units that are in a historically idle state is prohibited. When the traffic operation request is a traffic allocation request for a newly created second experiment, allocation is preferentially selected from allocation units that are in a historically idle state, and if the number of allocation units in a historically idle state is insufficient, allocation is supplemented from allocation units that are in a completely idle state.

[0008] In one possible implementation of the first aspect, the time attribute information includes the timestamp of the experiment first obtaining the allocation unit and the release timestamp of the experiment releasing the allocation unit; The prohibition of using allocation units that are in a historically idle state includes: When the timestamp of the first experiment's first acquisition of an allocation unit is earlier than the timestamp of the allocation unit in the historically idle state, the allocation of the historically idle allocation unit to the first experiment is prohibited.

[0009] In one possible implementation of the first aspect, the selection for allocation from allocation units in a purely idle state includes: Allocation units are selected sequentially from the first set of allocation units that are in the pure idle state, according to the order in which each allocation unit is marked as pure idle. The priority selection from allocation units in a historically idle state for allocation includes: Allocation units are selected sequentially from the second set of allocation units that are in a historically idle state, according to the order of their release timestamps.

[0010] In one possible implementation of the first aspect, prior to the response to the traffic operation request for the target experiment, the method further includes: In response to a scaling-down request for an existing third experiment, the status attribute information of the allocation unit released by the third experiment is updated from the used state to the historical idle state, and the release timestamp of the released allocation unit is recorded.

[0011] In one possible implementation of the first aspect, the method further includes: When it is detected that all experiments within the current traffic layer have been taken offline, the status attribute information of all allocation units in the current traffic layer that are in a historical idle state will be uniformly reset to a clean idle state.

[0012] In one possible implementation of the first aspect, prior to the response to the traffic operation request for the target experiment, the method further includes: In response to a user access request for the target experiment, obtain the user identifier carried in the user access request; The salt value of the target experiment is generated based on the random identifier and the experiment version number of the target experiment; A hash calculation is performed based on the salt value and the user identifier, and the range of available allocation units corresponding to the user identifier is determined according to the result of the hash calculation. The step of executing differentiated allocation control logic for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment includes: Within the available allocation units, differentiated allocation control logic is executed for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment.

[0013] Secondly, embodiments of this application provide a flow distribution device, including: The attribute information acquisition module is used to respond to a traffic operation request for a target experiment and acquire the time attribute information of the target experiment and the status attribute information of the allocation unit, wherein the allocation unit is obtained based on the total traffic allocation and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. The traffic allocation module is used to execute differentiated allocation control logic on allocation units with different state attribute information according to the type of the traffic operation request and the time attribute information of the target experiment.

[0014] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the traffic allocation method as described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the traffic allocation method as described in the first aspect above.

[0016] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the traffic allocation method described in the first aspect above.

[0017] In this embodiment, when a traffic operation request for a target experiment is received, the allocation logic is associated with the time characteristics of the experiment and the usage history of the allocation unit by obtaining the time attribute information of the target experiment and the status attribute information of the allocation unit. The allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. Then, according to the type of traffic operation request and the time attribute information of the target experiment, differentiated allocation control logic is executed for allocation units with different status attribute information. This ensures that the allocation units that experiments created at different time stages can use during the scaling up and down process are constrained by the time dimension. This allows for the adaptation of corresponding traffic allocation strategies for different traffic operation scenarios, different time characteristics of experiments, and different usage states of allocation units. This effectively reduces the possibility of incorrect allocation of allocation units during the scaling up and down process, thereby improving the isolation of the experimental traffic allocation process, reducing the risk of sample cross-contamination, and preventing users from being reassigned between different experiments due to improper reuse of allocation units. This ensures the stability of the experimental user group and, in turn, the accuracy and reliability of the experimental data. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the implementation of the traffic allocation method provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a specific implementation of step S102 in the traffic allocation method provided in this application embodiment; Figure 3 This is a flowchart illustrating a specific implementation of orthogonal hash allocation in the traffic allocation method provided in this application embodiment; Figure 4 This is a structural block diagram of the flow distribution device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the terminal device provided in the embodiments of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] By way of example and not limitation, the traffic allocation method provided in this application is applicable to various types of terminal devices that need to perform traffic allocation. Specific terminal devices may include servers, desktop computers, laptops, tablets, Ultra-Mobile Personal Computers (UMPCs), etc. This application does not impose any restrictions on the specific type of terminal device.

[0027] Figure 1 The implementation flow of the traffic allocation method provided in this application embodiment is illustrated. The method flow includes steps S101 to S102. The specific implementation principle of each step is as follows: Step S101: In response to a traffic operation request for a target experiment, obtain the time attribute information of the target experiment and the status attribute information of the allocation unit, wherein the allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment.

[0028] During the operation of the online experimental platform, when traffic adjustment is needed for a specific experiment, the terminal device will receive a traffic operation request for that experiment. The target experiment mentioned above is the experiment that requires the traffic operation, such as a recommendation algorithm test experiment or an interface optimization test experiment on an e-commerce platform. A traffic operation request is an instruction used to trigger traffic allocation or adjustment actions.

[0029] In one possible implementation, traffic operation requests include initial traffic allocation requests when the experiment is created, and scaling up or down requests during the experiment's operation.

[0030] Time attribute information refers to information related to the time characteristics of the target experiment, used to characterize the position or sequence of the target experiment in the time dimension. In one possible implementation, the time attribute information could be the timestamp of the target experiment's first acquisition of an allocation unit, or the time record of the target experiment's most recent traffic adjustment operation. By acquiring the time attribute information, the terminal device can make subsequent allocation decisions based on the temporal order of the experiments.

[0031] An allocation unit is the smallest unit of traffic management pre-divided based on the total traffic space, and its number can be set according to actual needs. As an example, the total traffic can be divided into one thousand allocation units, with each allocation unit corresponding to one-thousandth of the total traffic.

[0032] In one possible implementation, the allocation unit can be implemented in the form of a hash bucket, but this embodiment does not limit the specific implementation form of the allocation unit.

[0033] State attribute information is identification information used to characterize the current state of an allocation unit. State attribute information is determined based on whether the allocation unit has ever been allocated to any experiment. Specifically, if an allocation unit has never been allocated to any experiment after system initialization, its state attribute information can be characterized as "never allocated"; if an allocation unit has been allocated to an experiment, even if the experiment subsequently releases the allocation unit, its state attribute information can be characterized as "allocated and then released" because it was previously occupied. Through this classification method based on usage history, the terminal device can distinguish between allocation units that have never been used and those that have been used and then released, providing a basis for subsequent differentiated allocation control.

[0034] For example, in the experimental platform, Experiment A initially receives one hundred allocation units, whose status attribute information is marked as used. When Experiment A shrinks down and releases fifty of these allocation units, the terminal device does not directly restore these fifty allocation units to their unallocated state. Instead, based on their previously allocated usage history, it updates their status attribute information to a previously allocated and released state, distinguishing them from allocation units that were never allocated after system initialization. When Experiment C needs to expand, the terminal device can accurately identify which allocation units have never been used and which allocation units were previously occupied and released by other experiments by querying the status attribute information of each allocation unit.

[0035] In this embodiment of the application, when a traffic operation request is received, the time dimension information of the target experiment and the spatial dimension and historical usage information of the allocation unit are obtained simultaneously. The time characteristics of the target experiment and the usage history of the allocation unit are clarified. By introducing time attribute information and state attribute information based on usage history, the allocation decision no longer depends solely on the spatial occupancy of the allocation unit, but rather on the dual factors of time dimension and usage history.

[0036] Step S102: Based on the type of the traffic operation request and the time attribute information of the target experiment, execute differentiated allocation control logic for allocation units with different state attribute information.

[0037] After obtaining the time attribute information of the target experiment and the status attribute information of each allocation unit, the terminal device executes an allocation decision. This decision-making process comprehensively considers two dimensions of factors: the type of traffic operation request and the time attribute information of the target experiment. Based on different combinations of these two factors, different allocation processing methods are adopted for allocation units with different status attribute information, rather than applying a uniform allocation rule to all allocation units.

[0038] Traffic operation requests can be categorized into three types: new experiment creation requests, expansion requests, and reduction requests. A new experiment creation request is when the target experiment, having not yet received any allocation units, requests traffic allocation from the terminal device for the first time. A traffic expansion request is when the target experiment, having already received some traffic, needs to increase its traffic allocation. A reduction request is when the target experiment, having already received some traffic, needs to decrease its traffic allocation. Different types of traffic operation requests correspond to different allocation requirements and processing logic. By combining the type of traffic operation request with time attribute information, the terminal device can match the corresponding allocation strategy to different operation scenarios and the time characteristics of the experiment.

[0039] In this embodiment, during the execution of the differentiated allocation control logic, the state attribute information of the allocation unit determines whether the allocation unit can be selected in the current operating scenario. In one possible implementation, allocation units whose state attribute information indicates they have never been allocated can be used to meet the initial allocation requirements of newly created experiments or to expand the capacity of existing experiments. For allocation units whose state attribute information indicates they have been allocated and released, their use is limited by the time dimension; it is necessary to determine whether their use is allowed based on the temporal attribute information of the target experiment and the order in which the allocation unit was released. Through this differentiated control, the set of allocation units available to experiments created or running at different time stages differs, thereby achieving a temporal isolation effect.

[0040] For example, suppose experiment A creates and obtains allocation units at time T1, and experiment C creates and obtains allocation units at time T3, where T1 is earlier than T3. When experiment A shrinks and releases some allocation units, the status attribute information of these released allocation units is updated to the state of having been allocated and released. At this time, if experiment C requests expansion, the terminal device performs differentiated processing on allocation units with different status attribute information based on the time attribute information of experiment C (the time of first obtaining allocation units is T3) and the type of traffic operation request (expansion request). Since experiment C is an existing experiment, and its time attribute is later than the first allocation time of the released allocation units, under the differentiated allocation control logic, the terminal device will not allocate those allocation units that were previously occupied and released by experiment A to experiment C, thereby preventing the user group of experiment A from being reassigned to experiment C and ensuring the independence of each experimental sample.

[0041] In this embodiment, based on the acquisition of both time and state attributes, differentiated allocation control is performed based on the type and time attributes of traffic operation requests. This makes the use of allocation units constrained by the time dimension, thereby improving the isolation in the experimental traffic allocation process, reducing the risk of sample cross-contamination, and ensuring the independence of experimental data and the reliability of conclusions. At the same time, by establishing a differentiated allocation mechanism that coordinates the effects of time and state attributes, fine-grained control over the use of allocation units is achieved. Compared with the approach of using a unified allocation logic for all allocation units, the differentiated allocation control logic can adapt the corresponding allocation strategy according to different operation scenarios and experimental time characteristics, avoiding the problem of user groups migrating across experiments due to indiscriminate reuse of allocation units.

[0042] As one possible implementation of this application, the state attribute information of the allocation unit includes a pure idle state representing that it has never been allocated and a historical idle state representing that it has been allocated and released. A pure idle state refers to a situation where the allocation unit has never been allocated to any experiment since system initialization, or where it has been used but has recovered to a state that can be considered completely new after meeting specific reset conditions. A historical idle state refers to a situation where the allocation unit was previously occupied by an experiment, which released the allocation unit when it was scaled down or taken offline. The allocation unit is currently in an idle state, but because it carried traffic from a previous experiment, it cannot be considered pure idle traffic.

[0043] Figure 2 A specific implementation flow of step S102 in the traffic allocation method provided in this application embodiment is shown below: A1: When the traffic operation request is a traffic expansion request for an existing first experiment, the allocation is selected from the allocation units that are in a clean and idle state, and the use of allocation units that are in a historically idle state is prohibited.

[0044] An existing first experiment refers to an experiment that has been created and running for a period of time, and that has already obtained allocation units and carried corresponding user traffic. A traffic expansion request for an existing first experiment means a desire to increase the number of allocation units occupied by the first experiment, thereby expanding its coverage ratio.

[0045] When a traffic expansion request is received for an existing experiment (Part 1), the allocation rule is limited to selecting allocation units only from those in a completely idle state. Allocation units in a historically idle state, even if idle, are not allowed to be selected. The reason for this is that the existing experiment (Part 1) already has its own user base. If historically idle allocation units that have been used and then released by other experiments were allocated to Part 1, users who participated in other experiments might be brought into Part 1, resulting in users not native to that experiment appearing in Part 1's sample, thus compromising the independence and consistency of the sample. Therefore, selecting from completely idle states ensures that the newly added allocation units for Part 1 have never been used by any previous experiment, and that all newly added users are entirely new users, avoiding the introduction of existing users from other experiments and thus preventing overlap between user groups across experiments.

[0046] In one possible implementation, selecting allocation units from allocation units in a pure idle state for allocation includes: sequentially selecting allocation units from a first set of allocation units in a pure idle state according to the order in which each allocation unit was marked as being in a pure idle state.

[0047] The time when an allocation unit is marked as being in a clean, idle state refers to the moment it enters this state. For example, all allocation units are simultaneously marked as clean and idle during system initialization, or a batch of allocation units are reset and marked as clean and idle when reset conditions are met. When allocation units need to be selected, those marked as clean and idle earlier are prioritized. This ensures that clean allocation units that have not been used for a long time are used first, thus achieving orderly traffic consumption and preventing some allocation units from remaining idle for extended periods while others are frequently used.

[0048] In one possible implementation, the time attribute information includes the timestamp of the experiment first obtaining the allocation unit and the release timestamp of the experiment releasing the allocation unit; prohibiting the use of allocation units in a historically idle state includes: when the timestamp of the first experiment first obtaining the allocation unit is earlier than the release timestamp of the allocation unit in the historically idle state, the allocation unit in the historically idle state is prohibited from being allocated to the first experiment.

[0049] The timestamp of the first acquisition of an allocation unit reflects the order in which the first experiment started running, while the release timestamp reflects when a historical idle allocation unit was released by its original experiment. If the release time of a historical idle allocation unit is later than the first acquisition time of the first experiment, it means that the historical idle allocation unit originally belonged to an experiment created or running later than the first experiment. Allocating it to the earlier first experiment would be equivalent to backflowing traffic released by the later experiment into the earlier experiment, violating the time isolation principle. Therefore, by comparing the timestamps, indirect contamination caused by such time inversion can be avoided, further enhancing the purity of samples when expanding existing experiments. At the same time, through the dual constraints of the time and state dimensions, the improper inflow of historical traffic into existing experiments is prevented, ensuring the continuity and reliability of experimental data.

[0050] A2: When the traffic operation request is a traffic allocation request for a newly created second experiment, it shall be selected from the allocation units that are in the historical idle state for allocation first, and if the number of allocation units in the historical idle state is insufficient, it shall be supplemented from the allocation units that are in the pure idle state.

[0051] A newly created second experiment refers to an experiment that has not yet received any allocation units and is requesting traffic for the first time. For a newly created second experiment, since the experiment itself has no user base, even if historically idle allocation units that have been used by other experiments but have been released are allocated to it, it will not cause cross-contamination of the user base, because there is no issue of existing users being confused with new users in the second experiment. Therefore, to improve the utilization of traffic resources, allocation units in a historically idle state can be consumed first, reducing unnecessary consumption of purely idle allocation units. When the number of historically idle allocation units is insufficient, they can be supplemented from purely idle units.

[0052] In one possible implementation, allocation is preferentially selected from allocation units that are in a historically idle state, including: selecting allocation units sequentially from a second set of allocation units that are in a historically idle state according to the order of their release timestamps.

[0053] The release timestamp of the allocation unit records the moment when the allocation unit was released by its original experiment. The earlier the allocation unit is released, the longer it will be idle. Prioritizing these allocation units can ensure that traffic is recycled as soon as possible, avoid historical traffic from remaining in the idle pool for a long time, and improve the overall traffic utilization efficiency.

[0054] In one possible implementation, after prioritizing allocation from allocation units in a historically idle state, the user identifier carried by the user access request of the newly created second experiment is obtained; a salt value for the second experiment is generated based on the random identifier and the experiment version number of the second experiment; a hash calculation is performed on the salt value and the user identifier, and based on the result of the hash calculation, it is determined whether the user identifier is allocated to the second experiment; in response to determining that the user identifier is allocated to the second experiment, the user identifier is allocated to the experiment group corresponding to the second experiment.

[0055] The salt value is generated by combining a random identifier and an experiment version number. Since different experiments have different random identifiers or different experiment version numbers, the salt value corresponding to each experiment is different. Even if the same allocation unit number is used, after different salt value hash mappings, the same user identifier will fall into different groups in different experiments. Therefore, the historical idle allocation units are only the set of capacity available for new experiments. After the new experiment rehashes its own salt value, the affiliation of specific users within the allocation unit is completely refreshed, and the user groups of the old experiment will not be inherited, thus maintaining the orthogonal and independent relationship between the experiments.

[0056] To support the aforementioned differentiated allocation control logic, the status attribute information of the allocation units is maintained before responding to traffic operation requests for the target experiment. In one possible implementation, in response to a scaling-down request for an existing third experiment, the status attribute information of the allocation units released by the third experiment is updated from the used state to the historical idle state, and the release timestamp of the released allocation units is recorded. Whenever an experiment scales down, the terminal device can accurately capture the time when the release action occurs, providing a basis for subsequent timestamp-based selection and prohibition rules.

[0057] In one possible implementation, when it is detected that all experiments within the current traffic layer have gone offline, the status attribute information of all allocation units in the current traffic layer that were in a historically idle state is uniformly reset to a clean idle state. This means that these allocation units are only purified and their historical traces are cleared and restored to a clean idle state when a traffic layer is completely idle and no experiments are running. The reset mechanism can avoid frequent state switching caused by the offline of some experiments, thereby ensuring the stability and predictability of state management.

[0058] In this embodiment, the traffic allocation method provides differentiated allocation control for different types of traffic operation requests, experiments with different time attributes, and allocation units with different state attributes. For existing experiment expansion, by restricting the use of only pure idle state allocation units and combining timestamp comparison, the reverse contamination of historical traffic to existing experiments is blocked. For newly created experiments, by prioritizing the reuse of historical idle allocation units and refreshing the mapping relationship with its own salt value, efficient traffic recycling is achieved while maintaining orthogonal isolation between experiments. This embodiment achieves precise management of allocation unit usage permissions through state records and timestamp-driven selection, prohibition, and reset rules, which can effectively improve the isolation in the experimental traffic allocation process, reduce the risk of sample cross-contamination, and thus ensure the accuracy and reliability of experimental data.

[0059] As one possible implementation of this application, such as Figure 3 As shown, before responding to a traffic operation request for a target experiment, the terminal device can predetermine the range of available allocation units for different experiments through an orthogonal hash allocation mechanism. This ensures that the allocation units occupied by multiple experiments within the same traffic layer do not overlap, thereby achieving traffic isolation in the spatial dimension. The specific implementation process is detailed below: S301: In response to a user access request for the target experiment, obtain the user identifier carried in the user access request.

[0060] A user access request refers to a request generated when a user accesses an experimental platform page or function through a terminal device. When a user initiates access, the user access request carries a user identifier to uniquely identify the user. This user identifier can be a user identity number, device identifier, or session identifier, etc., that can distinguish different users. This application does not limit the specific form of the user identifier. By parsing the user access request, the user identifier is extracted so that subsequent hash calculations and traffic allocation can be performed based on this user identifier.

[0061] S302: Generate the salt value of the target experiment based on the random identifier and the experiment version number of the target experiment.

[0062] A random identifier is a string or number generated randomly to distinguish different experiments. The experiment version number refers to the version identifier of the experiment configuration or definition. Whenever an experiment is taken offline and then recreated or deployed with a new version, the experiment version number will change accordingly. The random identifier and the experiment version number are combined to generate the salt value for the target experiment. For example, assuming the random identifier generated for an experiment is "exp_rand_001" and the experiment version number is "v2", the two can be concatenated or combined according to preset rules to create the salt value, such as "exp_rand_001_v2".

[0063] Because the salt value includes the experiment version number, even if the random identifier is reused after the experiment is taken offline, the newly generated salt value will still be different from the old salt value as long as the experiment version number has been updated. This ensures that experiments created at different times have different salt values. This salt value generation mechanism ensures that each experiment uses different salting parameters in the hash calculation, providing a foundation for subsequent orthogonal allocation.

[0064] S303: Perform a hash calculation based on the salt value and the user identifier, and determine the range of available allocation units corresponding to the user identifier based on the result of the hash calculation.

[0065] After obtaining the salt value for the target experiment, the salt value and the user identifier are used together as input parameters for a hash function to perform hash calculation. The hash function can be a deterministic algorithm such as MurmurHash or MD5, which maps input data to a fixed range. By adding salt, different experiments will calculate different hash values ​​for the same user identifier, thus achieving orthogonality of traffic between experiments. Based on the hash calculation results and the proportion of traffic required by the target experiment, the available allocation unit range corresponding to that user identifier is determined, providing a clear operational boundary for subsequent execution of differentiated allocation control logic within this range.

[0066] For example, suppose the total traffic is divided into one thousand allocation units, numbered from 0 to 999, and the target experiment requires 10% of the traffic, i.e., 100 allocation units. In this case, the hash value can be modulo 1000 to obtain a value in the range of 0 to 999. This value corresponds to the allocation unit number where the user identifier falls. Then, based on the range of this allocation unit number, a set of consecutive or non-consecutive allocation units allocated to the target experiment is determined, serving as the available allocation unit range for that user identifier.

[0067] From the perspective of orthogonal allocation, since each experiment uses a different salt value, the allocation unit ranges that the same user identifier falls into after hashing with different salt values ​​are independent and do not overlap. For example, the user identifier "user_001" falls into the allocation unit range of 50 to 149 after hashing with the salt value of experiment A, but may fall into the allocation unit range of 300 to 399 after hashing with the salt value of experiment B. The allocation units occupied by the two experiments do not overlap, effectively achieving orthogonal isolation of traffic.

[0068] S304: Within the range of available allocation units, differentiated allocation control logic is executed for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment.

[0069] After determining the range of available allocation units corresponding to the user identifier through hash calculation, the terminal device performs subsequent allocation control within this range. The range of available allocation units defines the spatial boundary for the allocation operation. Within this boundary, the differentiated allocation control logic further filters and makes usage decisions for allocation units based on different state attribute information. In this embodiment, the specific implementation of the differentiated allocation control logic is consistent with the content described in step S102 above, and will not be repeated here.

[0070] In this embodiment, by generating a salt value for the target experiment, independent hash calculation parameters are constructed for each experiment, so that different experiments produce different hash results when performing hash calculations on the same user identifier. This allows users to be evenly and independently allocated to the allocation unit range of each experiment, avoiding traffic overlap caused by different experiments occupying the same allocation unit. By combining the available allocation unit range determined by orthogonal hashing with differentiated allocation control logic, the terminal device achieves non-overlapping traffic of each experiment in the spatial dimension and isolated use of historical traffic and clean traffic in the temporal dimension. The two work together, and the terminal device can reasonably manage the allocation units in different states when expanding or shrinking the experiment. This not only avoids existing experiments being polluted by historical traffic, but also effectively recycles and utilizes historical idle traffic when creating new experiments, improving the overall traffic resource utilization rate.

[0071] In one possible implementation, under high concurrency scenarios, the terminal device may receive multiple operation requests for the same allocation unit at the same time. When there are concurrent operation requests for the same allocation unit, the state change result of the allocation unit is determined according to the order in which the update lock is acquired, wherein the concurrent operation requests include traffic allocation requests for new experiments and scaling down requests for existing experiments.

[0072] Concurrent operation requests refer to multiple operation requests received by a terminal device within the same time window, targeting the same allocation unit and potentially conflicting with each other in state. An update lock is a mutual exclusion mechanism used to control changes to the state of an allocation unit. When a terminal device needs to modify the state attribute information of an allocation unit, it must first acquire the update lock for that allocation unit. Only after successfully acquiring the update lock can the terminal device execute the state change operation for that allocation unit. When multiple concurrent operation requests attempt to operate on the same allocation unit, the terminal device processes each operation request's state change sequentially according to the order in which they acquired the update lock. The operation request that acquires the update lock first executes its corresponding state change first, and the operation request that acquires the update lock later performs its judgment and processing based on the updated state of the allocation unit after the previous operation is completed. In this way, even in extreme concurrency situations where timestamp precision is indistinguishable, the terminal device can determine a unique sequence of state changes through the order of update lock acquisition, ensuring the atomicity and consistency of allocation unit state changes. The update lock guarantees that concurrent operations on the same allocation unit are executed serially in time, avoiding data conflicts caused by multiple operations simultaneously modifying the state of the same allocation unit.

[0073] For example, at a certain moment, a terminal device simultaneously receives a traffic allocation request for a newly created experiment and a scaling-down request for an existing experiment, both of which involve operations on the same allocation unit. The traffic allocation request for the new experiment attempts to allocate the allocation unit to itself, while the scaling-down request for the existing experiment attempts to release the allocation unit and update its status attributes to a historical idle state. These two operations have different requirements for the state change of the allocation unit, and if not coordinated, may lead to inconsistent states or data errors.

[0074] To resolve this conflict, the terminal device serializes concurrent operations using an update lock mechanism. Assuming an existing experiment's scaling-down request acquires the update lock first, the terminal device updates the allocation unit's status attribute information to a historical idle state, records the corresponding release timestamp, and then releases the update lock. Subsequently, a newly created experiment's traffic allocation request acquires the update lock. At this point, the terminal device checks that the allocation unit is currently in a historical idle state, which conforms to the allocation rule of prioritizing the reuse of historically idle allocation units by new experiments. Therefore, it allocates the allocation unit to the newly created experiment and updates its status attribute information from historically idle to used.

[0075] Conversely, assuming a newly created experiment's traffic allocation request acquires the update lock first, the terminal device first allocates the allocation unit to the newly created experiment, updates its status attribute information to "used," and then releases the update lock. If an existing experiment's scaling-down request subsequently acquires the update lock, the terminal device checks that the allocation unit is already occupied by the newly created experiment and is no longer within the scope of the existing experiment's usage. Therefore, the scaling-down release operation is no longer applicable to this allocation unit. The terminal device adjusts the range of allocation units released for the existing experiment's scaling-down according to a preset strategy, for example, by selecting a replacement unit from other allocation units currently occupied by the existing experiment. Through the update lock mechanism, regardless of the order in which concurrent requests acquire locks, the terminal device can guarantee the correctness and consistency of the allocation unit's state.

[0076] In this embodiment, by introducing an update lock and determining the order in which update locks are acquired, it is possible to ensure that state change operations of the same allocation unit do not interfere with each other and are executed sequentially in high-concurrency scenarios, thus avoiding errors or loss of allocation unit state attribute information due to concurrent operations. The update lock mechanism works synergistically with the aforementioned differentiated allocation control logic to ensure the accuracy of allocation unit state management even in large-scale concurrent experimental scenarios, guaranteeing the reliability and consistency of traffic allocation.

[0077] As can be seen from the above, in this embodiment, when a traffic operation request for a target experiment is received, the allocation logic is associated with the time characteristics of the experiment and the usage history of the allocation unit by obtaining the time attribute information of the target experiment and the status attribute information of the allocation unit. The allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. Then, according to the type of traffic operation request and the time attribute information of the target experiment, differentiated allocation control logic is executed for allocation units with different status attribute information. This ensures that the allocation units that experiments created at different time stages can use during the scaling up and down process are constrained by the time dimension. This achieves the adaptation of corresponding traffic allocation strategies for different traffic operation scenarios, different time characteristics of experiments, and different usage states of allocation units. This effectively reduces the situation where allocation units are incorrectly allocated during the scaling up and down process of experiments, thereby improving the isolation of the experimental traffic allocation process, reducing the risk of sample cross-contamination, and preventing users from being reassigned between different experiments due to improper reuse of allocation units. This ensures the stability of the experimental user group and thus ensures the accuracy and reliability of experimental data.

[0078] 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 this application.

[0079] Corresponding to the traffic allocation method described in the above embodiments, Figure 4 A structural block diagram of the flow distribution device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0080] Reference Figure 4 The traffic distribution device includes: an attribute information acquisition module 41 and a traffic distribution module 42, wherein: The attribute information acquisition module 41 is used to respond to a traffic operation request for a target experiment and acquire the time attribute information of the target experiment and the status attribute information of the allocation unit, wherein the allocation unit is obtained based on the total traffic division and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. The traffic allocation module 42 is used to execute differentiated allocation control logic on allocation units with different state attribute information according to the type of the traffic operation request and the time attribute information of the target experiment.

[0081] As one possible implementation of this application, the status attribute information of the allocation unit includes a pure idle state representing a state that has never been allocated and a historical idle state representing a state that has been allocated and released; the traffic allocation module 42 is specifically used for: When the traffic operation request is a traffic expansion request for an existing first experiment, the allocation is selected from the allocation units that are in a clean and idle state, and the use of allocation units that are in a historically idle state is prohibited. When the traffic operation request is a traffic allocation request for a newly created second experiment, allocation is preferentially selected from allocation units that are in a historically idle state, and if the number of allocation units in a historically idle state is insufficient, allocation is supplemented from allocation units that are in a completely idle state.

[0082] As one possible implementation of this application, the time attribute information includes the timestamp of the experiment first obtaining the allocation unit and the release timestamp of the experiment releasing the allocation unit; The prohibition of using allocation units that are in a historically idle state includes: When the timestamp of the first experiment's first acquisition of an allocation unit is earlier than the timestamp of the allocation unit in the historically idle state, the allocation of the historically idle allocation unit to the first experiment is prohibited.

[0083] As one possible implementation of this application, the step of selecting allocation units from those in a completely idle state for allocation includes: Allocation units are selected sequentially from the first set of allocation units that are in the pure idle state, according to the order in which each allocation unit is marked as pure idle. The priority selection from allocation units in a historically idle state for allocation includes: Allocation units are selected sequentially from the second set of allocation units that are in a historically idle state, according to the order of their release timestamps.

[0084] As one possible implementation of this application, the flow distribution device further includes: The update record module is used to update the status attribute information of the allocation unit released by the third experiment from the used state to the historical idle state in response to the scaling down request for the existing third experiment, and record the release timestamp of the released allocation unit.

[0085] As one possible implementation of this application, the flow distribution device further includes: The status reset module is used to reset the status attribute information of all allocation units in the current traffic layer that are in a historical idle state to a clean idle state when it is detected that all experiments in the current traffic layer have been taken offline.

[0086] As one possible implementation of this application, the flow distribution device further includes: The identifier acquisition module is used to obtain the user identifier carried in the user access request in response to the user access request for the target experiment. A salt value generation module is used to generate the salt value of the target experiment based on a random identifier and the experiment version number of the target experiment. An allocatable range determination module is used to perform a hash calculation based on the salt value and the user identifier, and determine the range of available allocation units corresponding to the user identifier based on the result of the hash calculation; The flow distribution module 41 is also used for: Within the available allocation units, differentiated allocation control logic is executed for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment.

[0087] As can be seen from the above, in this embodiment, when a traffic operation request for a target experiment is received, the allocation logic is associated with the time characteristics of the experiment and the usage history of the allocation unit by obtaining the time attribute information of the target experiment and the status attribute information of the allocation unit. The allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. Then, according to the type of traffic operation request and the time attribute information of the target experiment, differentiated allocation control logic is executed for allocation units with different status attribute information. This ensures that the allocation units that experiments created at different time stages can use during the scaling up and down process are constrained by the time dimension. This achieves the adaptation of corresponding traffic allocation strategies for different traffic operation scenarios, different time characteristics of experiments, and different usage states of allocation units. This effectively reduces the situation where allocation units are incorrectly allocated during the scaling up and down process of experiments, thereby improving the isolation of the experimental traffic allocation process, reducing the risk of sample cross-contamination, and preventing users from being reassigned between different experiments due to improper reuse of allocation units. This ensures the stability of the experimental user group and thus ensures the accuracy and reliability of experimental data.

[0088] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0089] This application embodiment also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements... Figures 1 to 3 The steps of any traffic allocation method are represented.

[0090] This application embodiment also provides a terminal device, 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... Figures 1 to 3 The steps of any traffic allocation method are represented.

[0091] This application also provides a computer program product that, when run on a terminal device, causes the terminal device to execute the implementation of... Figures 1 to 3 The steps of any traffic allocation method are represented.

[0092] Figure 5 This is a schematic diagram of a terminal device provided in an embodiment of this application. For example... Figure 5As shown, the terminal device 5 in this embodiment includes: a processor 50, a memory 51, and a computer program 52 stored in the memory 51 and executable on the processor 50. When the processor 50 executes the computer program 52, it implements the steps in the various traffic allocation method embodiments described above, for example... Figure 1 Steps S101 to S102 are shown. Alternatively, when the processor 50 executes the computer program 52, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 4 The functions of modules 41 to 42 are shown.

[0093] For example, the computer program 52 may be divided into one or more modules / units, which are stored in the memory 51 and executed by the processor 50 to complete this application. The one or more modules / units may be a series of computer-readable instruction segments capable of performing a specific function, which describe the execution process of the computer program 52 in the terminal device 5.

[0094] The terminal device 5 may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of terminal device 5 and does not constitute a limitation on terminal device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device 5 may also include input / output devices, network access devices, buses, etc.

[0095] The processor 50 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0096] The memory 51 can be an internal storage unit of the terminal device 5, such as a hard disk or memory of the terminal device 5. The memory 51 can also be an external storage device of the terminal device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal device 5. Furthermore, the memory 51 can include both internal and external storage units of the terminal device 5. The memory 51 is used to store the computer program and other programs and data required by the terminal device. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0097] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0098] 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 merely 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0100] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0101] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application, and should all be included within the protection scope of this application.

Claims

1. A flow allocation method, characterized in that, include: In response to a traffic operation request for a target experiment, the time attribute information of the target experiment and the status attribute information of the allocation unit are obtained, wherein the allocation unit is obtained based on the total traffic allocation, and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. Based on the type of the traffic operation request and the time attribute information of the target experiment, differentiated allocation control logic is executed for allocation units with different state attribute information.

2. The method according to claim 1, characterized in that, The status attribute information of the allocation unit includes a pure idle state that has never been allocated and a historical idle state that has been allocated and released. The step of executing differentiated allocation control logic for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment includes: When the traffic operation request is a traffic expansion request for an existing first experiment, the allocation is selected from the allocation units that are in a clean and idle state, and the use of allocation units that are in a historically idle state is prohibited. When the traffic operation request is a traffic allocation request for a newly created second experiment, allocation is preferentially selected from allocation units that are in a historically idle state, and if the number of allocation units in a historically idle state is insufficient, allocation is supplemented from allocation units that are in a completely idle state.

3. The method according to claim 2, characterized in that, The time attribute information includes the timestamp of the first acquisition of the allocation unit in the experiment and the release timestamp of the release of the allocation unit in the experiment; The prohibition of using allocation units that are in a historically idle state includes: When the timestamp of the first experiment's first acquisition of an allocation unit is earlier than the timestamp of the allocation unit in the historically idle state, the allocation of the historically idle allocation unit to the first experiment is prohibited.

4. The method according to claim 2, characterized in that, The step of selecting allocation units from those in a clean, idle state for allocation includes: Allocation units are selected sequentially from the first set of allocation units that are in the pure idle state, according to the order in which each allocation unit is marked as pure idle. The priority selection from allocation units in a historically idle state for allocation includes: Allocation units are selected sequentially from the second set of allocation units that are in a historically idle state, according to the order of their release timestamps.

5. The method according to claim 2, characterized in that, Prior to the traffic manipulation request in response to the target experiment, the following is also included: In response to a scaling-down request for an existing third experiment, the status attribute information of the allocation unit released by the third experiment is updated from the used state to the historical idle state, and the release timestamp of the released allocation unit is recorded.

6. The method according to claim 2, characterized in that, The method further includes: When it is detected that all experiments within the current traffic layer have been taken offline, the status attribute information of all allocation units in the current traffic layer that are in a historical idle state will be uniformly reset to a clean idle state.

7. The method according to any one of claims 1 to 6, characterized in that, Prior to the traffic manipulation request in response to the target experiment, the following is also included: In response to a user access request for the target experiment, obtain the user identifier carried in the user access request; The salt value of the target experiment is generated based on the random identifier and the experiment version number of the target experiment; A hash calculation is performed based on the salt value and the user identifier, and the range of available allocation units corresponding to the user identifier is determined according to the result of the hash calculation. The step of executing differentiated allocation control logic for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment includes: Within the available allocation units, differentiated allocation control logic is executed for allocation units with different state attribute information based on the type of the traffic operation request and the time attribute information of the target experiment.

8. A flow distribution device, characterized in that, include: The attribute information acquisition module is used to respond to a traffic operation request for a target experiment and acquire the time attribute information of the target experiment and the status attribute information of the allocation unit, wherein the allocation unit is obtained based on the total traffic allocation and the status attribute information is determined based on whether the allocation unit has been allocated to any experiment. The traffic allocation module is used to execute differentiated allocation control logic on allocation units with different state attribute information according to the type of the traffic operation request and the time attribute information of the target experiment.

9. A terminal 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 traffic allocation method 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 traffic allocation method as described in any one of claims 1 to 7.

Images