Data synchronization method and apparatus, electronic device, storage medium, and program product

Abstract

This application provides a data synchronization method, apparatus, electronic device, storage medium, and program product. The method includes: in response to triggering a data synchronization command, obtaining raw full-volume cloud storage data from at least one target cloud service provider; converting the raw full-volume cloud storage data into a target format based on a data format unification model, wherein the data format unification model is used to convert data of the same data resource type from different cloud service providers into a unified data format; comparing the target format full-volume cloud storage data with full-volume local data in the vehicle manufacturer's local database to obtain a comparison result; and synchronizing the vehicle manufacturer's local database based on the comparison result. This application solves the technical problem of low accuracy in synchronizing data to a vehicle manufacturer's local database in related technologies.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to a data synchronization method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of connected vehicle services, the demand for computing resources such as servers, storage, and bandwidth from existing and new connected vehicle remote service providers is dynamically increasing. However, in current operation and maintenance management, the deployment of business resources is highly heterogeneous, including physical assets such as self-built internet data centers and leased resources in multi-cloud environments from different cloud vendors, resulting in scattered resource information across various business systems. Existing multi-cloud synchronization solutions for automakers' local databases have not addressed the pain point of accurate data synchronization across cloud vendors, making it difficult to meet the automated operation and maintenance needs of large-scale, highly dynamic connected vehicle environments. In other words, the accuracy of data synchronization for automakers' local databases is relatively low.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a data synchronization method, apparatus, electronic device, storage medium, and program product to at least solve the technical problem of low accuracy in synchronizing local databases of car manufacturers in related technologies.

[0005] According to one aspect of the embodiments of this application, a data synchronization method is provided, comprising: in response to triggering a data synchronization instruction, obtaining raw full cloud storage data from at least one target cloud service provider; converting the raw full cloud storage data into a target format based on a data format unification model, wherein the data format unification model is used to convert data of the same data resource type from different cloud service providers into a unified data format; comparing the target format full cloud storage data with full local data in a vehicle manufacturer's local database to obtain a comparison result; and synchronizing the vehicle manufacturer's local database based on the comparison result.

[0006] In this embodiment of the application, obtaining raw full cloud storage data from at least one target cloud service provider includes: calling a target proxy model corresponding to at least one target cloud service provider from multiple proxy models; and accessing data from at least one target cloud service provider based on the target proxy model to obtain the raw full cloud storage data.

[0007] In this embodiment of the application, calling the target proxy model corresponding to at least one target cloud service provider from multiple proxy models includes: determining the provider identification information corresponding to at least one target cloud service provider; and calling the target proxy model from multiple proxy models based on the provider identification information.

[0008] In this embodiment of the application, based on the target proxy model, data access is performed on at least one target cloud service provider to obtain the original full cloud storage data, including: parsing the data synchronization instruction to determine the data resource type to be synchronized; and based on the target proxy model, calling the resource type encapsulation interface corresponding to the data resource type to obtain the original full cloud storage data.

[0009] In this embodiment of the application, based on the target proxy model, the resource type encapsulation interface corresponding to the data resource type is called to obtain the original full cloud storage data. This includes: based on the target proxy model, calling the resource type encapsulation interface corresponding to the data resource type, and access credential information corresponding to at least one target cloud service provider, to access the data from at least one target cloud service provider and obtain the original full cloud storage data.

[0010] In this embodiment of the application, the full cloud storage data in the target format is compared with the full local data in the vehicle manufacturer's local database to obtain the comparison result. This includes: converting the full cloud storage data in the target format into a first data dictionary object and converting the full local data into a second data dictionary object, wherein data of the same data resource type in the first data dictionary object and the second data dictionary object adopt a unified data format; and comparing the first data dictionary object and the second data dictionary object to obtain the comparison result.

[0011] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to obtain a comparison result includes: comparing the first data dictionary object and the second data dictionary object to determine the difference data items; and determining the comparison result based on the difference data items.

[0012] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to determine the difference data items includes: comparing the first data dictionary object and the second data dictionary object to determine the data items to be added, the data items to be modified, and / or the data items to be deleted; and determining the difference data items based on the data items to be added, the data items to be modified, and / or the data items to be deleted.

[0013] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to determine data items to be added, data items to be modified, and / or data items to be deleted includes: comparing the first data dictionary object and the second data dictionary object; determining data items missing in the second data dictionary object compared to the first data dictionary object as data items to be added; and / or determining data items in the second data dictionary object with different data content compared to the first data dictionary object as data items to be modified; and / or determining data items present in the second data dictionary object but missing in the first data dictionary object as data items to be deleted.

[0014] In this embodiment of the application, data synchronization of the vehicle manufacturer's local database is performed based on the comparison results, including: sending a data deletion review request when the comparison results contain data items to be deleted; and deleting the corresponding data items in the vehicle manufacturer's local database in response to receiving data deletion confirmation feedback.

[0015] In this embodiment of the application, data synchronization of the vehicle manufacturer's local database is performed based on the comparison results, including: when the comparison results contain data items to be added and / or data items to be modified, specifying corresponding addition and / or modification operations for the corresponding data items in the vehicle manufacturer's local database.

[0016] According to another aspect of the embodiments of this application, a data synchronization apparatus is also provided, comprising: an acquisition module, configured to acquire raw full cloud storage data from at least one target cloud service provider in response to a data synchronization triggering command; a conversion module, configured to convert the raw full cloud storage data into a target format full cloud storage data based on a data format unification model, wherein the data format unification model is used to convert data of the same data resource type from different cloud service providers into a unified data format; a comparison module, configured to compare the target format full cloud storage data with full local data in the vehicle manufacturer's local database to obtain a comparison result; and a synchronization module, configured to synchronize data in the vehicle manufacturer's local database based on the comparison result.

[0017] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0018] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0021] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0022] In this embodiment, in response to a data synchronization command, firstly, raw full-volume cloud storage data is obtained from at least one target cloud service provider; then, based on a unified data format model, the raw full-volume cloud storage data is converted to a target format full-volume cloud storage data; next, the target format full-volume cloud storage data is compared with the full-volume local data in the vehicle manufacturer's local database to obtain a comparison result; finally, based on the comparison result, data synchronization is performed on the vehicle manufacturer's local database. This application, based on a unified data format model, converts raw full-volume cloud storage data from different target cloud service providers, effectively shielding the data heterogeneity across different cloud vendor environments. Since the return structures of resource application programming interfaces from different cloud vendors vary significantly, converting to a unified data format ensures consistent data semantics, avoids misjudgments caused by differences in field naming or enumeration values, improves the accuracy and reliability of resource synchronization, and provides a guarantee for an accurate and standardized asset view for the configuration management database. By comparing the full cloud storage data in the target format with the full local data in the vehicle manufacturer's local database, the status of resource data can be efficiently and accurately identified. This solves the problem of resource information lag and inconsistency in multi-cloud and multi-source environments, ensuring the real-time and accuracy of operation and maintenance data. In turn, it solves the technical problem of low accuracy in data synchronization with the vehicle manufacturer's local database in related technologies. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 This is a flowchart of a data synchronization method according to an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of a data synchronization technology architecture according to an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of another data synchronization technology architecture according to an embodiment of this application;

[0027] Figure 4 This is a schematic diagram of a data synchronization process according to an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of another data synchronization process according to an embodiment of this application;

[0029] Figure 6 This is a schematic diagram of a data synchronization device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] According to an embodiment of this application, an embodiment of a data synchronization method is provided. The steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases the steps shown or described may be performed in a different order than that shown here.

[0033] This embodiment provides a data synchronization method. Figure 1 This is a flowchart of a data synchronization method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0034] Step S102: In response to the triggering data synchronization command, obtain the original full cloud storage data from at least one target cloud service provider.

[0035] The aforementioned data synchronization command can refer to a command that triggers the configuration management database system to perform resource data retrieval, comparison, and update operations. In this application, the data synchronization command can be triggered by a scheduled task, such as a global reconciliation during the daily off-peak hours in the early morning, a one-time task, or a periodic task. It can also be manually initiated by the user on a web platform, instructing the user to start the process of obtaining the latest resource status from the cloud vendor or the designated data center and synchronizing it to the vehicle manufacturer's local database.

[0036] At least one of the aforementioned target cloud service providers can refer to an external cloud resource management platform or physical resource environment that the configuration management database system needs to interface with and obtain resource data from. Specifically, this can include different cloud vendors and internet data center facilities, such as self-built data centers, containing physical servers, network equipment, and storage resources. This application can interface with these target cloud service providers through different proxy models or client objects.

