Multi-time-zone experimental configuration publishing method and device, computer device and storage medium

Abstract

The application discloses a multi-time-zone experiment configuration publishing method and device, computer equipment and a storage medium. The method comprises the following steps: obtaining an experiment configuration to be published, wherein the experiment configuration to be published comprises configuration content, a target range and a local effective time; generating a plurality of target experiment configurations based on the experiment configuration to be published according to the corresponding relationship between the target range and a plurality of time zones; setting the same publishing identifier for the plurality of target experiment configurations, and publishing the plurality of target experiment configurations; and the publishing identifier is used for reporting a hit result on a client. Through generating a plurality of target experiment configurations corresponding to different time zones respectively and adopting a single time zone configuration format, the clients in different target areas can enter a running state corresponding to the same configuration content according to the corresponding local time. Through setting the same publishing identifier for the plurality of target experiment configurations, the hit result uploaded by the client can be uniformly associated based on the same identifier, and the data processing cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method, apparatus, computer equipment, and storage medium for publishing multi-timezone experimental configurations. Background Technology

[0002] With the cross-regional deployment of computer application systems, configuration publishing servers typically need to publish experimental configurations to a configuration center or object storage for clients to access and execute. Experimental configurations can be structured data used to control client-side data processing operations such as resource loading, data caching, network requests, UI rendering, or algorithm calculations. Configuration content can include runtime parameters that affect client running status and technical performance. In A / B testing scenarios, different configuration content can be distributed to different clients according to preset traffic distribution rules, enabling different clients to execute data processing operations according to corresponding runtime parameters. The configuration hit results can be correlated with runtime data such as response latency, processor utilization, memory usage, network traffic, or anomaly occurrence rate to compare the impact of different runtime parameters on client technical performance.

[0003] Clients typically parse experimental configurations according to a pre-defined format, determining their effectiveness based on the target region, time zone, and valid time. If the conditions are met, the client enters the corresponding running state. Existing clients generally support single-timezone configurations, meaning each configuration can only use one timezone as the interpretation base for its valid time. When the same configuration targets multiple timezones and needs to be effective at the same local time in each region, the single timezone and its corresponding valid time cannot accurately represent the effectiveness relationship between target regions because the same local time corresponds to different absolute times in different timezones. This can easily cause some clients to enter the corresponding running state prematurely or delayed, and cause the collected running data to deviate from the predetermined time range. Changing the existing configuration format to express valid times for multiple timezones requires adjusting the configuration parsing logic of deployed clients, potentially leading to client version compatibility issues.

[0004] Furthermore, when clients in different target regions complete configuration hit detection and upload hit results separately, hit results related to the same experiment may be identified by the server as different data sources due to carrying different configuration identifiers, resulting in the scattered storage of hit results and their associated runtime data. The server needs to additionally maintain the mapping relationship between multiple configuration identifiers and perform data retrieval, matching, and association calculations, increasing the processing overhead of hit results and runtime data, and may also cause data classification bias due to incorrect identifier mapping.

[0005] Therefore, the existing experimental configuration deployment method struggles to ensure that the same configuration content takes effect accurately in multiple time zones according to the corresponding local time, while maintaining compatibility with the client's existing single-timezone configuration format. Furthermore, different configuration identifiers make it difficult to uniformly correlate related hit results and runtime data, increasing the data processing overhead on the server side. Summary of the Invention

[0006] Based on this, it is necessary to provide a method, apparatus, computer equipment, and storage medium for publishing multi-timezone experimental configurations to address the aforementioned technical problems. This method has the advantages of ensuring that the same configuration content takes effect accurately in multiple time zones according to the corresponding local time while being compatible with the client's existing single-timezone configuration format, and reducing the data processing overhead on the server side.

[0007] A method for deploying multi-timezone experimental configurations, applied to a configuration deployment server, the method comprising: Obtain the configuration of the experiment to be published, which includes the configuration content, target range, and local validity period; Based on the correspondence between the target range and multiple time zones, multiple target experiment configurations are generated based on the experiment configuration to be released. Each target experiment configuration adopts a single time zone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a partial target range associated with the corresponding time zone, and an effective time determined based on the local effective time and the corresponding time zone. Set the same release identifier for multiple target experiment configurations, and release multiple target experiment configurations. The release identifier is used by the client to report the hit result.

[0008] Optionally, the target range includes multiple target regions; the step of generating multiple target experimental configurations based on the correspondence between the target range and multiple time zones, and based on the experimental configuration to be released, includes: Obtain the region affiliation information and time zone information of each target region; Multiple materialized targets are generated according to the regional affiliation information and the time zone information, wherein each materialized target corresponds to a combination of regional affiliation information and time zone information, and includes a portion of the target range corresponding to the combination; Perform mutual exclusion checks on the partial target ranges corresponding to multiple materialized targets to determine whether there are target regions that simultaneously belong to at least two of the materialized targets; If the mutual exclusion check passes, multiple target experiment configurations are generated based on the experimental configuration to be released, according to the multiple materialized targets.

[0009] Optionally, the step of generating multiple target experiment configurations based on the experiment configuration to be released, according to multiple materialized targets, includes: In the same materialization transaction, multiple physical experiment instances are created for multiple materialization targets, wherein each physical experiment instance corresponds to one materialization target; The configuration content is written into multiple physical experiment instances. The partial target range corresponding to each physical experiment instance is determined according to the corresponding materialization target. The local effective time is converted according to the time zone information of the corresponding materialization target to obtain the effective time corresponding to each physical experiment instance. Establish batch association relationships among multiple physical experiment instances, determine a master instance from the multiple physical experiment instances, and determine the remaining physical experiment instances as associated instances; Audience conflict verification was performed on multiple instances of the physical experiment. If all of the physical experiment instances are successfully created and pass the audience conflict check, the materialization transaction is submitted, and multiple target experiment configurations are generated based on the multiple physical experiment instances respectively. If any of the physical experiment instances fails to be created or fails the audience conflict check, the materialized transaction is rolled back.

[0010] Optionally, the method further includes: In response to the configuration update request for the primary instance, a batch lock is acquired according to the batch association relationship, and the primary instance and the associated instances in the valid state are identified as multiple instances to be updated. The configuration update request includes update data, and the update data includes at least one of the updated configuration content and the updated local validity time. In the same update transaction, while retaining the partial target range and time zone information corresponding to each instance to be updated, the update data is applied to multiple instances to be updated respectively. When the update data includes updated configuration content, the updated configuration content is written to multiple instances to be updated. When the update data includes updated local effective time, the updated effective time is determined according to the time zone information corresponding to each instance to be updated. If all of the instances to be updated are successfully updated, the update transaction shall be committed. If any of the instances to be updated fails to update, the update transaction is rolled back.

[0011] Optionally, the method further includes: In response to a version update request for the primary instance, a batch lock is acquired based on the batch association, and a version transaction is initiated. Multiple version instances to be generated are determined from the main instance and the associated instances that are in a valid state; A unified target version number is determined based on the current version information of multiple instances of the version to be generated; In the version transaction, instance versions with the target version number are generated for each of the multiple instances of the version to be generated; If all of the aforementioned instance versions are successfully generated, the version transaction shall be committed; If any instance version generation fails, the version transaction is rolled back.

[0012] Optionally, the version addition request is a version replication request carrying the updated target range; in the version transaction, before determining multiple version instances to be generated, the method further includes: Based on the batch association relationship, obtain the original target range corresponding to the copied version; The target regions in the original target range and the updated target range are grouped according to the region affiliation information and the time zone information, respectively, to obtain the original materialized target set and the updated materialized target set; Based on the regional affiliation information and time zone information corresponding to each materialized target, the original set of materialized targets and the updated set of materialized targets are compared to obtain topological difference information. The topological difference information is used to indicate at least one of the following: newly added materialized targets, materialized targets whose ranges have changed, and removed materialized targets. The physical experiment instances in the batch association are adjusted according to the topology difference information. Specifically, when the topology difference information indicates the addition of a new materialized target, a physical experiment instance corresponding to the new materialized target is created, and the created physical experiment instance is added to the batch association. When the topology difference information indicates that some target ranges of a materialized target have changed, the target ranges of the corresponding physical experiment instance are adjusted. When the topology difference information indicates the removal of a materialized target, the corresponding physical experiment instance is excluded from the current version update. The adjusted physical experiment instances that will be added in this version will be determined as multiple instances of the version to be generated.

[0013] Optionally, the release identifier includes an experiment identifier and a version identifier; setting the same release identifier for multiple target experiment configurations and releasing multiple target experiment configurations includes: Based on the batch association relationship, obtain the release version corresponding to the main instance and each associated instance that is in a valid state; Perform consistency checks on the version numbers and configuration content of multiple versions to be released; If the consistency check passes, the experiment identifier and version identifier of the release version corresponding to the main instance will be determined as the group experiment identifier and group version identifier, respectively. While retaining the target range, time zone information and effective time corresponding to each target experiment configuration, the experiment identifier and version identifier of multiple target experiment configurations are set as the group experiment identifier and the group version identifier, respectively, and multiple target experiment configurations are published.

[0014] A multi-timezone experimental configuration publishing device, applied to a configuration publishing server, the device comprising: The acquisition module is used to acquire the configuration of the experiment to be published, which includes the configuration content, target range and local validity period. The generation module is used to generate multiple target experiment configurations based on the correspondence between the target range and multiple time zones, according to the experimental configuration to be released. Each target experiment configuration adopts a single time zone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a partial target range associated with the corresponding time zone, and an effective time determined according to the local effective time and the corresponding time zone. The publishing module is used to set the same publishing identifier for multiple target experiment configurations and to publish multiple target experiment configurations. The publishing identifier is used by the client to report the hit result.

[0015] A computer device includes a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer-readable instructions, implements the above-described multi-timezone experimental configuration release method.

[0016] A readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the above-described multi-timezone experimental configuration and deployment method.

[0017] The aforementioned multi-timezone experimental configuration publishing method, apparatus, computer equipment, and storage medium obtain the experimental configuration to be published, which includes configuration content, target range, and local valid time. Based on the correspondence between the target range and multiple time zones, multiple target experimental configurations are generated from the experimental configuration to be published. Each target experimental configuration adopts a client-supported single-timezone configuration format, corresponds to one of the multiple time zones, and includes the configuration content, a portion of the target range associated with the corresponding time zone, and an effective time determined based on the local valid time and the corresponding time zone. A common publishing identifier is set for the multiple target experimental configurations, and the multiple target experimental configurations are published. The publishing identifier is used by the client to report hit results. By generating multiple target experimental configurations corresponding to different time zones and using a single-timezone configuration format, clients in different target regions can enter the running state corresponding to the same configuration content according to their respective local time, while maintaining compatibility with existing client configuration parsing logic. By setting a common publishing identifier for multiple target experimental configurations, hit results uploaded by the client can be uniformly associated based on the same identifier, reducing the processing load of identifier mapping, data retrieval, and association calculations performed by the server, and lowering data processing overhead. Attached Figure Description

[0018] 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.

[0019] Figure 1 This is a flowchart illustrating a multi-timezone experimental configuration deployment method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of the multi-timezone experimental configuration release system in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the target experiment configuration generation method in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the experimental configuration update and version addition method in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the method for publishing target experiment configurations and reporting hit results in an embodiment of the present invention. Figure 6 This is a flowchart illustrating the physical experiment example of the version copying process adjustment method in an embodiment of the present invention. Figure 7 This is a schematic diagram of a multi-time zone experimental configuration release device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0020] 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.

[0021] In one embodiment, such as Figure 1 As shown, a method for publishing multi-timezone experimental configurations is provided and applied to a configuration publishing server, including the following steps: 101. Obtain the configuration for the experiment to be released.

[0022] In this embodiment of the invention, the experimental configuration to be published includes configuration content, target scope, and local validity period. The configuration publishing server can be a server, server cluster, or virtualized computing node deployed in a data center or cloud computing environment, equipped with a processor, memory, and communication interface, used to receive, parse, generate, and publish structured configuration data. The configuration publishing server can establish communication connections with the configuration management terminal, regional basic data service, configuration center, object storage, and clients.

[0023] The experimental configuration to be released can be unreleased structured configuration data, or an existing experimental configuration that has been edited or copied to form a version to be released. The configuration content can include at least one of the following: experimental parameters, grouping parameters, traffic splitting configuration, client function control parameters, and audience conditions. The target scope is used to limit the applicable area of ​​the experimental configuration and can include at least one of the following: country, city, market region, or data center. The target scope may also include exclusion area information for excluding certain regions. Specifically, the experimental configuration to be released can be an A / B experiment configuration. An A / B experiment can be an experimental method that, according to preset traffic splitting rules, distributes client or user requests that meet the audience conditions to at least two experimental groups, provides different configuration content to different experimental groups, and compares the execution effects of different configuration content based on the running data generated by each experimental group. A and B are used to distinguish different experimental groups and do not constitute a limit on the number of experimental groups; the number of experimental groups can also be three or more.

[0024] The local valid time indicates the time range during which the experimental configuration is effective using the local wall clock time in the target area. It can include the local effective date, local effective time, local expiration date, and local expiration time. Since the local valid time is not yet linked to a specific time zone, the same local valid time can correspond to different absolute times in different time zones. For example, if the target area includes two cities located in the UTC+8 and UTC+1 zones respectively, and the local valid time is from 10:00 to 18:00 on the predetermined date, this means the experimental configuration needs to take effect at 10:00 local time in each of the two cities, rather than at the same absolute time.

[0025] Furthermore, such as Figure 2 As shown, the experiment template receiving module receives the experiment configuration to be published, and the experiment template in the figure corresponds to the experiment configuration to be published before materialization. The market time zone parsing module obtains the regional affiliation information and time zone information of each target area according to the target range. The materialization decision module determines whether to perform multi-chain materialization based on the time zone parsing results, and the multi-chain materialization module generates multiple physical experiment instances corresponding to different time zones. The batch association and context module establishes batch association relationships between multiple physical experiment instances, and the master chain election module determines the master instance from multiple physical experiment instances. The logical single experiment view module presents multiple physical experiment instances with association relationships as the same experiment, the master-modification synchronization and group-level orchestration module coordinates the configuration updates and version additions of multiple physical experiment instances, and the conflict verification module verifies the audience scope of each physical experiment instance. The publication identifier naming module unifies the publication identifier carried by multiple target experiment configurations, and the configuration publication module publishes the target experiment configuration to the configuration center or object storage. After obtaining the target experiment configuration, the client performs a hit judgment and uploads the hit result using the unified publication identifier.

[0026] In one possible embodiment, the configuration publishing server can obtain the experimental configuration to be published through a visual configuration interface, application programming interface, or configuration file import method, and perform field integrity, time format, and target region encoding validity checks on the experimental configuration to be published. After the checks pass, time zone parsing and materialization processing are performed.

[0027] 102. Based on the correspondence between the target range and multiple time zones, generate multiple target experimental configurations based on the experimental configurations to be released.

[0028] In this embodiment of the invention, each target experiment configuration adopts a single time zone configuration format supported by the client, which corresponds to one of multiple time zones, and includes configuration content, a partial target range associated with the corresponding time zone, and an effective time determined based on the local effective time and the corresponding time zone.

[0029] The configuration release server converts a single deployment configuration into multiple target experiment configurations based on the correspondence between the target range and multiple time zones. The correspondence between the target range and multiple time zones represents the mapping relationship between each target region and its corresponding time zone. For example, when the target range includes multiple cities, the time zone corresponding to each city can be determined separately, and cities corresponding to the same time zone can be included as part of the target range of the corresponding target experiment configuration. When a country spans multiple time zones, the correspondence can be determined at the city or smaller regional granularity.

[0030] Each target experiment configuration corresponds to a specific time zone and retains the configuration content from the experiment configuration to be released. The main differences between different target experiment configurations lie in the target scope, time zone, and effective time. By generating multiple target experiment configurations, a single configuration data covering multiple time zones can be converted into multiple configuration data sets, each applicable to a single time zone.

[0031] The single-timezone configuration format can be a data format that the client's existing configuration parsing logic can recognize. For example, a single configuration data set contains only one timezone field and a set of effective time fields corresponding to that timezone. The field names, field types, data levels, and serialization methods of each target experiment configuration can use the configuration protocols already supported by the client, so that the client does not need to parse multiple timezones and multiple sets of effective times in a single configuration.

[0032] The effective time can be determined by combining the local effective time with the time zone corresponding to the target experiment configuration. For example, the target range includes City A, located in the UTC+8 zone, and City B, located in the UTC+1 zone, with the local effective time being from 10:00 to 18:00 on the predetermined date. With the time zone offset remaining constant, the target experiment configuration for City A can include City A, the UTC+8 zone, and the converted Coordinated Universal Time (UTC) from 2:00 to 10:00; the target experiment configuration for City B can include City B, the UTC+1 zone, and the converted UTC from 9:00 to 17:00. The absolute effective times for the two target experiment configurations are different, but both can take effect at 10:00 local time in their respective cities.

[0033] In one possible implementation, IANA time zone identifiers can be used to record the time zones corresponding to each target region, and the effective time can be calculated based on the time zone offset and daylight saving time rules corresponding to the target date in the IANA time zone database, thereby reducing the time deviation caused by the inability of fixed time zone offsets to adapt to daylight saving time changes.

[0034] 103. Set the same release identifier for multiple target experiment configurations and release multiple target experiment configurations. The release identifier is used by the client to report the hit results.

[0035] In this embodiment of the invention, the configuration publishing server sets the same publishing identifier for multiple target experimental configurations. The publishing identifier can be a character, number, or combination code used to indicate that multiple target experimental configurations originate from the same experimental configuration to be published, and can be written into the identifier field or publishing metadata of each target experimental configuration. Each target experimental configuration uses the same publishing identifier, but still retains its corresponding partial target range, time zone, and effective time.

[0036] The configuration publishing server can publish multiple target experiment configurations to a configuration center or object storage, or send them to clients via push notifications. After obtaining the target experiment configuration, the client matches it against its target region, current time, and audience criteria within the configuration content. When the matching result meets the configuration execution conditions, the client determines that it has matched the corresponding target experiment configuration and uploads a hit result carrying a publishing identifier. The hit result may also include at least one of the following: client identifier, hit time, target region, and configuration execution status.

[0037] For example, two target experiment configurations, one for city A and one for city B, both carry a release identifier R001. When a client in city A hits the corresponding target experiment configuration, it uploads the release identifier R001. Similarly, when a client in city B hits the other target experiment configuration, it uploads the release identifier R001. The configuration release server can directly associate the hit results uploaded from both locations based on R001, without needing to perform additional mapping and association calculations based on the different configuration identifiers.