[0037] The aforementioned raw full cloud storage data can refer to the collection of raw resource information retrieved from the application programming interfaces or management backends of various target cloud service providers, without undergoing standardized format processing. Raw full cloud storage data includes cloud resources such as virtual machines, disks, internet protocols, virtual private clouds, load balancers, and database instances, or the underlying attribute fields of internet data center physical assets such as hosts, switches, and routers. The data structure and naming conventions depend on the specific definitions of each cloud vendor or their internet data center, resulting in diverse data formats.

[0038] In one optional embodiment, dynamic routing calls based on a global proxy model pool can be performed. When a data synchronization command is received, the provider identification information contained in the command, such as cloud vendor type and tenant identifier, can be parsed. Based on the provider identification information, the corresponding target proxy model is retrieved and loaded from the pre-registered global client manager. This target proxy model encapsulates the application programming interface (API) interaction logic and authentication mechanism for a specific cloud vendor. Subsequently, using the access credentials held by the target proxy model, an API client object for the target cloud service provider is directly constructed. By calling the predefined resource retrieval interface in this client object, a data retrieval request is directly initiated to the cloud. The raw format data returned by the cloud interface is the raw full cloud storage data. This process achieves access for different cloud vendors through dynamic binding of the proxy pattern, without the need for hard-coding specific vendor logic.

[0039] In another alternative embodiment, standardized resource retrieval based on an internal unified interface can be performed. In this mode, after the data synchronization command is parsed, the specific data resource type to be synchronized, such as a cloud host or database cluster, is determined. Based on this data resource type, the standardized resource type encapsulation interface implemented in the target proxy model is located. Different cloud vendor proxy models have different underlying implementations, but all implement a unified interface definition. By calling these unified interface definitions, the target proxy model internally converts the standard interface call into an application programming interface (API) request specific to the cloud vendor, carrying the corresponding access credentials for authentication. After the target cloud service provider responds, the returned raw, full cloud storage data is directly captured. This process shields the differences in the underlying cloud vendor APIs, allowing the upper-layer synchronization logic to focus solely on the standard interface corresponding to the resource type, without needing to know which cloud vendor it is. This abstracts and standardizes the resource acquisition process, ensuring a consistent experience when acquiring multi-source heterogeneous cloud resources.

[0040] The above settings reduce communication overhead between system components and improve the scalability and stability of the architecture, enhance adaptability to multi-cloud environments, and provide a data foundation for subsequent efficient data comparison and synchronization.

[0041] Step S104: Based on the data format unification model, the original full cloud storage data is converted to obtain the full cloud storage data in the target format.

[0042] Among them, the data format unification model is used to convert data of the same data resource type from different cloud service providers into a unified data format.

[0043] The aforementioned unified data format model refers to an intermediate-layer data definition model used to abstract and standardize resource data structures. This model defines a unified custom cloud resource data format, aiming to shield the differences in field naming, data structure, and hierarchical relationships between similar resources from different cloud vendors and internet data centers. The unified data format model maps heterogeneous cloud resource data and internet data center physical resources to unified standard objects defined within the model, eliminating the need for subsequent processing to consider underlying vendor differences.

[0044] The aforementioned target format full cloud storage data can refer to structured resource data that conforms to the internal standards and specifications of the configuration management database system and is generated after being converted through a unified data format model.

[0045] The aforementioned data of the same resource type can refer to resource entities belonging to the same category in the unified data format model. For example, cloud host data from different cloud vendors are considered to be of the same data resource type; public Internet Protocol addresses from different cloud vendors are considered to be of the same type; and service components such as clusters and databases are also considered to be of the same data resource type. Different cloud vendors, if their resource functional attributes are the same, that is, if they have the same structural definition in the unified data format model, can therefore undergo unified format conversion.

[0046] In one optional embodiment, field-level conversion based on a resource type mapping table can be performed. The data format unification model internally maintains a standard data dictionary for various resources, such as cloud hosts, disks, and networks. When the original full cloud storage data arrives, the data resource type is identified. For each data resource type, predefined field mapping rules are loaded. Each resource object in the original full cloud storage data is traversed, and key attributes are extracted according to the mapping rules. Redundant fields specific to cloud vendors are removed, and different names for the same concept from different cloud vendors are uniformly converted into standard field names. Full cloud storage data conforming to the target format defined by the standard model is generated, ensuring a consistent data structure for the same resource type across different cloud vendors.

[0047] In another alternative embodiment, object-level conversion based on the adapter pattern can be performed. The unified data format model includes dedicated adapter components for each resource type. When the raw full cloud storage data arrives, the corresponding adapter is instantiated or invoked according to the resource type. The adapter internally encapsulates the conversion algorithm from the cloud vendor's specific data format to the standard data format. The adapter performs parsing, cleaning, and data type conversion, such as converting strings to timestamps, as well as default value filling operations. During the conversion process, the adapter is also responsible for handling the standardization of cloud vendor-specific enumeration values. Through the independent encapsulation of the adapter, the data format conversion logic of different cloud vendors is isolated, so that the main process only needs to call the unified conversion interface of the adapter to obtain the full cloud storage data in the target format without needing to care about the internal conversion details.

[0048] The above settings effectively shield against data heterogeneity in multi-vendor environments, laying the foundation for efficient data synchronization. The resource application programming interfaces (APIs) from different cloud vendors return significantly different structures; direct comparison would lead to high complexity and error rates. By converting to a unified data format, consistent data semantics are ensured, avoiding misjudgments caused by differences in field naming or enumeration values. This improves the accuracy and reliability of resource synchronization, guaranteeing an accurate and standardized asset view for the configuration management database.

[0049] Step S106: Compare the full cloud storage data in the target format with the full local data in the vehicle manufacturer's local database to obtain the comparison result.

[0050] The aforementioned local database of the automaker can refer to a database deployed internally within the configuration management database system, used to store globally unified resource and asset information of the automaker. This local database stores resource data synchronized from cloud vendors, as well as physical asset data of internet data centers, service component data, and application-resource relationship data, which are manually entered through web platforms or imported via scripts.

[0051] The aforementioned full local data can refer to the set of the newest resource records stored in the automaker's local database, corresponding to the type of cloud resource to be synchronized. During the synchronization process, relevant local resource information will be retrieved from the local database for item-by-item comparison with the full cloud storage data in the target format.

[0052] The comparison results mentioned above can refer to the difference results generated after comparing the full cloud storage data in the target format with the full local data item by item.

[0053] In one optional embodiment, key-value pair hash comparison based on an in-memory dictionary object can be performed. The full cloud storage data in the target format can be loaded into memory, using resource identifiers, such as cloud resource identifiers, as keys and standardized resource attribute objects as values ​​to construct a first data dictionary object. Corresponding resource data is retrieved from the vehicle manufacturer's local database, again using cloud resource identifiers as keys to construct a second data dictionary object. Subsequently, using the first data dictionary object as the main table, each key-value pair is traversed, and fast lookups are performed within the second data dictionary object. This hash index-based comparison method avoids nested loops in the full data set, improving the comparison efficiency of large-scale datasets.

[0054] In another alternative embodiment, a row-by-row comparison algorithm based on sorting can be used. The full cloud storage data and full local data in the target format can be extracted separately and sorted according to cloud resource identifiers to ensure the two data sequences are arranged in the same order. Then, two pointers are introduced, each pointing to the starting position of one of the sorted sequences. By comparing the identifiers of the resources pointed to by the pointers, if the identifiers are the same, the attribute content is further compared; if the content is different, it is recorded as a modification. If the identifiers are different, the pointer corresponding to the smaller identifier is moved according to the size relationship of the identifiers. If one pointer reaches the end first, the remaining unmatched resources are marked as added or deleted, respectively. This process is executed streamingly in memory or a temporary file, without needing to load the data into a memory-intensive dictionary structure all at once. It is suitable for scenarios with extremely large data volumes and limited memory, achieving accurate location of differing data through linear scanning.

[0055] The above settings enable efficient and accurate identification of resource data status, ensuring the consistency of configuration management database data. By introducing a unified data format and standardized comparison logic, the addition, deletion, and modification status of resources can be automatically identified. This comparison method outputs the discrepancies in a structured manner, providing clear instructions for subsequent accurate execution of database insertion, update, and deletion operations. This solves the problem of lagging and inconsistent resource information in multi-cloud and multi-source environments, ensuring the real-time performance and accuracy of operation and maintenance data.

[0056] Step S108: Based on the comparison results, synchronize the data in the local database of the car manufacturer.

[0057] In one optional embodiment, transaction-based batch atomic updates can be performed. A queue of data items to be added, modified, and deleted, generated from the comparison results, is received. For the data items to be added and modified, they are encapsulated into a set of structured query statements for batch insertion or batch update. Before executing the operations, a database transaction is started, and these batch operations are executed sequentially. For data items to be deleted, soft deletion logic can be triggered, i.e., the status field of the relevant record in the database is updated to "pending confirmation of deletion" or "released," and the deletion time and administrator information are recorded. If subsequent manual review fails, the data can be quickly restored. After the operation is completed, the success of each step in the transaction is checked. If all steps are successful, the transaction is committed to ensure data consistency; if any step fails, the entire transaction is rolled back to prevent data inconsistency caused by partial updates.

[0058] In another alternative embodiment, a traffic splitting mechanism based on difference types can be implemented. Data items are categorized and processed according to the comparison results. For data items to be added, the database's insert interface is directly called to write the new resource information from the cloud to the local table, while initializing relevant metadata such as creation time and synchronization source. For data items to be modified, an update operation is performed, updating the changed fields and retaining the original values ​​of unchanged fields to reduce database lock contention and I / O overhead. For data items to be deleted, physical deletion may not be performed immediately; the resource identifier is marked as abnormal or pending cleanup, and a synchronization log record is generated. This traffic splitting process allows for the use of optimal database strategies for different operation types. For example, a batch high-speed loading mode can be used for add operations, while row-level locking updates can be used for modification operations, thereby maximizing the database's concurrent processing capacity and synchronization efficiency while ensuring data accuracy.

[0059] The above settings ensure the consistency and operational security of asset data in the configuration management database. Batch atomic updates or distributed processing efficiently and accurately reflect the true state of cloud resources, eliminating information lag caused by manual maintenance. The introduction of transaction mechanisms and soft deletion strategies effectively prevents data loss or inconsistencies due to network fluctuations or program anomalies, improving system robustness. Furthermore, the structured reflection of synchronization results in the vehicle manufacturer's local database provides upper-layer applications with a real-time and accurate resource view, enabling the operations and maintenance team to conduct troubleshooting and resource planning based on the new data. This improves the efficiency of automated operations and maintenance and the scientific basis of decision-making, achieving closed-loop management of data flow from the cloud to the local system.

[0060] In this embodiment, in response to a data synchronization command, firstly, raw full-volume cloud storage data is obtained from at least one target cloud service provider; then, based on a unified data format model, the raw full-volume cloud storage data is converted to a target format full-volume cloud storage data; next, the target format full-volume cloud storage data is compared with the full-volume local data in the vehicle manufacturer's local database to obtain a comparison result; finally, based on the comparison result, data synchronization is performed on the vehicle manufacturer's local database. This application, based on a unified data format model, converts raw full-volume cloud storage data from different target cloud service providers, effectively shielding the data heterogeneity across different cloud vendor environments. Since the return structures of resource application programming interfaces from different cloud vendors vary significantly, converting to a unified data format ensures consistent data semantics, avoids misjudgments caused by differences in field naming or enumeration values, improves the accuracy and reliability of resource synchronization, and provides a guarantee for an accurate and standardized asset view for the configuration management database. By comparing the full cloud storage data in the target format with the full local data in the vehicle manufacturer's local database, the status of resource data can be efficiently and accurately identified. This solves the problem of resource information lag and inconsistency in multi-cloud and multi-source environments, ensuring the real-time and accuracy of operation and maintenance data. In turn, it solves the technical problem of low accuracy in data synchronization with the vehicle manufacturer's local database in related technologies.

[0061] In this embodiment of the application, obtaining raw full cloud storage data from at least one target cloud service provider includes: calling a target proxy model corresponding to at least one target cloud service provider from multiple proxy models; and accessing data from at least one target cloud service provider based on the target proxy model to obtain the raw full cloud storage data.

[0062] The aforementioned proxy models refer to a set of adapters pre-built in the configuration management database system to achieve unified data access. Each proxy model is specifically designed to interface with a resource management application interface of a particular type or cloud vendor. Each proxy model encapsulates the application interface call logic, authentication method, data parsing rules, and error handling mechanism for that vendor. Multiple proxy models are jointly registered in the global client manager, providing standardized interfaces to the outside world, thereby shielding the differences in application interfaces from different underlying cloud vendors.

[0063] The aforementioned target proxy model can refer to a specific proxy model that is dynamically selected or loaded from multiple proxy models based on the identifier of the cloud service provider that needs to be accessed during the execution of the current data synchronization task.

[0064] In one optional embodiment, static route resolution based on configuration files or the registry can be performed. Supported cloud vendor proxy models and their corresponding provider identifiers can be registered in a global configuration center or in-memory registry. When a data synchronization command is received, the target cloud service provider identifier carried in the command is first parsed. Subsequently, the target proxy model that accurately matches the identifier is retrieved from the registry using a key-value lookup. If no match is found, an exception indicating that the cloud vendor is not supported is thrown; if a match is found, the target proxy model is directly returned. This process relies on predefined mapping relationships, enabling rapid location from command to specific execution components and ensuring targeted access to resources of a specified cloud vendor.

[0065] In another alternative embodiment, dynamic instantiation based on the strategy pattern and factory method can be implemented. A proxy model factory is maintained, managing a set of abstract proxy interfaces and instantiation logic. When a data synchronization command is triggered, the cloud service provider identifier is passed as a parameter to the factory method. Based on the identifier information, the factory method dynamically loads and instantiates the corresponding concrete proxy model class using reflection or a strategy routing algorithm. After instantiation, a reference to the target proxy model is returned. This implementation decouples the creation and use of proxy models, allowing for the addition of new cloud vendor support simply by registering new mapping relationships or adding new code classes to the factory. This achieves a high degree of modular design and the open / closed principle, enhancing adaptability to changes in multi-cloud environments.

[0066] The above setup improves scalability and maintenance efficiency while reducing coupling. Encapsulating the application programming interface (API) interaction logic specific to different cloud vendors within independent proxy models avoids hard-coded binding between synchronization logic and specific cloud vendor implementations. This means that when integrating a new cloud vendor or updating existing cloud vendor interfaces, only the corresponding proxy model needs to be modified or added, without altering the synchronization code, reducing the risk of introducing errors. This on-demand invocation of specific proxy models avoids resource waste caused by loading components from various cloud vendors, improving system startup speed and runtime performance. Through unified interface abstraction, upper-layer business logic can access different cloud platforms in a consistent manner, simplifying development complexity and providing flexible and robust technical architecture support for building a unified multi-cloud resource management platform.

[0067] In this embodiment of the application, calling the target proxy model corresponding to at least one target cloud service provider from multiple proxy models includes: determining the provider identification information corresponding to at least one target cloud service provider; and calling the target proxy model from multiple proxy models based on the provider identification information.

[0068] The aforementioned provider identification information can refer to data used to distinguish and identify different cloud service providers, and may include identity characteristics of different cloud vendors, cloud accounts, and tenants. In the synchronous task scheduling of the configuration management database system, this provider identification information can be used to accurately match and invoke the corresponding target proxy model from the globally registered multi-proxy model pool.

[0069] In one optional embodiment, a fast index lookup based on a hash map can be performed. A global provider identifier mapping table is pre-built, using the cloud service provider's identifier as the key and the corresponding proxy model class reference or instance as the value. When the target proxy model needs to be obtained, the identifier information of the target cloud service provider is extracted from the data synchronization instruction or the current execution context. Subsequently, a lookup operation is performed in the hash map table using this identifier as the key. If the corresponding value is found, the proxy model object is returned directly; if not found, an exception handling mechanism or default fallback logic is triggered. This approach leverages the efficiency of hash algorithms to achieve instant mapping from identifier to execution component, avoiding the performance overhead caused by traversal or conditional judgments, and is suitable for scenarios with many cloud vendor types and high call frequency.

[0070] In another alternative embodiment, dynamic distribution based on policy enumeration or factory routing can be performed. A proxy policy interface is defined, and proxy models from various cloud vendors implement this interface. A policy registrar can be maintained, registering instances of proxy models implementing the interface into a list or dictionary via code initialization or reflection scanning. Once the target cloud service provider's identifier is determined, the policy list in the registrar is traversed, or a specific routing algorithm, such as prefix matching or regular expression matching based on the identifier, is used to find a proxy model compatible with that identifier. Once a match is found, the proxy model is returned. If multiple potential matches exist, the preferred option can be selected based on priority configuration. This implementation is more flexible, supports dynamic registration of new proxy models at runtime, and updates routing policies without restarting the service, making it suitable for environments that frequently require access to new cloud vendors or dynamic adjustments to cloud resource management policies.