[0038] By generating multiple target experiment configurations based on the correspondence between the target range and multiple time zones, each target experiment configuration saves a portion of the target range and its effective time that matches the corresponding time zone. This avoids directly applying the same absolute effective time to multiple time zones, reducing the possibility of clients prematurely or delayedly determining the effectiveness of the experiment configuration. This ensures that the same configuration content takes effect accurately in different target regions according to the corresponding local time. Since each target experiment configuration uses a single-timezone configuration format supported by the client, the client does not need to add multi-timezone field parsing, effective time selection, or protocol adaptation logic. It can continue to use the existing configuration parsing process, which helps maintain compatibility and configuration execution stability between different client versions.

[0039] Meanwhile, by configuring the same release identifier for multiple target experiments, the hit results generated in different target regions can be directly indexed, summarized, and statistically analyzed based on the release identifier. This reduces the processing load on the server side, which involves maintaining multiple sets of identifier mapping relationships and repeatedly performing data retrieval and correlation calculations. It also reduces the data processing overhead of the hit results and minimizes data classification bias caused by incorrect identifier mapping. Therefore, the configuration of multiple target experiments can adapt to the time zones and effective times of different target regions while maintaining a unified data correlation relationship during the hit result processing.

[0040] In one possible embodiment, each target experiment configuration can have a different internal storage identifier, but carry the same release identifier when published externally. The internal storage identifier is used to distinguish and manage different target experiment configurations, while the release identifier is used for client hits and hit result reporting, thus taking into account both the independent management of multiple target experiment configurations and the unified association of hit results.

[0041] In this embodiment of the invention, a configuration for an experiment to be published is obtained. This configuration includes configuration content, a target range, and a local valid time. Based on the correspondence between the target range and multiple time zones, multiple target experiment configurations are generated. Each target experiment configuration uses a single-timezone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a portion of the target range associated with the corresponding time zone, and an effective time determined based on the local valid time and the corresponding time zone. A common publication identifier is set for the multiple target experiment configurations, and the multiple target experiment configurations are published. The publication identifier is used by the client to report hit results. By generating multiple target experiment configurations corresponding to different time zones and using a single-timezone configuration format, clients in different target regions can enter the running state corresponding to the same configuration content according to their respective local time, while maintaining compatibility with existing client configuration parsing logic. By setting a common publication identifier for multiple target experiment configurations, hit results uploaded by the client can be uniformly associated based on the same identifier, reducing the processing load of identifier mapping, data retrieval, and association calculations performed by the server, and lowering data processing overhead.

[0042] Optionally, the target range includes multiple target regions; in the step of generating multiple target experimental configurations based on the correspondence between the target range and multiple time zones, the regional affiliation information and time zone information of each target region can also be obtained; multiple materialized targets are generated according to the regional affiliation information and time zone information, wherein each materialized target corresponds to a combination of regional affiliation information and time zone information, and includes a portion of the target range corresponding to the combination; mutual exclusion verification is performed on the portion of the target ranges corresponding to multiple materialized targets to determine whether there are target regions that simultaneously belong to at least two materialized targets; if the mutual exclusion verification passes, multiple target experimental configurations are generated based on the multiple materialized targets and the experimental configuration to be released.

[0043] In this embodiment of the invention, the target area can be a regional unit within the target area that can be independently identified through a regional code. Regional affiliation information indicates the country, market, or data center to which the target area belongs, and time zone information indicates the applicable time zone for the target area. The configuration publishing server can invoke the regional basic data service based on the regional code of the target area to obtain the corresponding country code, market code, data center code, and time zone identifier.

[0044] like Figure 3 As shown, the experiment template submitted by the operations staff corresponds to the experiment configuration to be released. The configuration release server parses the target country and city in the experiment template and obtains the regional affiliation information and time zone information of each city from the regional basic data service. Figure 3 The "parse target country, city, and time zone" function retrieves the regional affiliation and time zone information for each target area, while "verify city mutual exclusion and basic data validity" corresponds to mutual exclusion verification and validity verification of regional basic data. When the target area is granular at the city level, the mutual exclusion verification between target areas manifests as city mutual exclusion verification.

[0045] The configuration publishing server can concatenate regional affiliation information and time zone information into a grouping key, and group target regions with the same grouping key into the same materialized target. Each materialized target records its corresponding regional affiliation information, time zone information, and a partial target range composed of the corresponding target region. The partial target range can include a set of positive target regions and a set of excluded target regions, and can also be associated with audience conditions such as vehicle type. When different regional affiliation information forms different combinations with the same time zone information, different materialized targets are still generated, so that the subsequent generated target experiment configurations can retain the affiliation relationship of the corresponding regions.

[0046] For example, cities A and B both belong to country A and correspond to time zone 1, city C belongs to country A and corresponds to time zone 2, and city D belongs to country B and corresponds to time zone 2. The configuration and publishing server can generate three materialized targets, corresponding to "country A and time zone 1", "country A and time zone 2", and "country B and time zone 2" respectively. The first materialized target partially includes cities A and B, the second partially includes city C, and the third partially includes city D. Therefore, even though cities C and D correspond to the same time zone, they are still classified into different materialized targets due to their different regional affiliation information.

[0047] Mutual exclusion verification can be performed based on the unique region code of the target region. The configuration publishing server can extract the set of positive target regions from each materialized target after deducting excluded target regions, and calculate the intersection between different sets of positive target regions. When any two sets of positive target regions have the same region code, it is determined that there are target regions belonging to at least two materialized targets simultaneously, and the mutual exclusion verification fails. The configuration publishing server can stop generating target experiment configurations and return the conflicting target region codes and corresponding materialized targets to correct the target range. When there is no intersection between different sets of positive target regions, the mutual exclusion verification is considered successful, and multiple materialized targets are used as materialized inputs for generating multiple target experiment configurations subsequently.

[0048] Figure 3 Whether multiple time zones are involved can be determined by deduplicating and counting the time zone identifiers corresponding to multiple materialized targets. When the number of deduplicated time zones is greater than one, the configuration publishing server proceeds to the subsequent multi-chain materialization process; when the number of deduplicated time zones is no more than one, the generation process of the single-time zone experimental configuration can be used. Figure 3 The subsequent main experimental chain election, batch relationship writing, and audience conflict verification will be further explained in subsequent embodiments.

[0049] By generating materialized targets based on regional affiliation information and time zone information, and performing mutual exclusion verification on a portion of the target range before generating the target experiment configuration, it is possible to avoid the same target region being repeatedly written into multiple target experiment configurations, reduce the possibility of duplicate hits caused by the same client simultaneously meeting the regional conditions of multiple target experiment configurations, and provide mutually independent partial target ranges for subsequent creation of physical experiment instances based on materialized targets.

[0050] In one possible embodiment, the configuration publishing server can use hash sets, bitmaps, or inverted indexes to record the target region codes contained in each materialized target, thereby improving the retrieval efficiency of the target region intersection. The configuration publishing server can also verify whether the target region code is valid, whether the region affiliation is complete, and whether the time zone information is empty, and stop the materialization process if there is missing basic region data or the mapping relationship is not unique.

[0051] Optionally, in the step of generating multiple target experiment configurations based on the experiment configuration to be released, multiple physical experiment instances can be created for the multiple materialized targets within the same materialization transaction, where each physical experiment instance corresponds to one materialized target; the configuration content is written to the multiple physical experiment instances; the partial target range corresponding to each physical experiment instance is determined according to the corresponding materialized target; the local effective time is converted according to the time zone information of the corresponding materialized target to obtain the effective time corresponding to each physical experiment instance; a batch association relationship is established between the multiple physical experiment instances; a master instance is determined from the multiple physical experiment instances, and the remaining physical experiment instances are determined as associated instances; audience conflict verification is performed on the multiple physical experiment instances respectively; if all multiple physical experiment instances are successfully created and pass the audience conflict verification, the materialization transaction is committed, and multiple target experiment configurations are generated according to the multiple physical experiment instances respectively; if any physical experiment instance fails to be created or fails the audience conflict verification, the materialization transaction is rolled back.

[0052] In this embodiment of the invention, a physical experiment instance can be an experimental data entity created by the configuration publishing server in the data storage layer. Each physical experiment instance has an independent instance identifier and instance version, and respectively saves configuration content, part of the target range, time zone information and effective time. Figure 3 The physical experiment chain in the code corresponds to a physical experiment instance. The processing of cloning multiple experiment chains according to country and time zone corresponds to creating multiple physical experiment instances for multiple physical targets.

[0053] A materialized transaction can be a transaction processing unit established by the configuration and release server for a single multi-instance materialization process. Materialization refers to converting the configuration of the experiment to be released and multiple materialization targets into multiple physical experiment instances that can be independently stored, verified, and released. A transaction refers to incorporating the creation of multiple physical experiment instances, configuration data writing, batch association, primary instance determination, and audience conflict verification into the same atomic processing scope. Before the materialized transaction is committed, each data writing operation is in an uncommitted state and is not queried or published outside the transaction. When all operations succeed, they are committed uniformly, making multiple physical experiment instances and their batch associations effective simultaneously. If any operation fails, it is rolled back uniformly, restoring the data storage to the state before the materialized transaction began. Therefore, a materialized transaction corresponds to the complete processing boundary of multiple physical experiment instances from their initial creation to their overall effectiveness. Materialized transactions are used to ensure the atomicity of the creation operations of multiple physical experiment instances. The configuration and release server can start a materialized transaction after receiving multiple materialization targets and assign a transaction identifier to the materialized transaction. Instance data, instance version data, target region data, and batch association data are all written in the materialized transaction, and are not queried, edited, or published before the materialized transaction is committed.