[0071] The above settings achieve efficient decoupling and dynamic management of cloud resource access components. By accurately invoking the corresponding proxy model using identification information, the synchronization logic doesn't need to concern itself with the specific cloud vendor; it only needs to focus on the identifier itself, reducing coupling between modules. This approach simplifies adding support for new cloud vendors; simply register a new proxy model and configure the corresponding identifier mapping without modifying the data synchronization code, adhering to the open / closed principle. The efficient lookup mechanism ensures that proxy model initialization and retrieval do not become performance bottlenecks under high-concurrency synchronization tasks, guaranteeing overall high availability and response speed, and providing flexible and efficient technical support for unified resource management in multi-cloud environments.

[0072] In this embodiment of the application, based on the target proxy model, data access is performed on at least one target cloud service provider to obtain the original full cloud storage data, including: parsing the data synchronization instruction to determine the data resource type to be synchronized; and based on the target proxy model, calling the resource type encapsulation interface corresponding to the data resource type to obtain the original full cloud storage data.

[0073] The aforementioned data resource types to be synchronized can refer to the specific categories of cloud resources or Internet data center assets that are specified or required to be pulled, compared, and updated in the data synchronization instructions. These types cover various levels such as computing, networking, storage, and middleware services.

[0074] The aforementioned resource type encapsulation interfaces can refer to standardized internal application programming interface (API) methods defined within a unified data format model. These interfaces are implemented by different cloud vendor proxy models and have unified names, parameter structures, and return value formats, thereby shielding the differences in underlying application programming interfaces among various cloud vendors.

[0075] In one optional embodiment, interface routing distribution based on resource type enumeration can be performed. First, the data synchronization instruction is parsed to extract the specified data resource type parameter. A mapping configuration table is maintained, defining the standard interface method names corresponding to various resource types. Then, based on the obtained target proxy model, reflection or dynamic proxy technology is used to find the standard interface method implemented in the proxy model that matches the resource type. After finding the corresponding method, a call request containing the required parameters is constructed, and the interface method is executed through the target proxy model. Internally, the target proxy model executes a specific cloud vendor application interface call and encapsulates the returned raw data before returning it, thus obtaining the raw, full cloud storage data for the specific resource type.

[0076] In another alternative embodiment, a chain-of-responsibility call based on the policy pattern can be performed. A set of resource type processors is defined, each responsible for handling the synchronization of resource data of a specific type. Once the data resource type is resolved, the corresponding processor instance is determined based on that type. These processors are integrated internally by the target proxy model or it holds processor references. The unified resource acquisition entry point in the target proxy model is invoked, passing in the resource type identifier. Internally, the target proxy model distributes the request to the corresponding processor based on the identifier. The processor executes the specific cloud vendor application programming interface (API) fetching logic, and after completing the data fetch, returns the raw data to the caller. This implementation distributes the acquisition logic for different resource types into independent processors, with each processor focusing on the API interaction details of its own type, and invoked through a unified entry point, achieving modular isolation of the resource type acquisition logic.

[0077] The above setup enhances flexibility and maintainability. By decoupling data resource types from specific application programming interfaces (APIs), different types of cloud resources can be handled in a unified manner, and changes in resource types do not require modification of the upper-layer synchronization logic. This interface- or policy-based design means that when a new resource type is added, only a new interface definition or processor logic needs to be added, and the corresponding mapping relationship needs to be configured, without altering the synchronization process. This abstraction layer shields the differences in API calls between different cloud vendors, enabling the synchronization module to acquire various resource data in a standardized and consistent manner, reducing development complexity, improving code reusability, and providing a technical foundation for building a unified and efficient configuration management database resource synchronization platform.

[0078] In this embodiment of the application, based on the target proxy model, the resource type encapsulation interface corresponding to the data resource type is called to obtain the original full cloud storage data. This includes: based on the target proxy model, calling the resource type encapsulation interface corresponding to the data resource type, and access credential information corresponding to at least one target cloud service provider, to access the data from at least one target cloud service provider and obtain the original full cloud storage data.

[0079] The aforementioned access credentials information can refer to a set of keys or authentication credentials required for identity authentication, authorization, and establishing secure communication connections with the target cloud service provider, including cloud platforms of various cloud vendors and self-built Internet data center systems. Because different cloud tenants or different business lines require isolated management, the synchronization module needs to carry the correct credentials to legally access specific resource data.

[0080] In one optional embodiment, dynamic credential injection based on security context isolation can be performed. The current context's secure storage area is retrieved from the target proxy model, pre-loaded with access credential information corresponding to the target cloud service provider. When a resource type encapsulation interface needs to be called, the target cloud service provider's identifier and corresponding access credential are passed to the target proxy model via dependency injection or method parameter passing. The target proxy model automatically extracts the credential from the security context and populates it into the request header or signature parameters. Subsequently, the target proxy model executes the logic defined in the resource type encapsulation interface, sending a data access request to the target cloud service provider with the authenticated credential. After verifying the credential validity, the cloud service returns the original full cloud storage data. This process ensures the isolation and security of credential information during transmission and processing, avoiding hard-coding the credential in the code.

[0081] In another alternative embodiment, credential reuse and load balancing based on connection pool management can be implemented. A credential connection pool or session manager is maintained for each cloud service provider. When a data synchronization command is triggered, a dedicated application interface client session, already bound to corresponding access credential information, is obtained or created from the connection pool based on the target cloud service provider's identifier. A pre-registered resource type encapsulation interface in the target proxy model is invoked, internally reusing the credential context from the session manager. The target proxy model uses this session to establish a connection with the target cloud service provider and performs data retrieval operations. During this process, request retry mechanisms or load balancing strategies can be implemented, such as automatically refreshing credentials or switching to backup credentials when credentials expire or connections time out. After obtaining the original full cloud storage data, the session is returned to the connection pool or closed to release resources. This approach improves the efficiency of credential management, reduces the overhead of frequent authentication, and enhances the stability of interactions with cloud service providers.

[0082] The above settings enhance security, stability, and resource utilization efficiency. By decoupling access credential information from resource access logic and employing dynamic injection or connection pooling management, the risk of sensitive credential leakage is effectively prevented, complying with enterprise-level security standards. Credential reuse and session management reduce authentication overhead for each data access, lower network latency, and improve the performance of large-scale cloud resource synchronization. This mechanism supports automatic credential refresh and fault recovery, ensuring continuous data access within the credential validity period, improving robustness against network fluctuations or changes in cloud vendor interfaces, and providing reliable assurance for accurate and real-time resource data to the configuration management database.

[0083] In this embodiment of the application, the full cloud storage data in the target format is compared with the full local data in the vehicle manufacturer's local database to obtain the comparison result. This includes: converting the full cloud storage data in the target format into a first data dictionary object and converting the full local data into a second data dictionary object, wherein data of the same data resource type in the first data dictionary object and the second data dictionary object adopt a unified data format; and comparing the first data dictionary object and the second data dictionary object to obtain the comparison result.

[0084] The aforementioned first data dictionary object can refer to a memory data structure constructed from new cloud resource data obtained from the cloud service provider and converted through a unified data format model, using cloud resource identifiers as keys and standardized attribute information of the resource, such as name, specifications, Internet protocol address, status, tenant, project and environment tags, as values.

[0085] The aforementioned second data dictionary object can refer to the current storage resource data related to the type of resource to be synchronized, retrieved from the local database of the car manufacturer, and constructed as an in-memory data structure with the cloud resource identifier as the key and the attribute information of the resource in the database as the value.

[0086] In one optional embodiment, efficient key-value comparison based on memory hash mapping can be performed. The full cloud storage data in the target format can be loaded into memory, using resource identifiers, such as cloud resource identifiers, as keys and standardized complete resource attribute objects as values ​​to construct a first data dictionary object. Corresponding resource data is then retrieved from the vehicle manufacturer's local database, again using cloud resource identifiers as keys to construct a second data dictionary object. Subsequently, using the first data dictionary object as a reference, each key-value pair is traversed, and hash lookups are performed within the second data dictionary object. This hash index-based comparison method avoids nested loops in the full data set, improving the comparison efficiency of large-scale datasets.

[0087] In another optional embodiment, a line-by-line comparison algorithm can be executed to extract the full cloud storage data and the full local data in the target format, and sort them according to cloud resource identifiers to ensure that the two data sequences are arranged in the same order. Then, two pointers are introduced, each pointing to the beginning of one of the sorted sequences. By comparing the identifiers of the resources pointed to by the pointers, if the identifiers are the same, the attribute content of the two is further compared; if the content is different, it is recorded as a modification; if the identifiers are different, the pointer corresponding to the smaller identifier is moved according to the size relationship of the identifiers. If one pointer reaches the end first, the remaining unmatched resources are marked as added or deleted, respectively. This process is executed streamingly in memory or a temporary file, without needing to load the data into a memory-intensive dictionary structure all at once. It is suitable for scenarios with large data volumes and limited memory, achieving accurate location of differing data through linear scanning.

[0088] The above settings enable efficient and accurate identification of resource data status, ensuring the consistency of configuration management database data. By introducing a unified data format and standardized comparison logic, the addition, deletion, and modification status of resources can be automatically identified, replacing the inefficient and error-prone traditional manual comparison method. The comparison mechanism based on memory dictionary or sorting scan can complete the difference analysis of massive amounts of resource data within minutes, meeting the performance requirements of scheduled synchronization and full reconciliation. Furthermore, this comparison method outputs complex difference results in a structured manner, providing clear instructions for subsequent accurate execution of database insertion, update, and deletion operations. This solves the problem of resource information lag and inconsistency in multi-cloud and multi-source environments, ensuring the real-time nature and accuracy of operation and maintenance data.

[0089] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to obtain a comparison result includes: comparing the first data dictionary object and the second data dictionary object to determine the difference data items; and determining the comparison result based on the difference data items.

[0090] The aforementioned discrepancy data items refer to the set of resource records identified as inconsistent or with changed states after comparing the first data dictionary object and the second data dictionary object item by item based on an identifier, such as a cloud resource identifier. These discrepancy data items represent the deviation between the actual state in the cloud and the state recorded locally in the configuration management database, and are the specific data units that require synchronization operations.

[0091] In one optional embodiment, difference identification based on set operations can be performed. The key sets of the first and second data dictionary objects are extracted respectively. Using the set difference operation, the set of keys existing in the cloud but missing locally is calculated; the resource data items corresponding to these keys are directly identified as data items to be added. Next, the set of keys existing locally but missing in the cloud is calculated; the resource data items corresponding to these keys are identified as data items to be deleted. For the intersection of the two sets, i.e., keys existing in both the cloud and local environments, a detailed field-by-field comparison process is initiated, extracting the value objects of the corresponding keys from the two dictionaries for in-depth comparison. If inconsistent attribute field content is found, the data item is marked as a data item to be modified. Finally, the three categories of data items—added, deleted, and modified—are summarized to form a list of differing data items.

[0092] In another alternative embodiment, incremental tracking and comparison based on a state machine can be performed. Three independent difference queues are initialized: an add queue, a modify queue, and a delete queue. Each data item in the first data dictionary object is traversed, and the cloud resource identifier is used as an index to search in the second data dictionary object. If no match is found, it means the resource does not exist in the automaker's local database, and the resource is added to the add queue. If a match is found, the attribute states of the two are compared. If there are differences in state or attribute values, the resource is added to the modify queue. After traversing the first data dictionary object, the second data dictionary object is traversed in reverse, searching for keys that do not appear in the first data dictionary object. These resources have been released in the cloud but still have records locally, and these resources are added to the delete queue. This method, through one forward traversal and one reverse traversal, combined with state markers, clearly defines the ownership of various difference data and avoids redundant calculations.

[0093] The above settings enable accurate classification and control of resource changes. By explicitly categorizing comparison results into three types—addition, modification, and deletion—differentiated synchronization strategies can be implemented for changes of different natures. For example, addition operations can be directly inserted, modification operations can update specific fields, and deletion operations can trigger a security review mechanism. This fine-grained difference identification avoids the performance waste and data loss risks associated with full coverage, ensuring the atomicity and consistency of data updates in the configuration management database. The structured difference results make subsequent data synchronization operations more transparent and traceable, providing the operations team with clear change audit trails and improving the accuracy and security of resource management.

[0094] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to determine the difference data items includes: comparing the first data dictionary object and the second data dictionary object to determine the data items to be added, the data items to be modified, and / or the data items to be deleted; and determining the difference data items based on the data items to be added, the data items to be modified, and / or the data items to be deleted.

[0095] In one optional embodiment, a three-way logical decision based on hash indexes can be performed. Using a first data dictionary object as the main table, each key-value pair is traversed. During traversal, a hash lookup is performed in the second data dictionary object using the cloud resource identifier as the key. If the lookup fails (i.e., the identifier does not exist in the local database), the data item is determined to be a data item to be added and is added to the add queue. If the lookup succeeds, the attribute value objects of the two are further compared. If any difference is found in any attribute field, it is determined to be a data item to be modified and is added to the modify queue. After completing the traversal of the first data dictionary object, the second data dictionary object is traversed in reverse, checking whether the key exists in the first data dictionary object. If a key is missing in the first data dictionary object, it means that the resource has been released in the cloud but still has a record locally; this is determined to be a data item to be deleted and is added to the delete queue. Finally, these three queues are merged to form a set of differing data items.

[0096] In another alternative embodiment, a sort-merge-based linear scan algorithm can be executed. The first data dictionary object and its data items are extracted into lists and uniformly sorted in ascending order by cloud resource identifiers. Then, two pointers are initialized, each pointing to the beginning of one list. The identifiers of the resources pointed to by the two pointers are compared: if the identifiers are the same, the attribute content is compared; if they are inconsistent, they are marked as needing modification, and both pointers move forward simultaneously; if the identifiers are different, it means that the one with the smaller identifier is missing in the other. If the current identifier of the first data dictionary object is smaller than that of the first data dictionary object, it means that the resource exists in the cloud but not locally, and it is marked as needing to be added, and the first dictionary pointer moves forward; if the current identifier of the second data dictionary object is smaller, it means that the resource exists locally but not in the cloud, and it is marked as needing to be deleted, and the second dictionary pointer moves forward. When either list is traversed to its end, the remaining untraversed data items are marked as either added or deleted. This process efficiently determines various discrepancies through linear scanning.

[0097] The above settings enable accurate identification and categorized management of resource status changes. By explicitly classifying comparison results into three categories—addition, modification, and deletion—differentiated processing strategies can be implemented for data changes of different natures. Added data items are directly inserted, modified data items are partially updated, and deleted data items trigger security reviews, avoiding the performance overhead and data consistency risks associated with full data overwrite. This fine-grained difference identification improves synchronization efficiency and ensures the real-time accuracy of configuration management database data. The structured difference results provide clear instructions for subsequent automated operations, enhancing adaptability to complex changes in multi-cloud environments and ensuring the consistency of asset data throughout its entire lifecycle.

[0098] In this embodiment of the application, comparing the first data dictionary object and the second data dictionary object to determine data items to be added, data items to be modified, and / or data items to be deleted includes: comparing the first data dictionary object and the second data dictionary object; determining data items missing in the second data dictionary object compared to the first data dictionary object as data items to be added; and / or determining data items in the second data dictionary object with different data content compared to the first data dictionary object as data items to be modified; and / or determining data items present in the second data dictionary object but missing in the first data dictionary object as data items to be deleted.

[0099] In one optional embodiment, logical judgment based on set operations can be performed to extract the identifier sets of each data item in the first and second data dictionary objects. For data items to be added, the set difference is calculated, i.e., identifiers that exist in the first data dictionary object but not in the second data dictionary object are identified. The resources corresponding to these identifiers are data added in the cloud but missing locally, and are marked as to be added. For data items to be modified, the intersection of the identifiers in the two dictionaries is calculated, and these common identifiers are traversed, with a depth comparison of the resource attribute content corresponding to both. If differences are found in the attribute fields, the data item is marked as to be modified. For data items to be deleted, the set difference is calculated again, i.e., identifiers that exist in the second dictionary but not in the first dictionary are identified. These resources no longer exist in the cloud but are still recorded locally, and are marked as to be deleted. Finally, these three types of marking results are summarized.

[0100] In another optional embodiment, a bidirectional scanning mechanism based on index traversal can be executed, performing a forward traversal based on a first data dictionary object. For each data item in the first data dictionary object, its existence is checked in the second data dictionary object. If not found, it indicates that the resource is missing locally and is added to the list to be added; if found, the content is compared field by field, and if the content is inconsistent, it is added to the list to be modified. After completing the forward traversal, a reverse traversal is performed, using the second data dictionary object as the basis. For each data item in the second data dictionary object, its existence is checked in the first data dictionary object. If not found, it indicates that the resource has been deleted in the cloud but remains locally, and is added to the list to be deleted. This process, through two independent traversal logics, handles the three cases of addition, modification, and deletion respectively, ensuring that discrepancies are accurately categorized.

[0101] The above settings enable accurate identification and automated synchronization of resource data changes. By clearly distinguishing between additions, modifications, and deletions, targeted database operations can be performed: adding data items triggers an insert, modifying data items triggers a partial update, and deleting data items triggers a soft delete or a review. This fine-grained difference handling avoids the performance waste and data loss risk of full data overwrite, ensuring the consistency of the configuration management database.