[0054] like Figure 3As shown, when the target range involves multiple time zones, the configuration and publishing server enters multi-chain materialization processing and creates physical experiment instances on a per-materialized-target basis. Creating a physical experiment instance may include generating an instance identifier, writing instance basic data, creating an initial instance version, and establishing the association between the instance and the target region. Each physical experiment instance corresponds to only one materialized target, ensuring that the region affiliation information, time zone information, and part of the target range from the materialized target can be completely written into the corresponding physical experiment instance.

[0055] The configuration publishing server writes the configuration content of the experiment to be published into multiple physical experiment instances, ensuring that all physical experiment instances use the same grouping parameters, traffic splitting configurations, function control parameters, and other common configuration fields. Each physical experiment instance also retains the region affiliation information, partial target range, time zone information, and data center information corresponding to the materialized target. The local effective time can be written as a common configuration field into multiple physical experiment instances, and converted to the corresponding absolute effective time based on the time zone information of each physical experiment instance. Therefore, multiple physical experiment instances can store the same local effective time, but each has an effective time matching its own time zone.

[0056] The configuration and publishing server can generate a batch identifier for this creation operation and write a batch record to the batch table. It can also write member records corresponding to multiple physical experiment instances to the batch member table. The batch record can include a batch identifier, batch status, and primary instance identifier. Member records can include the instance identifier, instance role, region affiliation information, time zone information, sort order, and validity status of the physical experiment instance. Multiple member records are associated with the same batch identifier, thus forming a batch association relationship between multiple physical experiment instances.

[0057] Figure 3 In the batch management system, the main experiment chain corresponds to the main instance, and the secondary experiment chains correspond to associated instances. The configuration and publishing server can determine a main instance from multiple physical experiment instances based on a pre-specified main region, the order of the physical experiment instances, or time zone priority, and designate the remaining physical experiment instances as associated instances. Only one member record in the batch member table is marked as the main instance, while the others are marked as associated instances. The main instance serves as a unified query entry point, editing entry point, and external return object for multiple physical experiment instances, while associated instances are stored as backend data entities. The configuration and publishing server can summarize the region, time zone, version, and status of each associated instance in the main instance's details data, allowing access to the entire batch's coverage through a single instance entry point.

[0058] Mutual exclusion checks for materialized targets determine whether the same target area is assigned to multiple materialized targets, while audience conflict checks determine whether newly created physical experiment instances have unacceptable audience overlap with other valid experiment instances. The configuration and publishing server can compare the audience conditions (target area, user tags, client version, vehicle type, traffic range, and experiment level) of each physical experiment instance with valid experiment instances at the same experiment level or in the same business scenario. When audience conditions overlap and do not meet preset coexistence conditions, the corresponding physical experiment instance is determined to have failed the audience conflict check. The configuration and publishing server can preload basic area data and valid experiment instances to be compared in the batch context, and multiple physical experiment instances can reuse the loading results to reduce repeated queries and calculations per instance.

[0059] After multiple physical experiment instances have been successfully created and passed audience conflict checks, the configuration publishing server commits the materialization transaction, making instance data, instance version data, batch records, and member records effective simultaneously. After the materialization transaction is committed, the configuration publishing server can read the instance versions of multiple physical experiment instances and generate the corresponding target experiment configuration accordingly. The configuration publishing server can also... Figure 3 The method shown returns the main instance identifier and batch information, enabling subsequent operations to locate all physical experiment instances in the same batch from the main instance entry point.

[0060] If any physical experiment instance fails to write data, create an initial version, or associate with a target region, the creation of that physical experiment instance is determined to have failed. If any physical experiment instance fails audience conflict verification, the publishing server is configured to roll back the materialized transaction, revoking the physical experiment instance, instance version, batch record, and member record already written in the materialized transaction to avoid retaining batch data that lacks associated instances or has not completed verification. Figure 3 The "rollback of the entire batch" corresponds to the rollback process of the materialized transaction, while "return the main experiment identifier and batch information" corresponds to the return process after the materialized transaction is successfully submitted.

[0061] For example, three materialized targets correspond to three physical experiment instances. The deployment server can be configured to designate the first physical experiment instance as the primary instance and the other two as associated instances. When the third physical experiment instance conflicts with an existing experiment instance, even if the first two physical experiment instances have completed data writing, the materialization transaction is not committed; instead, all three physical experiment instances and their batch associated data are revoked. After the audience conflict is resolved, the materialization process is executed again, and the transaction is committed uniformly when all three physical experiment instances have been successfully created and passed verification.

[0062] By completing the creation, batch association, and audience conflict verification of multiple physical experiment instances within the same materialized transaction, it is possible to avoid only some physical experiment instances being created successfully or only some target regions entering the publishable state, ensuring that multiple target experiment configurations have a complete and consistent physical instance foundation. By setting a master instance and associated instances, it is also possible to retain the independent time zone and partial target range of each physical experiment instance while providing a unified operation entry point for subsequent configuration updates, version additions, and consistent releases.

[0063] In one possible implementation, materialized transactions can be implemented using database-local transactions, distributed transactions, or transaction mechanisms with compensatory operations. The configuration publishing server can also generate idempotent identifiers based on the identifiers of the experiment configurations to be published and the set of materialized targets. When the same creation request is received repeatedly, it returns information about already created batches, avoiding the repeated generation of physical experiment instances due to request retries.

[0064] Optionally, the above method may further include the following steps: in response to a configuration update request for the primary instance, acquiring a batch lock based on the batch association relationship, and identifying the primary instance and associated instances in a valid state as multiple instances to be updated; the configuration update request includes update data, which includes at least one of the updated configuration content and the updated local validity time; within the same update transaction, while retaining partial target range and time zone information corresponding to each instance to be updated, applying the update data to the multiple instances to be updated respectively, wherein when the update data includes the updated configuration content, the updated configuration content is written to the multiple instances to be updated; when the update data includes the updated local validity time, determining the updated effective time according to the time zone information corresponding to each instance to be updated; committing the update transaction if all instances to be updated are successfully updated; and rolling back the update transaction if any instance to be updated fails to update.

[0065] In this embodiment of the invention, configuration update requests can be initiated by the configuration management terminal through the unified editing entry point corresponding to the primary instance. The configuration publishing server can verify whether the request points to the primary instance based on the instance identifier carried in the configuration update request. When the request points to the associated instance, the configuration update can be rejected and the corresponding primary instance identifier can be returned, thus ensuring that all configuration updates in the same batch are initiated from the primary instance entry point. Figure 4 The "Initiate operation from the main experiment entry" and "Normal edit" branches correspond to the processing of configuration updates initiated for the main instance. The main experiment and the slave chain correspond to the main instance and the associated instance, respectively.

[0066] Batch locks are exclusive access controls established by the configuration and publishing server using a batch identifier as the locking object. Once the configuration and publishing server acquires a batch lock, other configuration updates, version additions, version replications, state changes, or publishing operations cannot simultaneously modify physical experimental instances within the same batch. Unlike single-instance locks, batch locks cover all physical experimental instances in the batch's association, preventing configuration inconsistencies caused by different operations modifying the primary and associated instances separately. Batch locks can be implemented using database lock records, distributed lock services, or atomic updates based on batch status fields.

[0067] After the configuration release server acquires the batch lock, it queries the corresponding member records based on the batch association and determines the instances to be updated based on the instance roles and validity status in the member records. The validity status indicates that the physical experiment instance is still participating in the configuration synchronization and subsequent releases of the current batch. Associated instances that have been taken offline, removed, or marked as no longer participating in batch operations are not considered as instances to be updated, thus preventing configuration updates from reactivating physical experiment instances that have already left the current experiment scope.

[0068] An update transaction can be a transaction processing unit established by the configuration publishing server for a batch of configuration updates, used to incorporate data modifications of multiple instances to be updated into the same atomic processing scope. After the update transaction begins, the configuration publishing server can load the current instance version of the primary instance and each valid associated instance, record the data state before the update, and merge the updated data into the current instance version of each instance to be updated. Before the update transaction is committed, the modified data of each instance to be updated remains in an uncommitted state; when all instances to be updated are successfully updated, the transaction is committed uniformly; if any instance to be updated fails to update, the data state is uniformly restored to that before the update transaction began.

[0069] Figure 4 The phrase "synchronize the master experiment changes to the latest version on each slave chain" corresponds to applying the updated data to both the master instance and each valid associated instance. The configuration publishing server can divide the data in the instance version into public configuration fields and instance-specific fields. Public configuration fields may include grouping parameters, experiment parameters, traffic splitting configurations, function control parameters, and local valid time. Instance-specific fields may include regional affiliation information, partial target range, time zone information, and data center information. When performing a configuration update, the updated public configuration fields are written to multiple instances to be updated, while the original instance-specific fields of each instance remain unchanged.

[0070] When the update data includes updated configuration content, the configuration publishing server can write the changed configuration fields to multiple instances to be updated based on the field identifiers carried in the update data. Configuration fields not included in the update data can continue to use their original field values ​​from the corresponding instance version. When the update data includes the updated local valid time, the configuration publishing server writes the updated local valid time to multiple instances to be updated and recalculates the effective time based on the original timezone information of each instance. Therefore, multiple instances to be updated can use the same updated local valid time while retaining an effective time that matches their respective timezones.

[0071] For example, the primary instance corresponds to time zone one, two active associated instances correspond to time zones two and three respectively, and another associated instance is offline. The configuration update request modifies the function control parameter from the first parameter value to the second parameter value and changes the local effective time from 10:00 to 12:00. The configuration publishing server writes the second parameter value to the primary instance and the two active associated instances, re-determines the effective time according to time zones one, two, and three respectively, and retains a portion of the target range for each of the three instances to be updated. The offline associated instance does not participate in this update.

[0072] In one possible implementation, after configuring the publishing server to apply the update data to multiple instances to be updated, it can be done according to... Figure 4 The method shown performs audience conflict checking on an instance-by-instance basis. Instance-by-instance execution can be sequential or parallel execution followed by summarizing the results. If any instance to be updated fails the audience conflict check, the corresponding instance can be determined as having failed the update, and the update transaction can be rolled back; once all instances to be updated have completed data writing and passed the audience conflict check, the update transaction is committed.

[0073] After the update transaction is committed, the common configuration fields of the primary instance and all valid associated instances take effect simultaneously, and the configuration publishing server then releases the batch lock. Figure 4 In the corresponding implementation, after the update transaction is successfully committed, a full group configuration release can be triggered, causing multiple updated instance versions to generate corresponding configurations and uniformly enter the release process. The full group configuration release can be executed immediately, or it can be executed according to a scheduled release time or a preset release strategy.

[0074] When any instance to be updated experiences a configuration data write failure, an effective time conversion failure, an abnormal version status, or an audience conflict verification failure, the configuration publishing server rolls back the update transaction, undone the modifications already performed on other instances to be updated, and releases the batch lock. Figure 4 The "whole group rollback" in the context corresponds to the rollback processing of update transactions. By rolling back the whole group, it is possible to avoid situations where the primary instance has already adopted the updated configuration content, while some related instances still retain the original configuration content or the original effective time.

[0075] By limiting concurrent modifications within the same batch through batch locks and applying configuration updates synchronously to the primary instance and all valid associated instances through update transactions, multiple physical experimental instances can adopt consistent configuration content and local valid time while retaining partial target range and time zone information corresponding to different instances. This reduces instance configuration drift caused by concurrent operations or partial update failures.

[0076] In one possible embodiment, the batch lock may include a lock holder identifier, a locking time, and a lock expiration period. If the configuration publishing server fails to acquire the batch lock within a preset waiting time, it can return a message indicating that the batch is being processed or add the configuration update request to the waiting queue. If the batch lock expires and the original operation is not continued, the batch lock can be released according to the transaction status to avoid abnormal interruption causing the batch to be unable to be updated for a long time.

[0077] Optionally, the above method may further include the following steps: in response to a version addition request for the primary instance, acquiring a batch lock based on the batch association relationship and initiating a version transaction; determining multiple version instances to be generated from the primary instance and associated instances in a valid state; determining a unified target version sequence number based on the current version information of the multiple version instances to be generated; generating instance versions with target version sequence numbers for the multiple version instances to be generated in the version transaction; committing the version transaction if all instance versions are successfully generated; and rolling back the version transaction if any instance version generation fails.

[0078] In this embodiment of the invention, the version update request can be initiated by the configuration management terminal through the unified entry point corresponding to the main instance, which is used to uniformly generate a new instance version for the main instance and each valid associated instance in the same batch. Figure 4 The "Initiate operation from the main experiment entry" and "normal version addition" branches in the process correspond to the processing of version addition requests. "Unified addition of the same display version to all active chains in the group" corresponds to generating instance versions with a unified target version number for multiple version instances to be generated.

[0079] A regular version addition adds a version to the current batch without changing the batch membership or the target range of each physical experiment instance. Unlike configuration updates, which directly modify the current instance version of each physical experiment instance, a regular version addition creates a new instance version record for each instance to be generated. Unlike version replication, a regular version addition does not adjust the composition of physical experiment instances corresponding to countries, cities, or time zones. A version addition request can include the primary instance identifier, the current version identifier used as the basis for generation, and the request identifier.

[0080] After receiving a version update request, the configuration release server acquires a batch lock based on the batch identifier corresponding to the primary instance, and then queries the primary instance and its active associated instances according to the batch association relationship. Associated instances that have been taken offline, removed, or are no longer participating in batch operations are not included in this version update. The primary instance and the retrieved active associated instances together constitute multiple version instances to be generated.

[0081] A version transaction can be a transaction processing unit established by the configuration and release server for a single group-level version addition. It is used to incorporate the determination of the target version number, the generation of multiple instance versions, the update of the current version pointer, and related verification operations into the same atomic processing scope. Before the version transaction is committed, the newly generated instance version is in a pending-commit state and cannot be queried or released as a formal version. When multiple instance versions are successfully generated, they are committed together; if any instance version fails to be generated, the data generated by this version addition is rolled back. Therefore, a version transaction corresponds to the complete processing boundary for the same batch, from determining the target version number to the overall effectiveness of multiple instance versions.

[0082] The current version information can include the current instance version identifier, current version sequence number, version status, and latest version pointer for each instance to be generated. The version sequence number can be an integer or a sortable code used to display and identify the order of instance versions on the configuration management side. The configuration publishing server can read the current version sequence numbers of multiple instances to be generated, determine the largest current version sequence number, and add a preset increment to the largest current version sequence number to obtain the target version sequence number. The target version sequence number is determined only once and is used collectively for all instance versions generated in this version transaction.

[0083] For example, if the current version numbers of the primary instance and two valid associated instances are three, three, and two respectively, the configuration publishing server can increment the current maximum version number three by one to obtain the target version number four. Subsequently, the configuration publishing server creates instance versions with version number four for each of the three instances to be generated. The new instance versions corresponding to different physical experiment instances can have different instance version identifiers, but use the same target version number, thus enabling the configuration management terminal to identify multiple instance versions as versions generated from the same group-level version update.

[0084] When generating instance versions, the configuration publishing server can copy the current instance version data of the instance to be generated and assign a new instance version identifier and target version sequence number to the copied data. The new instance version of the primary instance can inherit the configuration content, some target ranges, time zone information, and effective time from the current version of the primary instance. The new instance versions of each associated instance inherit the configuration content, some target ranges, time zone information, and effective time from the current version of their respective associated instances. Therefore, the newly generated multiple instance versions use a unified target version sequence number, while still retaining the regional and time zone differences corresponding to each physical experiment instance.

[0085] In one possible implementation, the version update request may also carry new version data that needs to be applied to the new instance version. The configuration publishing server can write the common configuration fields from the new version data into multiple new instance versions, while retaining some of the original target range and time zone information of each instance to be generated. When the new version data includes local valid time, the effective time of the new instance version can be determined according to the time zone information of each instance to be generated.

[0086] After configuring the publishing server to generate instance versions for multiple pending version instances, you can proceed according to... Figure 4 The method shown performs audience conflict verification on an instance-by-instance basis. If any new instance version fails the audience conflict verification, the corresponding instance version can be determined as a failed generation, and the version transaction is not committed; when all new instance versions are successfully generated and pass the verification, the version transaction is committed, so that multiple new instance versions take effect simultaneously, and the latest version pointer of each instance to be generated is updated to the corresponding new instance version.

[0087] When any new instance version fails to copy data, generate version identifier, write target version sequence number, or verify version data, the configuration publishing server rolls back the version transaction, deletes or invalidates the new instance version that has been generated but not yet committed, and restores the latest version pointer of each pending version instance to the state before the version transaction started. Figure 4 The "whole group rollback" in the configuration corresponds to the rollback process of the version transaction. After the version transaction is committed or rolled back, the configuration release server releases the batch lock.

[0088] exist Figure 4 In the corresponding implementation, after a version transaction is successfully committed, a full group configuration release can be triggered, causing multiple instance versions using the target version number to uniformly enter the configuration generation and release process. The full group configuration release can also be postponed based on version status, scheduled release time, or manual confirmation results.

[0089] By determining a unified target version number based on the current version information of multiple instances to be generated, and generating instance versions with the same version number for the main instance and each valid associated instance in the same version transaction, it is possible to avoid the situation where the main instance has added a new version while some associated instances remain on the original version, thus ensuring that multiple physical experiment instances in the same batch are managed and released according to a unified version standard.

[0090] In one possible implementation, the configuration publishing server can store the most recently allocated version number in the batch record and generate the target version number atomically during the holding of the batch lock. Version addition requests can also carry an idempotent flag; when the same version addition request is submitted repeatedly, the configuration publishing server can return the already generated target version number and instance version information, avoiding duplicate creation of group-level versions.