[0102] In this embodiment of the application, data synchronization of the vehicle manufacturer's local database is performed based on the comparison results, including: sending a data deletion review request when the comparison results contain data items to be deleted; and deleting the corresponding data items in the vehicle manufacturer's local database in response to receiving data deletion confirmation feedback.

[0103] The aforementioned data deletion review request can refer to a manual intervention notification or approval process signal automatically initiated by the configuration management database synchronization reconciliation module to ensure asset data security when it detects a data item to be deleted, i.e., the cloud has released resources but there are still records in the local database.

[0104] The aforementioned data deletion confirmation feedback can refer to a positive response signal returned to the configuration management database system through a designated channel after receiving a data deletion review request and manually verifying that the resource does not need to be retained in the configuration management database, or after confirming that there is no error.

[0105] In one optional embodiment, an asynchronous manual confirmation mechanism using an instant messaging tool can be implemented. When the synchronization module detects a data item to be deleted in the comparison results, it automatically constructs a deletion review notification message containing information such as resource identifier, resource name, business line, and administrator. The pre-integrated instant messaging platform application interface is invoked to push this notification to the administrator or operations team group of the corresponding resource. The module then enters a waiting state, listening for callback interfaces or message receipts from the communication platform. When the administrator views the notification on the client and performs the confirmation deletion operation, a feedback signal containing a specific confirmation token is sent to the configuration management database system. After verifying the validity of the token, a deletion transaction is triggered in the local database, removing the corresponding resource record. This process decouples automated synchronization from manual security verification, ensuring the rigor of the deletion operation.

[0106] In another alternative embodiment, a semi-automatic mechanism based on state machines and timeout automatic cleanup can be implemented. When a data item to be deleted is detected, deletion is not performed immediately. Instead, the status field of the corresponding resource in the local database is marked as pending review or soft deletion, and the review deadline is recorded. Simultaneously, a notification is sent to the administrator, requesting confirmation via a web console or application programming interface within a specified time window. If the administrator confirms before the timeout, physical deletion is performed; if no feedback is received after the timeout, deletion can be performed automatically according to a preset policy or manual intervention can be initiated. Furthermore, a review task queue is maintained, periodically scanning data items in the pending review status. If no confirmation is received for an extended period, the items are automatically marked as abnormal and an alarm is triggered. This mechanism manages the deletion lifecycle through state flow, balancing automation efficiency and data security requirements, and avoiding synchronization blockages caused by network latency or busy personnel.

[0107] The above settings enhance the security and accuracy of cloud resource data, preventing operational incidents caused by accidental deletion. By introducing a secondary confirmation mechanism, a manual review step is embedded in the automated synchronization process, effectively identifying false deletion signals caused by application interface misreports, network fluctuations, or configuration errors, ensuring the accurate reflection of data in the configuration management database. This design retains the efficiency of automated synchronization while reducing the risk of data loss through a safety valve mechanism. Decoupling the deletion operation from the confirmation feedback allows other synchronization tasks to continue during manual response, improving the overall throughput and availability of the system and providing a guarantee for building a trustworthy and reliable automated operation and maintenance platform.

[0108] In this embodiment of the application, data synchronization of the vehicle manufacturer's local database is performed based on the comparison results, including: when the comparison results contain data items to be added and / or data items to be modified, specifying corresponding addition and / or modification operations for the corresponding data items in the vehicle manufacturer's local database.

[0109] In one optional embodiment, atomic writes based on batch transactions can be performed. First, the data items to be added and modified from the comparison results are encapsulated into independent database operation object queues. For data items to be added, a standard structured query insert statement is generated or the batch insert interface of an object-relational mapping framework is called to package the new record into a transaction unit. For data items to be modified, a batch update statement is generated, updating only the changed fields to improve execution efficiency and reduce network overhead. Subsequently, the insert and update operations are executed within the same database transaction. If any operation fails, such as due to constraint conflicts or network anomalies, a rollback operation is performed to ensure the consistency of the database state; if all operations succeed, the transaction is committed. During this process, operation logs, including the number of rows affected and timestamps, can also be recorded for subsequent auditing and troubleshooting. This approach guarantees the atomicity of data synchronization through a transaction mechanism, avoiding data inconsistency issues caused by partial updates.

[0110] In another alternative embodiment, a streaming, item-by-item processing retry mechanism can be implemented. The list of data items to be added and modified is traversed, and an independent database operation is performed on each data item. For adding data items, the database's insert interface is called; for modifying data items, the update interface is called. Before executing each operation, the database connection status is checked. If the operation fails due to a temporary error, such as lock waiting or connection timeout, a limited number of retries are performed according to a preset retry strategy, such as an exponential backoff algorithm. If the retries are exhausted and the operation still fails, the failure record is added to the corresponding queue, along with detailed error information, while the remaining data items continue to be processed, ensuring that a single failure does not affect the overall synchronization process. After processing is complete, an alarm notification is sent to the failed items in the queue, prompting administrator intervention. This approach improves the system's robustness, enabling it to cope with sudden high database loads or network fluctuations, ensuring that most data is correctly synchronized.

[0111] The above settings ensure a high degree of consistency and data integrity between the local configuration management database and cloud resource status. Atomic transactions or streaming processing with retries effectively overcome the risks posed by network instability or transient database failures, guaranteeing the accurate persistence of newly added and modified data. This mechanism eliminates the need for manual intervention, achieving automated closed-loop management of resource changes and improving operational efficiency. Fine-grained operation logs and failure handling mechanisms provide strong support for data traceability and problem diagnosis, enhancing system maintainability and reliability. They provide accurate and real-time resource data support for business systems, ensuring the correct access to resource information by upper-layer applications.

[0112] The technical solution proposed in this application is described below with reference to an optional embodiment. This application proposes a method for synchronizing and reconciling cloud resources in a configuration management database system. It relates to the field of global automated operation and maintenance technology, and involves the management of hardware resources, cloud rental resources, and business application information in internet data centers, forming an overview of hardware and software resource data usage and a network topology diagram of resource relationships. It aims to solve the problems of fragmented offline manual records of cloud rental resources and internet data center physical assets and service resources, difficulties in cross-cloud account management, inaccurate data due to untimely updates, and the risk of business service interruptions caused by untimely detection of resource usage bottlenecks. By adapting to the cloud resource retrieval application programming interfaces of different cloud vendors, similar resource data from different cloud vendors are standardized into a unified data format. Then, through data comparison and analysis modules, changed cloud resource data is filtered out, and the data items are updated to the local database. Information on physical machines, virtual machines, and self-built service clusters in internet data centers is entered into the configuration management database system platform in a unified data format.

[0113] The cloud resource data synchronization management method proposed in this application includes: connecting and adapting to the open application programming interfaces (APIs) of cloud vendors, and defining a unified cloud resource data format as an intermediate layer data format; implementing a unified internal interface for resource data format conversion; generating cloud application programming interface client objects based on the developer accounts of different cloud rental spaces; and implementing resource data retrieval and various resource operation interfaces through traversal. The resource type encapsulation interfaces are shown in Table 1 below:

[0114]

[0115] The resource list interfaces from different cloud vendors are unified into a single internal resource application programming interface (API) definition. Different cloud API client objects implement these interface methods and are registered with the global client manager, thus masking differences in resource interface definitions and resource attributes across different cloud vendors. This enhances code maintainability and reusability, eliminating the need for users to concern themselves with the implementation details of specific interface methods. For example, using a cloud client object, users only need to obtain and construct the cloud API client object using the cloud vendor name identifier and developer credentials, and then execute the cloud resource retrieval interface to pull cloud resource information. Service component data and operation interfaces are uniformly defined, with data information categorized into service clusters and component nodes, as shown in Table 2 below.

[0116]

[0117] Service component information is obtained through client objects from different cloud vendors and converted into a custom list of service cluster data items and cluster node data items, thereby shielding the differences in application programming interfaces (APIs) and data definitions provided by various cloud vendors. When traversing the resource type list to perform resource information synchronization or reconciliation tasks, this is accomplished through a synchronous concurrency management module. Each cloud tenant generates an independent API client object, and uses threads or coroutines to concurrently synchronize the leased resource information of each business line on different cloud platforms to the local database. There are two data format conversions: the first is to standardize the different cloud resource data formats into a custom cloud resource data format, and the second is to convert the custom cloud resource data format into a local database data format. The custom cloud resource data format is used to unify the resource data format definitions of different cloud vendors, while the local database data format is used to ensure compatibility with the resource data definitions of self-built internet data center server rooms.

[0118] Figure 2 This is a schematic diagram of a data synchronization technology architecture according to an embodiment of this application, such as... Figure 2As shown, based on the target proxy models corresponding to target cloud service provider 1, target cloud service provider 2, and target cloud service provider 3 respectively, the original full cloud storage data can be obtained; and the full local data can be obtained from the vehicle manufacturer's local database. Next, the original full cloud storage data and the full local data can be formatted to obtain the target format full cloud storage data and full local data. Then, data comparison can be performed to obtain the comparison results, and the vehicle manufacturer's local database can be updated based on the comparison results.

[0119] Taking the synchronization of public Internet Protocol (IP) addresses as an example, the synchronization steps are briefly described as follows: First, the cloud client object is called to retrieve public IP address data from the cloud and convert it into a cached version with the cloud resource identifier as the key and the local public IP address data as the value. Then, public IP address data from the local database is retrieved, filtered by cloud vendor and developer account, and converted into a cached version with the cloud resource identifier as the key and the local public IP address data as the value. Next, the two cached public IP address data dictionary objects are compared using the cloud resource identifier to categorize the deleted, modified, and newly added public IP addresses. Finally, the deleted, updated, and newly added public IP address lists are recorded in the local database. For resources marked as released on the cloud during the synchronization process, the platform notifies the resource administrator for secondary manual confirmation before deletion, thereby ensuring the accuracy and security of resource data information. By constructing a unified interface for cloud client interfaces and registering it to a global object, the system replaces the distribution of synchronization tasks to the application interface cloud interface gateway, reducing communication overhead between components and issues caused by interface anomalies. A unified cloud resource data format effectively masks differences in data definitions for similar resources from different cloud vendors, freeing users of the synchronization module from concern themselves with underlying details. Local caching of cloud resource data replaces independent cloud resource caching units, reducing resource overhead and component failure risks associated with external components. A multi-threaded concurrent model controls multiple cloud tenant client objects to simultaneously initiate synchronization resource tasks, improving synchronization efficiency. A two-layer data model of clusters and nodes, along with the construction of cluster-node object relationships, manages synchronization component resources. A reconciliation module ensures the consistency of all cloud resource data. A secondary confirmation mechanism for released resources is provided using instant messaging collaboration tools, strengthening the security of cloud resource data. The system is compatible with and supports the entry of asset data from proprietary internet data centers, using a custom cloud resource data format to mask differences in resource data definitions from cloud vendors, and using database table-defined resource data structures to unify the data formats of cloud leased resources and internet data center resources.

[0120] Figure 3This is a schematic diagram of another data synchronization technology architecture according to an embodiment of this application, such as... Figure 3 As shown, corresponding data can be obtained from at least one target cloud service provider and the vehicle manufacturer's local database, and the data format is unified based on a data format unification model. Next, data items missing from the second data dictionary object compared to the first data dictionary object are identified as items to be added; data items with different content from the first data dictionary object are identified as items to be modified; and data items present in the second data dictionary object but missing from the first data dictionary object are identified as items to be deleted. This yields comparison results, which are then used to synchronize data in the vehicle manufacturer's local database.

[0121] This application can collect and analyze hardware resource attribute information from traditional internet data center server rooms and various cloud vendors, such as virtual machines, physical machines, and disks; compare attribute information between self-built component clusters and cloud platform-as-a-service products; and abstract unified resource structure definitions and cloud resource object operation interfaces by using common network resource concepts, such as network address translation gateways, load balancers, public internet protocol addresses, bandwidth, domain name servers, certificates, virtual private clouds, peer-to-peer links, virtual private networks, enterprise routing, and physical leased lines. The synchronization management module calls cloud application programming interfaces to synchronize resources from different cloud tenant spaces to the platform's local database. For resources with frequently changing object attributes, a periodic synchronization management module is built to ensure consistency between cloud resource information and local database records in near real-time. To enhance resource data consistency, a global resource reconciliation module can be started during the low-peak hours of early morning each day to pull, compare, and record the latest resource data to the local database. After establishing a unified configuration management database resource management platform, resource data information and network topology between objects can be searched globally based on resource identifiers, reducing the time for fault information location and quickly resolving problems. At the same time, based on the generated global resource usage overview, it provides early warnings when resource usage reaches the warning threshold, thereby reducing system risks and preventing problems before they occur.

[0122] The method provided in this application includes the following steps: Initially, a full cloud resource data retrieval for a cloud tenant is performed, followed by data format conversion and storage in the platform's central database. The data model definition is divided into three parts: custom data models for different cloud vendors, a unified custom cloud resource data model, and a local database resource model definition. A cloud vendor resource retrieval application programming interface (API) is abstracted, and the unified internal interface methods and functions are implemented by client objects from different cloud vendors. By fetching cached cloud resource data and retrieving corresponding data from the local database, the data is unified into a uniform local resource data format through a data standardization module. Cloud resource identifiers are used as keys to compare cloud and local resource attribute information one by one. If data items with the same cloud resource identifier have inconsistent data between the cloud and local data, the cloud data is used and recorded in the update list queue. If the resource exists in the cloud but the local cloud resource identifier information is not available, the cloud data is recorded in the new addition list queue. If the local resource identifier data exists but the cloud does not, the local data is recorded in the deletion list queue. An analysis module categorizes newly added, modified, and deleted cloud resource data item queues, and then calls the resource data table interfaces for insertion, update, and deletion to record them in the database. By leveraging thread or coroutine technology, concurrent processing by different cloud tenant clients is achieved, simultaneously triggering the business line resource synchronization process, thereby improving data processing efficiency. Synchronization and reconciliation logic is abstracted into a task model for management, which can be divided into scheduled tasks, one-time tasks, and periodic tasks. Message queues are used to decouple task generation, task scheduling, and task execution logic. The task consumer is a persistent worker thread. After receiving a synchronization task event, it executes the resource synchronization process and records the task results, such as the types and quantities of added, modified, and deleted resources, in a local database, providing data for daily inspections. Local internet data center server room resource data or non-cloud-managed resource information is imported into the configuration management database management platform by calling external application interfaces through web platforms or scripts, including physical assets, network resources, service components, and business application data, along with related stakeholder or organizational information. To ensure the accuracy of released resource data, after the resource data is softly deleted in the background synchronization and reconciliation module, a secondary manual confirmation management mechanism and collaborative notification to relevant administrators are provided. After verification and confirmation, the resource data is manually deleted and released from the configuration management database management system offline.

[0123] Figure 4 This is a schematic diagram of a data synchronization process according to an embodiment of this application, such as... Figure 4As shown, firstly, a target proxy model corresponding to at least one target cloud service provider can be invoked from multiple proxy models. Based on the target proxy model, data access is performed on at least one target cloud service provider to obtain the raw full cloud storage data. Next, the raw full cloud storage data can be format-converted based on a data format unification model to obtain the full cloud storage data in the target format. Then, the full cloud storage data in the target format can be compared with the full local data in the vehicle manufacturer's local database to obtain the comparison results. Finally, based on the comparison results, data synchronization can be performed on the vehicle manufacturer's local database.

[0124] Figure 5 This is a schematic diagram of another data synchronization process according to an embodiment of this application, such as... Figure 5 As shown, firstly, a target proxy model corresponding to at least one target cloud service provider can be called from multiple proxy models. Based on the target proxy model, data access is performed on at least one target cloud service provider to obtain the raw full cloud storage data. Next, the raw full cloud storage data can be format-converted based on a data format unification model to obtain the target format full cloud storage data. Then, the target format full cloud storage data can be converted into a first data dictionary object, and the full local data can be converted into a second data dictionary object. Data of the same data resource type in both the first and second data dictionary objects uses a unified data format. The first and second data dictionary objects are compared to obtain the comparison result. Finally, based on the comparison result, data synchronization can be performed on the vehicle manufacturer's local database.

[0125] According to another aspect of the embodiments of this application, a data synchronization device is also provided. This device can execute the data synchronization method of the above embodiments. The specific implementation method and preferred application scenarios are the same as those of the above embodiments, and will not be described in detail here.

[0126] Figure 6 This is a schematic diagram of a data synchronization device according to an embodiment of this application, such as... Figure 6 As shown, the device includes the following: an acquisition module 602, a conversion module 604, a comparison module 606, and a synchronization module 608.

[0127] The system includes: an acquisition module 602, used to acquire raw full cloud storage data from at least one target cloud service provider in response to a data synchronization command; a conversion module 604, used to convert the raw full cloud storage data into a target format based on a unified data format model, wherein the unified data format model is used to convert data of the same data resource type from different cloud service providers into a unified data format; a comparison module 606, used to compare the target format full cloud storage data with the full local data in the vehicle manufacturer's local database to obtain a comparison result; and a synchronization module 608, used to synchronize data in the vehicle manufacturer's local database based on the comparison result.