[0091] Optionally, the version addition request is a version replication request carrying the updated target range; in the version transaction, before determining multiple version instances to be generated, the original target range corresponding to the replicated version can be obtained according to the batch association relationship; the target regions in the original target range and the updated target range are grouped according to the regional affiliation information and time zone information respectively to obtain the original materialized target set and the updated materialized target set; according to the regional affiliation information and time zone information corresponding to each materialized target, the original materialized target set and the updated materialized target set are compared to obtain topology difference information, which is used to indicate the addition of materialized targets and the materialization of some target ranges that have changed. At least one of the target and removed materialized targets; adjust the physical experiment instances in the batch association relationship according to the topology difference information, wherein, when the topology difference information indicates the addition of a new materialized target, create a physical experiment instance corresponding to the new materialized target and add the created physical experiment instance to the batch association relationship; when the topology difference information indicates that the range of some materialized targets has changed, adjust the range of some targets of the corresponding physical experiment instance; when the topology difference information indicates the removal of a materialized target, prevent the corresponding physical experiment instance from participating in the addition of this version; determine the physical experiment instances that participate in the addition of this version after adjustment as multiple version instances to be generated.

[0092] In this embodiment of the invention, a version replication request can be used to generate a new group-level version based on an existing instance version, and allows the configuration management terminal to adjust the target scope during the replication process. The version replication request may include the primary instance identifier, the replicated version identifier, the updated target scope, and the configuration content to be written to the new version. Figure 4The "Copy Version" branch corresponds to the overall processing of version copy requests. "Compare Market and City Topology Before and After Copying" corresponds to the comparison between the original materialized target set and the updated materialized target set. "Add Chain, Remove Chain or Adjust City Range" corresponds to adjusting physical experiment instances based on topology difference information.

[0093] The configuration and deployment server can query the primary instance and associated instances of the replicated version based on the replicated version identifier and batch association, and obtain a partial target range for each physical experiment instance under the replicated version. The configuration and deployment server then merges these partial target ranges to obtain the original target range corresponding to the replicated version. The original target range is not merely the partial target range corresponding to the primary instance, but rather a summary of the partial target ranges corresponding to multiple physical experiment instances in the replicated version. The original target range can include forward target areas, excluded target areas, and their area affiliation information.

[0094] The configuration and publishing server grouped the target areas within the original and updated target ranges according to the same regional base data and grouping rules. Target areas with the same regional affiliation information and time zone information were grouped into the same materialized target, thus obtaining the original set of materialized targets and the updated set of materialized targets. Figure 6 The "analyze the target market before and after replication and make topological differences" in the text corresponds to target range acquisition, target region grouping, and comparison of materialized target sets.

[0095] Topology can represent the number of materialized targets in a batch, the region affiliation information and time zone information corresponding to each materialized target, and the distribution relationship of target regions among the materialized targets. The configuration and publishing server can use the combination of region affiliation information and time zone information as the combination identifier of the materialized targets, and compare the original set of materialized targets and the updated set of materialized targets based on the combination identifier. When a combination identifier exists only in the updated set of materialized targets, it is determined that a new materialized target exists; when a combination identifier exists in both sets, but the corresponding target ranges are different, it is determined that a materialized target with a changed target range exists; when a combination identifier exists only in the original set of materialized targets, it is determined that a materialized target needs to be removed.

[0096] Changes in target countries, cities, or time zones can be converted into corresponding topological difference information. When a new country is added, the configuration publishing server can generate one or more new materialized targets based on the time zones involved in the target region within that country. When an existing country adds a time zone that is not present in the original set of materialized targets, a new materialized target consisting of that country and the new time zone can be generated. When the regional affiliation information and time zone information corresponding to a new city already exist in the original set of materialized targets, it can be determined that the target range of some of the corresponding materialized targets has changed; if no identical combination exists, it can be determined that a new materialized target exists.

[0097] When a country is removed, one or more materialized targets in the original set of materialized targets corresponding to that country can be identified as removed materialized targets. If, after removing a city, the original materialized target still includes other target areas, it can be determined that the target range of the corresponding materialized target has changed; if, after removing a city, the corresponding materialized target no longer includes any positive target areas, the materialized target can be identified as removed materialized target. Figure 6 The terms “countries removed”, “cities removed”, “cities added”, and “countries added” correspond to the specific manifestations of the aforementioned topological differences.

[0098] When topology difference information indicates the addition of a materialized target, the configuration release server creates a physical experiment instance corresponding to the new materialized target within the version transaction. It assigns an instance identifier to the newly created physical experiment instance and writes the corresponding region affiliation information, time zone information, and partial target range. The configuration release server can also add a corresponding member record to the batch member table, adding the newly created physical experiment instance as an associated instance to the existing batch association. For adding a new country or time zone, it can be done according to... Figure 6 The method shown involves creating a new associated instance from the animal and writing the batch membership relationship.

[0099] When topology difference information indicates that the scope of a materialized target has changed, the configuration publishing server can write the adjusted target scope into the new instance version of the corresponding physical experiment instance without modifying the historical instance version that has already taken effect or been published. When a new city is added and a physical experiment instance with the same regional affiliation and time zone information already exists in the batch, the new city will be merged into the new instance version of that physical experiment instance; when a city is removed and the corresponding physical experiment instance still includes other target regions, the corresponding city will be removed from the new instance version of that physical experiment instance. Physical experiment instances with the same time zone but different regional affiliation information are not used to merge newly added cities to maintain the one-to-one correspondence between physical experiment instances and materialized targets.

[0100] When topology difference information indicates the removal of a materialized target, the configuration publishing server can mark the corresponding physical experiment instance as not participating in this version update, and will no longer generate a new instance version with the target version number for that physical experiment instance. The corresponding physical experiment instance and its historical instance versions will continue to be retained to support historical configuration queries and hit result tracing. For physical experiment instances corresponding to the removed country, the member status can also be adjusted to offline, so that they will no longer participate in subsequent configuration publishing. Figure 6 The phrase "the country is taken offline from the chain and will not participate in the new version" corresponds to the removal of materialized targets.

[0101] After the topology adjustment is completed, the physical experiment instances added in this version can include some existing physical experiment instances whose target range has not changed, some existing physical experiment instances whose target range has changed, and physical experiment instances created for newly added materialized targets, but not physical experiment instances corresponding to removed materialized targets. The configuration and release server will identify the above physical experiment instances as multiple version instances to be generated, and perform group-level version addition according to the target version number determination method already explained. Both newly created physical experiment instances and existing physical experiment instances will generate instance versions with a unified target version number.

[0102] For example, the copied version includes three physical experiment instances: the first physical experiment instance corresponds to country A, time zone 1, and cities A and B; the second physical experiment instance corresponds to country A, time zone 2, and city C; and the third physical experiment instance corresponds to country B, time zone 3, and city D. After the update, country B and city B are removed from the target scope, city E is added to time zone 2 of country A, and city F corresponding to time zone 4 of country C is added. The configuration publishing server can remove city B from the new instance version of the first physical experiment instance, merge city E into the new instance version of the second physical experiment instance, prevent the third physical experiment instance from participating in this version addition, and create a fourth physical experiment instance for the new materialized target consisting of country C and time zone 4. After the adjustment, the first, second, and fourth physical experiment instances are determined as the version instances to be generated.

[0103] like Figure 4 and Figure 6 As shown, after completing topology adjustments and instance version generation, the configuration release server can perform target area mutual exclusion checks and audience conflict checks on each of the new physical experiment instances participating in this version. When all physical experiment instances are successfully processed, the version transaction is committed, making the new physical experiment instance, batch membership relationship, instance status adjustment, and new instance version take effect simultaneously, and can trigger a full group configuration release, including the new physical experiment instance. If any physical experiment instance creation fails, part of the target range adjustment fails, instance version generation fails, or verification fails, the version transaction is rolled back, and the new physical experiment instance, batch membership relationship changes, instance status changes, and already generated instance versions are undone.

[0104] By comparing the original and updated materialized target sets, changes in target countries, cities, and time zones can be uniformly converted into new materialized targets, partial target range changes, and removed materialized targets. Based on this, the addition, range adjustment, and exit processing of physical experiment instances can be automatically completed. Therefore, when copying versions, there is no need to manually create, take offline, or modify physical experiment instances one by one, and version transactions can prevent inconsistencies between batch members and the new version's coverage caused by only partially adjusting the target range topology.

[0105] In one possible implementation, when the primary instance corresponding to a materialized target is removed, the configuration publishing server can re-determine the primary instance from among the physical experiment instances that continue to participate in the current version's additions and update the batch member roles in the version transaction; if no physical experiment instances continue to participate in the current version's additions, version replication can be terminated. The configuration publishing server can also set data version identifiers for regional basic data and generate the original materialized target set and the updated materialized target set using the same data version, reducing unexpected topological differences caused by changes in regional affiliation or time zone data during the comparison process.

[0106] Optionally, the release identifier includes an experiment identifier and a version identifier. In the step of setting the same release identifier for multiple target experiment configurations and releasing multiple target experiment configurations, the release versions corresponding to the master instance and each associated instance in a valid state can be obtained according to the batch association relationship. The version number and configuration content of multiple release versions are checked for consistency. If the consistency check passes, the experiment identifier and version identifier of the release version corresponding to the master instance are determined as the group experiment identifier and group version identifier, respectively. While retaining some target range, time zone information and effective time corresponding to each target experiment configuration, the experiment identifier and version identifier of multiple target experiment configurations are set as the group experiment identifier and group version identifier, respectively, and multiple target experiment configurations are released.

[0107] In this embodiment of the invention, the experiment identifier can be used to distinguish different physical experiment instances, and the version identifier can be used to distinguish different instance versions under the same physical experiment instance. The version identifier and the version sequence number have different meanings. The version identifier can be a unique code for the instance version in the data storage layer, while the version sequence number is used to indicate the order of instance versions or the group-level display order. Multiple physical experiment instances corresponding to release versions can have different experiment identifiers and version identifiers, but should have the same version sequence number.