[0128] The acquisition module is also used to call the target proxy model corresponding to at least one target cloud service provider from multiple proxy models; and to access data from at least one target cloud service provider based on the target proxy model to obtain the original full cloud storage data.

[0129] The acquisition module is also used to determine the provider identification information corresponding to at least one target cloud service provider; and based on the provider identification information, to call the target proxy model from multiple proxy models.

[0130] The acquisition module is also used to parse the data synchronization instructions and determine the type of data resource to be synchronized; based on the target proxy model, it calls the resource type encapsulation interface corresponding to the data resource type to obtain the original full cloud storage data.

[0131] The acquisition module is also used to access data from at least one target cloud service provider by calling the resource type encapsulation interface corresponding to the data resource type and the access credential information corresponding to at least one target cloud service provider based on the target proxy model, and to obtain the original full cloud storage data.

[0132] The comparison module is also used to convert the full cloud storage data in the target format into a first data dictionary object and convert the full local data into a second data dictionary object. Data of the same data resource type in the first and second data dictionary objects adopt a unified data format. The first and second data dictionary objects are compared to obtain the comparison result.

[0133] The comparison module is also used to compare the first data dictionary object and the second data dictionary object to determine the difference data items; and to determine the comparison result based on the difference data items.

[0134] The comparison module is further used to compare the first data dictionary object and the second data dictionary object to determine the data items to be added, the data items to be modified, and / or the data items to be deleted; and to determine the difference data items based on the data items to be added, the data items to be modified, and / or the data items to be deleted.

[0135] The comparison module is further used to compare the first data dictionary object and the second data dictionary object; to identify data items missing in the second data dictionary object compared to the first data dictionary object as data items to be added; and / or to identify data items in the second data dictionary object that have different data content compared to the first data dictionary object as data items to be modified; and / or to identify data items that exist in the second data dictionary object but are missing in the first data dictionary object as data items to be deleted.

[0136] The synchronization module is also used to send a data deletion review request when the comparison result contains data items to be deleted; and to delete the corresponding data items in the automaker's local database in response to receiving data deletion confirmation feedback.

[0137] The synchronization module is also used to perform corresponding addition and / or modification operations on the corresponding data items in the automaker's local database when the comparison results contain data items to be added and / or data items to be modified.

[0138] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0139] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0140] The aforementioned memory can refer to devices inside a computer used to store data and programs, including RAM, hard disks, etc. RAM can be used to temporarily store running programs and data, while hard disks can be used to store programs and data long-term. Memory enables the computer to read and write data and execute programs. The aforementioned processor is responsible for executing instructions in computer programs and performing data processing. It can also be responsible for controlling and executing various operations, including arithmetic operations, logical operations, and data transmission.

[0141] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0142] The aforementioned computer storage media can refer to the media used in computer memory to store certain discontinuous physical quantities. Computer storage media mainly include semiconductors, magnetic cores, magnetic drums, magnetic tapes, laser discs, etc. Computer-readable storage media include stored programs, which can be a set of instructions that a computer can recognize and execute, running on an electronic computer to meet certain information needs.

[0143] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0144] The aforementioned computer program products can refer to software programs that have been written, tested, and released, and can run on computers or other devices. Computer program products can include application programs, operating systems, utility software, etc., used to achieve specific functions or solve specific problems.

[0145] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0146] The aforementioned non-volatile computer-readable storage medium can refer to a medium for storing data. Non-volatile computer-readable storage media can retain data without loss when power is off and can be used to store long-term data, such as operating systems, applications, and user files. Non-volatile storage media can include hard disk drives, solid-state drives, optical disks, and flash memory storage devices, etc.

[0147] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0148] The aforementioned computer program can refer to a set of instructions used to tell the computer to perform specific tasks or operations. Computer programs can be written by programmers using specific programming languages ​​and can include algorithms, data structures, logic, and control flow. Computer programs can be used for a variety of purposes, including application software, operating systems, etc.

[0149] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0152] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0154] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data synchronization method, characterized in that, include: In response to a data synchronization command, the system retrieves the raw, full cloud storage data from at least one target cloud service provider. Based on the data format unification model, the original full cloud storage data is converted to obtain the full cloud storage data in the target format. The data format unification model is used to convert data of the same data resource type from different cloud service providers into a unified data format. The full cloud storage data in the target format is compared with the full local data in the vehicle manufacturer's local database to obtain the comparison results; Based on the comparison results, the local database of the car manufacturer is synchronized.

2. The data synchronization method according to claim 1, characterized in that, Obtain the raw, full cloud storage data from at least one target cloud service provider, including: From multiple proxy models, invoke the target proxy model corresponding to the at least one target cloud service provider; Based on the target proxy model, data access is performed on the at least one target cloud service provider to obtain the original full cloud storage data.

3. The data synchronization method according to claim 2, characterized in that, From multiple proxy models, invoking the target proxy model corresponding to the at least one target cloud service provider includes: Determine the provider identification information corresponding to the at least one target cloud service provider; Based on the provider identification information, the target proxy model is invoked from among the multiple proxy models.

4. The data synchronization method according to claim 2, characterized in that, Based on the target proxy model, data access is performed on the at least one target cloud service provider to obtain the original full cloud storage data, including: The data synchronization command is parsed to determine the type of data resource to be synchronized; Based on the target proxy model, the resource type encapsulation interface corresponding to the data resource type is called to obtain the original full cloud storage data.

5. The data synchronization method according to claim 4, characterized in that, Based on the target proxy model, the resource type encapsulation interface corresponding to the data resource type is called to obtain the original full cloud storage data, including: Based on the target proxy model, the resource type encapsulation interface corresponding to the data resource type and the access credential information corresponding to the at least one target cloud service provider are invoked to access the data from the at least one target cloud service provider and obtain the original full cloud storage data.

6. The data synchronization method according to any one of claims 1 to 5, characterized in that, The full cloud storage data in the target format is compared with the full local data in the vehicle manufacturer's local database to obtain the comparison results, including: The full cloud storage data in the target format is converted into a first data dictionary object, and the full local data is converted into a second data dictionary object, wherein data of the same data resource type in the first data dictionary object and the second data dictionary object adopt a unified data format; The first data dictionary object and the second data dictionary object are compared to obtain the comparison result.

7. The data synchronization method according to claim 6, characterized in that, The comparison between the first data dictionary object and the second data dictionary object yields the comparison result, including: The first data dictionary object and the second data dictionary object are compared to determine the difference data items; The comparison result is determined based on the difference data items.

8. The data synchronization method according to claim 7, characterized in that, The first data dictionary object and the second data dictionary object are compared to determine the difference data items, including: The first data dictionary object and the second data dictionary object are compared to determine the data items to be added, the data items to be modified, and / or the data items to be deleted. The difference data item is determined based on the data item to be added, the data item to be modified, and / or the data item to be deleted.

9. The data synchronization method according to claim 8, characterized in that, The first data dictionary object and the second data dictionary object are compared to determine the data items to be added, the data items to be modified, and / or the data items to be deleted, including: Compare the first data dictionary object and the second data dictionary object; The data items missing in the second data dictionary object compared to the first data dictionary object are determined as the data items to be added; And / or, The data items whose data content differs from that of the first data dictionary object in the second data dictionary object are identified as the data items to be modified. And / or, The data items that exist in the second data dictionary object but are missing in the first data dictionary object are identified as the data items to be deleted.

10. The data synchronization method according to any one of claims 1 to 5, characterized in that, Based on the comparison results, data synchronization is performed on the automaker's local database, including: If the comparison result contains data items to be deleted, a data deletion review request is sent. Upon receiving confirmation of data deletion, the corresponding data item in the vehicle manufacturer's local database is deleted.

11. The data synchronization method according to any one of claims 1 to 5, characterized in that, Based on the comparison results, data synchronization is performed on the automaker's local database, including: If the comparison result contains data items to be added and / or data items to be modified, the corresponding data items in the vehicle manufacturer's local database shall be subject to the specified addition and / or modification operations.

12. A data synchronization device, characterized in that, include: The acquisition module is used to acquire the raw full cloud storage data from at least one target cloud service provider in response to a data synchronization command. The conversion module is used to convert the original full cloud storage data into a format based on a unified data format model to obtain full cloud storage data in a target format. The unified data format model is used to convert data of the same data resource type from different cloud service providers into a unified data format. The comparison module is used to compare the full cloud storage data in the target format with the full local data in the vehicle manufacturer's local database to obtain the comparison result. The synchronization module is used to synchronize data in the local database of the car manufacturer based on the comparison results.

13. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the data synchronization method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the data synchronization method according to any one of claims 1 to 11.

15. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the data synchronization method according to any one of claims 1 to 11.

Images