[0108] The configuration release server can query batch member records based on the batch identifier corresponding to the primary instance to obtain the primary instance and each associated instance in a valid state, and then determine the release version from the instance versions of each physical experiment instance. The release version can be an instance version that has completed version generation and related verification but has not yet been released, or is awaiting its scheduled release time. For the same group-level release, each valid physical experiment instance should have a release version corresponding to the target version number. If any valid physical experiment instance does not have a corresponding release version, or if multiple release versions with uncertain release order exist simultaneously, it can be determined that this release does not meet the integrity requirements.

[0109] Consistency checks are used to determine whether multiple release versions belong to the same group-level version generation and whether common configuration fields in multiple release versions are consistent. The configuration release server can compare the version numbers of each release version; if all version numbers are the same, the version numbers are considered consistent. Consistency checks on configuration content can include at least one of the following: grouping parameters, experiment parameters, traffic splitting configuration, traffic ratio, function control parameters, and common audience conditions. However, it does not include the target range, time zone information, data center information, and effective time that need to be retained separately for each physical experiment instance.

[0110] The configuration publishing server can serialize the configuration content participating in consistency verification according to a preset field order and calculate a configuration digest from the serialization result. If the configuration digests of all versions to be published are the same, the configuration content is considered consistent; if the configuration digests differ, specific fields can be further compared and difference information generated. The difference information can include the physical experimental instance where the difference occurred, the instance version identifier, and the configuration fields. If the version number or configuration content of any version to be published is inconsistent, the configuration publishing server can prohibit this publication to prevent associated instances from using configuration content inconsistent with the primary instance, yet publishing with the primary instance's experimental identifier and version identifier.

[0111] Figure 5 The "multiple physical experiment configurations within a group" in the configuration file correspond to multiple target experiment configurations generated based on multiple release versions. These multiple target experiment configurations still originate from the primary instance and each associated instance at the data storage layer, and can retain their respective internal experiment identifiers and internal version identifiers. After the consistency check passes, the configuration release server determines the experiment identifier of the release version corresponding to the primary instance as the group experiment identifier, and determines the version identifier of the release version corresponding to the primary instance as the group version identifier.

[0112] Figure 5 The "Replace the primary experiment ID and primary version ID when publishing from the chain" option corresponds to setting the experiment identifier and version identifier in the target experiment configuration generated by the associated instance to the group experiment identifier and group version identifier, respectively. The experiment identifier and version identifier originally carried by the target experiment configuration generated by the primary instance are the same as the group experiment identifier and group version identifier, and can remain unchanged. The identifier setting only changes the experiment identifier and version identifier provided by the target experiment configuration to the client, and does not change the data source or internal storage relationship of the target experiment configuration.

[0113] When setting the identifier, the target range, time zone information and effective time of each target experiment configuration remain unchanged. Figure 5The "Retain the time zone, country, and city range of the chain itself" option corresponds to retaining the instance-specific fields of the associated instance. After the configuration publishing server completes the identifier settings, it publishes the configurations of multiple target experiments to the configuration center or object storage, so that the client can still select the matching configuration based on the region and time zone conditions corresponding to each target experiment configuration.

[0114] Client requests can carry country and city information. The client filters multiple target experiment configurations based on the country, city, time zone, and current time of the request. When the client hits a target experiment configuration generated by the associated instance, the read experiment identifier and version identifier have been set as the group experiment identifier and group version identifier, so the uploaded hit result carries the experiment identifier and version identifier corresponding to the main instance. Figure 5 The "Report Main Experiment ID and Main Version ID" in the text corresponds to the above-mentioned hit result reporting process. If the client does not hit any target experiment configuration, it will not enter the corresponding experiment, nor will it upload the corresponding hit result.

[0115] For example, the primary instance corresponds to the experiment identifier E100 and the version identifier V100 for the version to be released. The two associated instances correspond to the experiment identifiers E200 and E300 for the versions to be released, and the version identifiers V200 and V300 for the versions to be released, respectively. All three versions to be released have a version number of five and identical configuration content. The configuration release server can designate E100 as the group experiment identifier and V100 as the group version identifier. After release, all three target experiment configurations will externally carry E100 and V100, but will retain their respective target city, time zone, and effective time. When a client hits the target experiment configuration originating from the second associated instance, it will still upload E100 and V100.

[0116] When any of the three release versions uses a different version number, or when the grouping parameters, traffic splitting configuration, or other configuration content differs from other release versions, the configuration release server will not perform release identifier replacement or configuration release, and can return the physical experiment instance and configuration fields that differ. This avoids situations where multiple physical experiment instances actually execute different configuration content, but the client reports the same experiment identifier and version identifier, resulting in the hit results not accurately reflecting the configuration execution status.

[0117] By performing consistency checks on multiple release versions before setting the group experiment identifier and group version identifier, it can be ensured that multiple target experiment configurations using the same release identifier have consistent version definitions and configuration content. By only replacing the external experiment identifier and version identifier, while retaining some target range, time zone information, and effective time corresponding to each target experiment configuration, clients can hit the corresponding target experiment configuration according to different regions and time zones. At the same time, the hit results generated by different physical experiment instances are uniformly aggregated to the experiment and version corresponding to the main instance.

[0118] In one possible implementation, the configuration publishing server can retain the experiment identifier and version identifier of the original physical experiment instance in the internal publishing metadata of the target experiment configuration for configuration tracking, fault location, and release rollback. The configuration fields that the client can read only include the group experiment identifier and group version identifier. The configuration publishing server can also lock batch version snapshots during consistency verification and configuration publishing to prevent changes to the version to be published after verification but before configuration publishing.

[0119] 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.

[0120] In one embodiment, a multi-timezone experiment configuration publishing device is provided, which corresponds one-to-one with the multi-timezone experiment configuration publishing method described in the above embodiments. For example... Figure 7 As shown, the multi-timezone experimental configuration publishing device includes an acquisition module 701, a generation module 702, and a publishing module 703. Detailed descriptions of each functional module are as follows: The acquisition module 701 is used to acquire the configuration of the experiment to be published, which includes the configuration content, target range and local validity time. The generation module 702 is used to generate multiple target experiment configurations based on the correspondence between the target range and multiple time zones, wherein each target experiment configuration adopts a single time zone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a partial target range associated with the corresponding time zone, and an effective time determined according to the local effective time and the corresponding time zone. The publishing module 703 is used to set the same publishing identifier for multiple target experiment configurations and to publish multiple target experiment configurations. The publishing identifier is used by the client to report the hit result.

[0121] Optionally, the target range includes multiple target regions; the generation module 702 is further configured to: Obtain the region affiliation information and time zone information of each target region; Multiple materialized targets are generated according to the regional affiliation information and the time zone information, wherein each materialized target corresponds to a combination of regional affiliation information and time zone information, and includes a portion of the target range corresponding to the combination; Perform mutual exclusion checks on the partial target ranges corresponding to multiple materialized targets to determine whether there are target regions that simultaneously belong to at least two of the materialized targets; If the mutual exclusion check passes, multiple target experiment configurations are generated based on the experimental configuration to be released, according to the multiple materialized targets.

[0122] Optionally, the generation module 702 is further configured to: In the same materialization transaction, multiple physical experiment instances are created for multiple materialization targets, wherein each physical experiment instance corresponds to one materialization target; The configuration content is written into multiple physical experiment instances. The partial target range corresponding to each physical experiment instance is determined according to the corresponding materialization target. The local effective time is converted according to the time zone information of the corresponding materialization target to obtain the effective time corresponding to each physical experiment instance. Establish batch association relationships among multiple physical experiment instances, determine a master instance from the multiple physical experiment instances, and determine the remaining physical experiment instances as associated instances; Audience conflict verification was performed on multiple instances of the physical experiment. If all of the physical experiment instances are successfully created and pass the audience conflict check, the materialization transaction is submitted, and multiple target experiment configurations are generated based on the multiple physical experiment instances respectively. If any of the physical experiment instances fails to be created or fails the audience conflict check, the materialized transaction is rolled back.

[0123] Optionally, the device is further used for: In response to the configuration update request for the primary instance, a batch lock is acquired according to the batch association relationship, and the primary instance and the associated instances in the valid state are identified as multiple instances to be updated. The configuration update request includes update data, and the update data includes at least one of the updated configuration content and the updated local validity time. In the same update transaction, while retaining the partial target range and time zone information corresponding to each instance to be updated, the update data is applied to multiple instances to be updated respectively. When the update data includes updated configuration content, the updated configuration content is written to multiple instances to be updated. When the update data includes updated local effective time, the updated effective time is determined according to the time zone information corresponding to each instance to be updated. If all of the instances to be updated are successfully updated, the update transaction is committed. If any of the instances to be updated fails to update, the update transaction is rolled back.

[0124] Optionally, the device is further used for: In response to a version update request for the primary instance, a batch lock is acquired based on the batch association, and a version transaction is initiated. Multiple version instances to be generated are determined from the main instance and the associated instances that are in a valid state; A unified target version number is determined based on the current version information of multiple instances of the version to be generated; In the version transaction, instance versions with the target version number are generated for each of the multiple instances of the version to be generated; If all of the aforementioned instance versions are successfully generated, the version transaction shall be committed; If any instance version generation fails, the version transaction is rolled back.

[0125] Optionally, the version addition request is a version replication request carrying the updated target range; in the version transaction, before determining multiple version instances to be generated, the device is further configured to: Based on the batch association relationship, obtain the original target range corresponding to the copied version; The target regions in the original target range and the updated target range are grouped according to the region affiliation information and the time zone information, respectively, to obtain the original materialized target set and the updated materialized target set; Based on the regional affiliation information and time zone information corresponding to each materialized target, the original set of materialized targets and the updated set of materialized targets are compared to obtain topological difference information. The topological difference information is used to indicate at least one of the following: newly added materialized targets, materialized targets whose ranges have changed, and removed materialized targets. The physical experiment instances in the batch association are adjusted according to the topology difference information. Specifically, when the topology difference information indicates the addition of a new materialized target, a physical experiment instance corresponding to the new materialized target is created, and the created physical experiment instance is added to the batch association. When the topology difference information indicates that some target ranges of a materialized target have changed, the target ranges of the corresponding physical experiment instance are adjusted. When the topology difference information indicates the removal of a materialized target, the corresponding physical experiment instance is excluded from the current version update. The adjusted physical experiment instances that will be added in this version will be determined as multiple instances of the version to be generated.

[0126] Optionally, the release identifier includes an experimental identifier and a version identifier; the release module 703 is further configured to: Based on the batch association relationship, obtain the release version corresponding to the main instance and each associated instance that is in a valid state; Perform consistency checks on the version numbers and configuration content of multiple versions to be released; If the consistency check passes, the experiment identifier and version identifier of the release version corresponding to the main instance will be determined as the group experiment identifier and group version identifier, respectively. While retaining the target range, time zone information and effective time corresponding to each target experiment configuration, the experiment identifier and version identifier of multiple target experiment configurations are set as the group experiment identifier and the group version identifier, respectively, and multiple target experiment configurations are published.

[0127] Each module in the aforementioned multi-timezone experimental configuration and distribution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0128] In one embodiment, a computer device is provided, which may be a terminal device, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a readable storage medium storing computer-readable instructions. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a multi-timezone experimental configuration deployment method. The readable storage medium provided in this embodiment includes both non-volatile and volatile readable storage media.

[0129] In one embodiment of the application, a readable storage medium is provided, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, they implement the steps of the multi-timezone experimental configuration release method described above.

[0130] 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 instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When executed, these computer-readable instructions can include the processes of the embodiments of the methods described above. 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 may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of 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.

[0131] 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.

[0132] The above 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 method for deploying multi-timezone experimental configurations, applied to a configuration deployment server, characterized in that, The method includes: Obtain the configuration of the experiment to be published, which includes the configuration content, target range, and local validity period; Based on the correspondence between the target range and multiple time zones, multiple target experiment configurations are generated based on the experiment configuration to be released. Each target experiment configuration adopts a single time zone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a partial target range associated with the corresponding time zone, and an effective time determined based on the local effective time and the corresponding time zone. Set the same release identifier for multiple target experiment configurations, and release multiple target experiment configurations. The release identifier is used by the client to report the hit result.

2. The multi-timezone experimental configuration and release method according to claim 1, characterized in that, The target range includes multiple target regions; the generation of multiple target experimental configurations based on the correspondence between the target range and multiple time zones, and the experimental configuration to be released, includes: Obtain the region affiliation information and time zone information of each target region; Multiple materialized targets are generated according to the regional affiliation information and the time zone information, wherein each materialized target corresponds to a combination of regional affiliation information and time zone information, and includes a portion of the target range corresponding to the combination; Perform mutual exclusion checks on the partial target ranges corresponding to multiple materialized targets to determine whether there are target regions that simultaneously belong to at least two of the materialized targets; If the mutual exclusion check passes, multiple target experiment configurations are generated based on the experimental configuration to be released, according to the multiple materialized targets.

3. The multi-timezone experimental configuration and release method according to claim 2, characterized in that, The step of generating multiple target experiment configurations based on the experiment configuration to be released, according to multiple materialized targets, includes: In the same materialization transaction, multiple physical experiment instances are created for multiple materialization targets, wherein each physical experiment instance corresponds to one materialization target; The configuration content is written into multiple physical experiment instances. The partial target range corresponding to each physical experiment instance is determined according to the corresponding materialization target. The local effective time is converted according to the time zone information of the corresponding materialization target to obtain the effective time corresponding to each physical experiment instance. Establish batch association relationships among multiple physical experiment instances, determine a master instance from the multiple physical experiment instances, and determine the remaining physical experiment instances as associated instances; Audience conflict verification was performed on multiple instances of the physical experiment. If all of the physical experiment instances are successfully created and pass the audience conflict check, the materialization transaction is submitted, and multiple target experiment configurations are generated based on the multiple physical experiment instances respectively. If any of the physical experiment instances fails to be created or fails the audience conflict check, the materialized transaction is rolled back.

4. The multi-timezone experimental configuration and release method according to claim 3, characterized in that, The method further includes: In response to the configuration update request for the primary instance, a batch lock is acquired according to the batch association relationship, and the primary instance and the associated instances in the valid state are identified as multiple instances to be updated. The configuration update request includes update data, and the update data includes at least one of the updated configuration content and the updated local validity time. In the same update transaction, while retaining the partial target range and time zone information corresponding to each instance to be updated, the update data is applied to multiple instances to be updated respectively. When the update data includes updated configuration content, the updated configuration content is written to multiple instances to be updated. When the update data includes updated local effective time, the updated effective time is determined according to the time zone information corresponding to each instance to be updated. If all of the instances to be updated are successfully updated, the update transaction is committed. If any of the instances to be updated fails to update, the update transaction is rolled back.

5. The multi-timezone experimental configuration and release method according to claim 3, characterized in that, The method further includes: In response to a version update request for the primary instance, a batch lock is acquired based on the batch association, and a version transaction is initiated. Multiple version instances to be generated are determined from the main instance and the associated instances that are in a valid state; A unified target version number is determined based on the current version information of multiple instances of the version to be generated; In the version transaction, instance versions with the target version number are generated for each of the multiple instances of the version to be generated; If all of the aforementioned instance versions are successfully generated, the version transaction shall be committed; If any instance version generation fails, the version transaction is rolled back.

6. The multi-timezone experimental configuration release method according to claim 5, characterized in that, The version addition request is a version replication request carrying the updated target range; in the version transaction, before determining multiple version instances to be generated, the method further includes: Based on the batch association relationship, obtain the original target range corresponding to the copied version; The target regions in the original target range and the updated target range are grouped according to the region affiliation information and the time zone information, respectively, to obtain the original materialized target set and the updated materialized target set; Based on the regional affiliation information and time zone information corresponding to each materialized target, the original set of materialized targets and the updated set of materialized targets are compared to obtain topological difference information. The topological difference information is used to indicate at least one of the following: newly added materialized targets, materialized targets whose ranges have changed, and removed materialized targets. The physical experiment instances in the batch association are adjusted according to the topology difference information. Specifically, when the topology difference information indicates the addition of a new materialized target, a physical experiment instance corresponding to the new materialized target is created, and the created physical experiment instance is added to the batch association. When the topology difference information indicates that some target ranges of a materialized target have changed, the target ranges of the corresponding physical experiment instance are adjusted. When the topology difference information indicates the removal of a materialized target, the corresponding physical experiment instance is excluded from the current version update. The adjusted physical experiment instances that will be added in this version will be determined as multiple instances of the version to be generated.

7. The multi-timezone experimental configuration and release method according to claim 3, characterized in that, The release identifier includes an experiment identifier and a version identifier; setting the same release identifier for multiple target experiment configurations and releasing multiple target experiment configurations includes: Based on the batch association relationship, obtain the release version corresponding to the main instance and each associated instance that is in a valid state; Perform consistency checks on the version numbers and configuration content of multiple versions to be released; If the consistency check passes, the experiment identifier and version identifier of the release version corresponding to the main instance will be determined as the group experiment identifier and group version identifier, respectively. While retaining the target range, time zone information and effective time corresponding to each target experiment configuration, the experiment identifier and version identifier of multiple target experiment configurations are set as the group experiment identifier and the group version identifier, respectively, and multiple target experiment configurations are published.

8. A multi-timezone experimental configuration publishing device, applied to a configuration publishing server, characterized in that, The device includes: The acquisition module is used to acquire the configuration of the experiment to be published, which includes the configuration content, target range, and local validity period. The generation module is used to generate multiple target experiment configurations based on the correspondence between the target range and multiple time zones, according to the experimental configuration to be released. Each target experiment configuration adopts a single time zone configuration format supported by the client, corresponds to one of the multiple time zones, and includes the configuration content, a partial target range associated with the corresponding time zone, and an effective time determined according to the local effective time and the corresponding time zone. The publishing module is used to set the same publishing identifier for multiple target experiment configurations and to publish multiple target experiment configurations. The publishing identifier is used by the client to report the hit result.

9. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, characterized in that, When the processor executes the computer-readable instructions, it implements the multi-timezone experimental configuration release method as described in any one of claims 1 to 7.

10. A readable storage medium having computer-readable instructions stored thereon, characterized in that, When the computer-readable instructions are executed by the processor, they implement the multi-timezone experimental configuration release method as described in any one of claims 1 to 7.

Images