Automobile after-sales service information retrieval method and system based on cloud database

Abstract

The invention relates to the technical field of automobile after-sales service information retrieval based on a cloud database, in particular to an automobile after-sales service information retrieval method and system based on the cloud database, and the method comprises the following steps: obtaining an automobile part number, and decomposing the automobile part number into a plurality of semantic fragments; storing the semantic fragment and the unique identifier of the automobile part in a part information table of a cloud database; constructing a global metadata directory; asynchronously updating the global metadata directory; receiving a user query request, and extracting a query semantic tag; directionally sending the query request to a related data partition containing target data; performing local retrieval on the query request to obtain a local retrieval result; the local retrieval result is transmitted back to the distributed semantic routing layer; and aggregating the retrieval results received by the distributed semantic routing layer and returned by each data partition to obtain a final retrieval result. The query efficiency and the overall performance of the system can be improved.

Description

Technical Field

[0001] This invention relates to the technical field of automotive after-sales service information retrieval based on cloud databases, specifically to a method and system for automotive after-sales service information retrieval based on cloud databases. Background Technology

[0002] In the automotive aftermarket service sector, cloud-based database systems are widely used to efficiently manage and retrieve massive amounts of repair records, parts inventory, customer feedback, and vehicle diagnostic data. Initially, parts numbers typically had simple structures, such as pure numbers or fixed-length alphanumeric combinations. Systems generally used standard database B-tree indexes for management, a method that proved highly efficient for both exact match and range queries at the time.

[0003] However, with the rapid development of the automotive industry and the increasing complexity of the global supply chain, the sources and types of parts have increased dramatically. A new parts numbering system has been introduced. This new numbering is no longer a simple, fixed format, but has evolved into a composite string containing multiple pieces of information, such as "AUDI-A4-ENG-OILPUMP-2023-V2.1". These composite numbers have variable lengths and contain various connecting symbols, making them more like a descriptive text. Faced with this new type of text-like composite numbering, the existing B-tree index began to expose its inherent shortcomings. Summary of the Invention

[0004] The purpose of this invention is to address the aforementioned shortcomings by proposing a cloud database-based method and system for retrieving automotive after-sales service information.

[0005] The present invention adopts the following technical solution: A method for retrieving automotive after-sales service information based on a cloud database, the method comprising the following steps: Obtain the vehicle part number and perform semantic processing on the vehicle part number, decomposing the vehicle part number into multiple semantic fragments; Semantic fragments, along with unique identifiers for automotive parts, are stored in a parts information table in a cloud database. Construct a global metadata directory, which records the distribution information of semantic fragments in each data partition; Asynchronously update the global metadata directory, and asynchronously update the semantic fragments of newly entered auto parts and the partition information where the newly entered auto parts are located; Receive user query requests, perform semantic parsing on the user query requests, and extract query semantic tags; Based on the query semantic tags and the asynchronously updated global metadata directory, the query request is directed to the relevant data partition containing the target data; Within the relevant data partitions, based on the indexes created for semantic fragments in the parts information table, local retrieval is performed on the query requests to obtain local retrieval results; The local search results are sent back to the distributed semantic routing layer. The search results received by the distributed semantic routing layer from the data partitions are aggregated to obtain the final search results.

[0006] This technical solution enables efficient fuzzy queries for complex part numbers by semantically processing the part numbers and constructing a global metadata directory. At the same time, through asynchronous update mechanisms and distributed retrieval, it effectively solves the performance bottleneck of traditional indexes in a distributed environment and the additional overhead caused by full-text indexes, significantly improving query efficiency and overall system performance.

[0007] This application also discloses a cloud database-based automotive after-sales service information retrieval system, applied to a cloud database-based automotive after-sales service information retrieval method. The system includes: The processing module obtains the vehicle part number and performs semantic processing on the vehicle part number, decomposing the vehicle part number into multiple semantic fragments; The storage module stores semantic fragments along with the unique identifiers of automotive parts in the parts information table of the cloud database; The module builds a global metadata directory, which records the distribution information of semantic fragments in each data partition. The update module asynchronously updates the global metadata directory and asynchronously updates semantic fragments based on newly entered auto parts and the partition information where the newly entered auto parts are located. The parsing module receives user query requests, performs semantic parsing on the user query requests, and extracts query semantic tags; The sending module, based on the query semantic tags and the asynchronously updated global metadata directory, directs the query request to the relevant data partition containing the target data; The retrieval module performs local retrieval of query requests based on the index built for semantic fragments in the parts information table within the relevant data partitions, and obtains local retrieval results. The return module sends the local search results back to the distributed semantic routing layer; The aggregation module aggregates the search results received by the distributed semantic routing layer from each data partition to obtain the final search results.

[0008] This application provides a system-level solution through this technical solution. Through modular design, it achieves efficient retrieval of complex automotive part numbers and supports data management and querying in a distributed environment, effectively solving the problems of low query efficiency, high storage overhead, and complex system maintenance in the prior art.

[0009] This application avoids the additional storage and update overhead of full-text indexing by building indexes on semantic segments, while the asynchronous update mechanism ensures the real-time nature of data writing.

[0010] To further understand the features and technical content of the present invention, please refer to the following detailed description and drawings of the present invention. However, the drawings provided are for reference and illustration only and are not intended to limit the present invention. Attached Figure Description

[0011] Figure 1 This is a flowchart of a method for retrieving automotive after-sales service information based on a cloud database, according to the present invention. Figure 2 This is a schematic diagram of the structure of a cloud database-based automotive after-sales service information retrieval system according to the present invention. Detailed Implementation

[0012] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can understand the advantages and effects of the present invention from the content disclosed in this specification. The present invention can be implemented or applied through other different specific embodiments, and various details in this specification can also be modified and changed based on different viewpoints and applications without departing from the spirit of the present invention. Furthermore, the accompanying drawings of the present invention are for simple illustrative purposes only and are not depictions of actual dimensions; this is stated in advance. The following embodiments will further describe the relevant technical content of the present invention in detail, but the disclosed content is not intended to limit the scope of protection of the present invention.

[0013] This embodiment provides a method and system for retrieving automotive after-sales service information based on a cloud database, combined with... Figure 1 and Figure 2 As shown.

[0014] refer to Figure 1 A method for retrieving automotive after-sales service information based on a cloud database, comprising the following steps: Obtain the vehicle part number and perform semantic processing on the vehicle part number, decomposing the vehicle part number into multiple semantic fragments; Semantic fragments, along with unique identifiers for automotive parts, are stored in a parts information table in a cloud database. Construct a global metadata directory, which records the distribution information of semantic fragments in each data partition; Asynchronously update the global metadata directory, and asynchronously update the semantic fragments of newly entered auto parts and the partition information where the newly entered auto parts are located; Receive user query requests, perform semantic parsing on the user query requests, and extract query semantic tags; Based on the query semantic tags and the asynchronously updated global metadata directory, the query request is directed to the relevant data partition containing the target data; Within the relevant data partitions, based on the indexes created for semantic fragments in the parts information table, local retrieval is performed on the query requests to obtain local retrieval results; The local search results are sent back to the distributed semantic routing layer. The search results received by the distributed semantic routing layer from the data partitions are aggregated to obtain the final search results.

[0015] Among them, "automotive part number" refers to the code used to uniquely identify automotive parts, which may be in the form of pure numbers, alphanumeric combinations, or composite strings containing multiple information.

[0016] "Semantic processing" refers to analyzing and interpreting the part numbers of automobiles, breaking them down into "semantic fragments" with independent meanings, such as brand, model, part type, year, etc.

[0017] A "semantic fragment" is the smallest unit of information in an automotive part number that has a specific meaning.

[0018] "Cloud database" refers to database services deployed on cloud computing platforms, which have features such as elastic scaling, high availability, and distributed storage.

[0019] The "Parts Information Table" is a table in the cloud database used to store detailed information about automotive parts, which includes semantic fragments and unique identifiers for each part.

[0020] The "Global Metadata Catalog" is a centralized index structure used to record the distribution of semantic fragments in each data partition, so as to quickly locate the data partition containing a specific semantic fragment.

[0021] "Data partitioning" refers to the logical or physical division of data into independent storage units in a cloud database, with each partition capable of independent data storage and retrieval.

[0022] The "Distributed Semantic Routing Layer" is a middleware layer responsible for receiving user query requests and routing them to the corresponding data partitions based on the global metadata directory.

[0023] The method proposed in this application aims to achieve rapid and accurate retrieval of automotive after-sales service information through a series of collaborative steps.

[0024] First, after obtaining the auto part number, it needs to be semantically processed, breaking it down into multiple semantic segments. For example, an auto part number "AUDI-A4-ENG-OILPUMP-2023-V2.1" can be decomposed into semantic segments such as "AUDI", "A4", "ENG", "OILPUMP", "2023", and "V2.1". This semantic processing can be performed using a predefined set of rules, such as using regular expressions to match specific delimiters (e.g., "-") to extract segments. Alternatively, machine learning-based natural language processing techniques can be used to perform pattern recognition and entity extraction on the part number, thereby more intelligently identifying semantic segments.

[0025] Subsequently, the semantic fragments, along with the unique identifiers of the auto parts, are stored in a parts information table in the cloud database. For example, each semantic fragment can be a field in the parts information table, or associated with the unique identifier of the part through a related table. In one implementation, each semantic fragment can be stored as a separate column in the parts information table, with independent indexes created for these columns. In another implementation, all semantic fragments can be aggregated into a single text field, and the database's full-text indexing capabilities can be used for storage and retrieval.

[0026] Next, a global metadata directory is constructed, recording the distribution information of semantic fragments across each data partition. The global metadata directory can be a standalone database table or a distributed caching system. For example, it can store a mapping between each semantic fragment and the data partitions in which it exists. In one implementation, the global metadata directory can be a simple key-value pair store, where the key is the semantic fragment and the value is a list of data partitions containing that semantic fragment. In another implementation, the global metadata directory can be a more complex inverted index structure, where each semantic fragment points to a list of data partition IDs.

[0027] Furthermore, the global metadata catalog is updated asynchronously, based on the semantic fragments of newly entered automotive parts and the partition information where these parts reside. This asynchronous update mechanism ensures the real-time nature and accuracy of the global metadata catalog without significantly delaying data write operations. For example, when new automotive part information is written to a data partition, that partition can trigger an event to notify the global metadata management service to update. In one implementation, the data partition can write the change event to a message queue, from which the global metadata management service consumes these events and updates the catalog. In another implementation, the global metadata management service can periodically poll each data partition to check for new semantic fragments or partition information that needs updating.

[0028] After receiving a user query request, semantic parsing is required to extract semantic tags. For example, if a user enters "find oil pump for model A4," the system can parse "A4" and "oil pump" as semantic tags. This semantic parsing can be achieved through technologies such as keyword matching and natural language understanding. In one implementation, the system can maintain a predefined keyword dictionary and match the words in the user's query against the dictionary to extract semantic tags. In another implementation, machine learning models can be used to perform intent recognition and entity extraction on the user's query, thereby obtaining more accurate semantic tags.

[0029] Then, based on the query semantic tag and the asynchronously updated global metadata directory, the query request is directed to the relevant data partition containing the target data. For example, if the query semantic tag contains "OILPUMP", and the global metadata directory shows that "OILPUMP" exists in data partitions 1 and 3, then the query request will be sent to these two data partitions. This directed sending mechanism avoids scanning all data partitions, significantly improving query efficiency. In one implementation, the distributed semantic routing layer can directly send the query request to the corresponding IP address or service port based on the mapping relationship in the global metadata directory. In another implementation, the routing layer can utilize a load balancer to distribute the request to one or more of the multiple data partitions containing the target data.

[0030] Within the relevant data partition, based on the indexes created for semantic fragments in the parts information table, a local retrieval is performed on the query request to obtain local search results. Since the query request has been directed to the data partition containing the target data, and the parts information table has already created indexes for the semantic fragments, the local retrieval can be completed efficiently. For example, if the parts information table has an inverted index for each semantic fragment, then during a local retrieval, the parts information containing the specific semantic fragment can be quickly located directly through the index. In one implementation, the local retrieval can use the database's built-in full-text search functionality to efficiently query the semantic fragment fields. In another implementation, a dedicated search engine (such as Elasticsearch) can be used to perform local retrieval within the data partition for even faster response times.

[0031] Subsequently, the local search results are sent back to the distributed semantic routing layer. Each data partition, after completing its local search, sends its results back to the distributed semantic routing layer for further processing. For example, the local search results may contain unique identifiers of matching automotive parts and their related attributes. In one implementation, the local search results can be sent back in JSON or Protobuf format via HTTP / RPC protocol. In another implementation, to improve transmission efficiency, streaming or batch transmission methods can be used to send back the results.

[0032] Finally, the search results received by the distributed semantic routing layer from each data partition are aggregated to obtain the final search results. The distributed semantic routing layer is responsible for collecting local search results from all relevant data partitions and performing operations such as deduplication, sorting, and merging before presenting them to the user. For example, if multiple data partitions return the same accessory information, the aggregation layer will perform deduplication; if sorting by relevance or time order is required, the aggregation layer will also perform corresponding processing. In one implementation, the aggregation layer can simply merge and deduplicate all results. In another implementation, the aggregation layer can perform more complex processing on the results according to preset business logic, such as sorting by accessory inventory or update time, or performing secondary filtering of the results.

[0033] This application further proposes the following steps for asynchronously updating the global metadata directory: In the local maintenance semantic fragment change event stream of each data partition, whenever new part information is written to the corresponding data partition, after the semantic fragment of the new part information is parsed, the corresponding change is appended as an event to the local maintenance semantic fragment change event stream. The global metadata management service periodically pulls change events from the locally maintained semantic fragment change event stream of each data partition, and returns all new events since the last successful pull based on the pull progress indicator, which helps to improve the continuity of asynchronous updates. When the global metadata management service encounters network problems while pulling change events, it will retry pulling under the preset retry policy; After successfully retrieving the change events for each data partition, the global metadata management service iterates through all semantic fragments contained in the change events, identifies new semantic fragments and adds them to the semantic fragment list in the global metadata directory, and then updates the presence marker of the semantic fragments in the corresponding data partitions.

[0034] Specifically, in the local maintenance semantic fragment change event stream of each data partition, whenever new part information is written to the corresponding data partition, the system performs semantic parsing on the auto part number, decomposing it into multiple semantic fragments. These semantic fragments, along with the unique identifier of the auto part, are then stored in the part information table of the cloud database. During this process, changes to semantic fragments related to the newly written part information are captured and appended as a separate event to the local maintenance semantic fragment change event stream corresponding to that data partition. This event stream can be implemented as a persistent, append-only data structure, such as a message queue or a distributed log system, to ensure the integrity and order of change events.

[0035] The global metadata management service is configured to periodically pull change events from the locally maintained semantic fragment change event streams of each data partition. To ensure the continuity and efficiency of the pull process, the service maintains a pull progress indicator that records the position or offset of the last successfully pulled event stream. During each pull, the global metadata management service, based on this indicator, returns only all newly added events since the last successful pull, thus avoiding duplicate processing of already pulled events and ensuring that all change events are processed promptly.

[0036] In practical applications, considering the potential network instability issues that distributed systems may face, a pre-defined retry strategy will be initiated when the global metadata management service encounters network problems during the process of pulling change events. This retry strategy may include, but is not limited to, exponential backoff, fixed-interval retries, or jittered retry mechanisms, to automatically retry the pull operation in the event of a temporary network failure, thereby improving the robustness of the system and the reliability of data synchronization.

[0037] Furthermore, after successfully retrieving change events from each data partition, the global metadata management service processes these events. Specifically, the service iterates through all semantic fragments contained in the change events and identifies any new semantic fragments not yet recorded in the global metadata directory. Once new semantic fragments are identified, they are added to the semantic fragment list in the global metadata directory. Simultaneously, for all semantic fragments in all change events, regardless of whether they are new or not, the global metadata management service updates their presence markers in the corresponding data partitions to accurately reflect which data partition each semantic fragment exists in, thus providing an accurate basis for routing subsequent query requests.

[0038] In some preferred embodiments, it is assumed that the cloud database contains three data partitions: partition A, partition B, and partition C. When information about a new automotive part, "engine piston 100," is written to partition A, its part number is semantically resolved into three semantic fragments: "engine," "piston," and "100." Change events for these semantic fragments are appended to the locally maintained semantic fragment change event stream of partition A. Subsequently, when information about a new automotive part, "brake pad 200," is written to partition B, change events for its semantic fragments "brake pad" and "200" are appended to the locally maintained semantic fragment change event stream of partition B. The global metadata management service periodically pulls these change events from the event streams of partitions A and B. For example, in one pull cycle, the service pulls change events for "engine," "piston," and "100" from partition A and change events for "brake pad" and "200" from partition B. The service checks the global metadata catalog. If "engine," "piston," or "brake pad" are new semantic fragments, it adds them to the catalog and updates the presence markers of all these semantic fragments in partitions A and B. If a brief network interruption occurs between partition A and the global metadata management service during the fetch process, a retry policy is automatically triggered. The fetch is retried after the network is restored, ensuring that the change event for "engine piston 100" is ultimately successfully processed, thus guaranteeing the real-time performance and accuracy of the global metadata catalog.

[0039] When data partitions use a high-availability replication architecture, the steps for asynchronously updating the global metadata directory include: When new auto parts information is written to a data partition of the cloud database, the system performs semantic parsing on the auto parts number, decomposing the auto parts number into multiple semantic fragments. In the local maintenance semantic fragment change event stream of the data partition, the change of the semantic fragment is appended as an event to the local maintenance semantic fragment change event stream; When a data partition adopts a high-availability replication architecture, after the primary replica of the data partition receives a request to write automotive parts information and parses out the semantic fragment, it appends the change event of the semantic fragment to the local maintenance semantic fragment change event stream of the primary replica. The primary replica synchronously replicates the semantic fragment change events to the local maintenance semantic fragment change event stream of all secondary replicas; When a master-slave switch occurs in a data partition, the new master replica takes over the write operations and continues to append the semantic fragment change events to the local maintenance semantic fragment change event stream of the new master replica, and synchronously replicates them to other replicas; The global metadata management service pulls semantic fragment change events from the local maintenance semantic fragment change event stream of the current primary replica of the data partition.

[0040] Specifically, when new automotive parts information is written to a data partition in the cloud database, that partition is responsible for receiving and processing the write request. The system first performs semantic parsing on the automotive parts number. The purpose is to transform the original, potentially structured or unstructured, automotive parts number into more granular, semantically defined fragments. For example, "engine model XYZ-123" is broken down into semantic fragments such as "engine," "model," "XYZ," and "123." These semantic fragments form the basis for subsequent retrieval and indexing. Subsequently, in the local maintenance event stream of the semantic fragment change, the changes to these semantic fragments are appended as events to this event stream. This event stream can be understood as an ordered, append-only log, recording all add, delete, and modify operations related to semantic fragments. Its purpose is to provide a reliable and traceable change record for the global metadata management service to retrieve.

[0041] In a high-availability replication architecture, data partitioning typically employs one primary replica and multiple secondary replicas. The primary replica handles all write operations and synchronizes their changes to the secondary replicas. Therefore, when the primary replica receives a write request for automotive parts information and parses out semantic fragments, it appends the semantic fragment change events to its locally maintained semantic fragment change event stream. This ensures that all write operation change events are first recorded on the primary replica. Furthermore, the primary replica synchronously replicates these semantic fragment change events to the locally maintained semantic fragment change event streams of all secondary replicas. This synchronous replication mechanism ensures the consistency of event streams between the primary and secondary replicas. Even if the primary replica fails, the secondary replicas still possess complete event records, providing a data foundation for subsequent primary-secondary failover. Synchronous replication can be implemented using various technologies, such as log-based replication and streaming replication, with the core principle being to guarantee the order and integrity of events.

[0042] In practical applications, during a master-slave switch in a data partition, such as due to a primary replica failure or maintenance, a secondary replica is promoted to the new primary replica. At this time, the new primary replica takes over all write operations and continues to append semantic fragment change events to the new primary replica's locally maintained semantic fragment change event stream, synchronously replicating this to other replicas. This mechanism ensures that during the master-slave switch, write operations in the event stream can seamlessly migrate from the old primary replica to the new primary replica, avoiding event loss or interruption. Finally, the global metadata management service pulls the semantic fragment change events from the locally maintained semantic fragment change event stream of the current primary replica of the data partition. Since the primary replica is always the sole entry point for write operations, and its event stream ensures high availability through synchronous replication, the global metadata management service only needs to focus on the current primary replica to obtain all the latest change events, thus simplifying the retrieval logic and ensuring the authority of the data source.

[0043] In some preferred embodiments, it is assumed that a cloud database system contains three data partitions, each employing a master-slave replication architecture, meaning each partition has one master replica and two slave replicas. When an automaker releases a batch of new automotive parts, such as "brake pad model A100," the information needs to be entered into the cloud database.

[0044] Specifically, when the accessory information "Brake pad model A100" is written to data partition 1, the primary replica of data partition 1 receives the write request. The system first performs semantic parsing on "Brake pad model A100," breaking it down into semantic fragments such as "brake pad," "model," and "A100." Subsequently, the primary replica appends the change event containing these semantic fragments to its locally maintained semantic fragment change event stream. Almost simultaneously, the primary replica, through its internal replication mechanism, synchronously replicates this change event to the locally maintained semantic fragment change event streams of the two secondary replicas in data partition 1.

[0045] Suppose that at some point, the primary replica of data partition 1 fails. Upon detecting the primary replica failure, the system automatically promotes one of the secondary replicas to the new primary replica. If new component information, such as "oil filter model B200," is then written to data partition 1, the new primary replica will receive and process the write request. The new primary replica performs semantic parsing on "oil filter model B200," generates a corresponding semantic fragment change event, and appends it to its own (the new primary replica's) local maintenance semantic fragment change event stream. Simultaneously, the new primary replica will also synchronously replicate this change event to the remaining secondary replicas.

[0046] During this process, the global metadata management service periodically pulls change events from the locally maintained semantic fragment change event stream of the current primary replica of data partition 1 (whether it is the original primary replica or the new primary replica promoted after a failure). Because the event stream is always synchronized between the primary and secondary replicas and can be seamlessly taken over during primary-secondary switching, the global metadata management service can continuously and uninterruptedly obtain all the latest semantic fragment change information, thereby ensuring the real-time performance and accuracy of the global metadata catalog. Even if the underlying data partition fails or switches, the reliability of metadata updates will not be affected.

[0047] The global metadata management service periodically pulls change events from the locally maintained semantic fragment change event stream of each data partition, and returns all newly added events since the last successful pull based on the pull progress indicator. The steps include: The global metadata management service obtains the current cumulative amount of events in the local maintenance semantic fragment change event stream of each data partition; The global metadata management service adjusts the fetch interval for each data partition based on the cumulative amount of events. The global metadata management service maintains independent fetch tasks for each data partition; The global metadata management service adjusts the concurrency of each fetch task based on the load of each data partition; The global metadata management service uses independent pull tasks to pull change events from the locally maintained semantic fragment change event stream of each data partition with adjusted pull intervals and concurrency. Based on the pull progress indicator, it returns all new events since the last successful pull.

[0048] Specifically, the global metadata management service is configured to monitor and obtain the current cumulative amount of events in the locally maintained semantic fragment change event stream for each data partition in real time. This cumulative amount can be understood as the number of new semantic fragment change events added to that data partition since the last successful fetch. By obtaining this cumulative amount, the global metadata management service can understand the data update activity of each data partition.

[0049] The global metadata management service dynamically adjusts the fetch interval for each data partition based on the accumulated event volume. For example, when the accumulated event volume for a data partition is high, it indicates that the data in that partition is updated frequently, and the global metadata management service can shorten the fetch interval for that partition to synchronize the latest data more quickly; conversely, when the accumulated event volume is low, the fetch interval can be appropriately extended to reduce unnecessary system overhead.

[0050] In practical applications, the global metadata management service maintains an independent pull task for each data partition. This means that each data partition has one or a group of dedicated threads or processes responsible for pulling change events from its locally maintained semantic fragment change event stream, thereby avoiding mutual interference between pull operations of different data partitions and improving the parallelism and isolation of the pull process.

[0051] Furthermore, the global metadata management service can adjust the concurrency of each fetch task based on the load of each data partition. The load of a data partition can include metrics such as CPU utilization, memory usage, and network bandwidth utilization. For example, when the load of a data partition is low, the concurrency of the corresponding fetch task can be increased to accelerate event fetching; when the load is high, the concurrency can be reduced to avoid putting excessive pressure on the data partition.

[0052] Therefore, the global metadata management service uses these independent pull tasks, with adjusted pull intervals and concurrency, to pull change events from the locally maintained semantic fragment change event streams of each data partition. During the pull process, a pull progress indicator is used to record the position of the last successful pull, ensuring that each pull accurately returns all new events since the last successful pull, thereby guaranteeing the integrity and continuity of data synchronization.

[0053] This application further proposes a process whereby, after successfully retrieving change events from each data partition, the global metadata management service iterates through all semantic fragments contained in the change events, identifies new semantic fragments and adds them to the semantic fragment list in the global metadata directory, and then updates the presence markers of the semantic fragments in the corresponding data partitions. This process includes: After receiving change events from each data partition, the global metadata management service aggregates all semantic fragments contained in the change events to form batch processing units. The global metadata management service maintains a cache of the global semantic fragment set in memory, and for each semantic fragment in the batch processing unit, it queries the memory cache to determine whether each semantic fragment is a new semantic fragment. The global metadata management service adds the newly identified semantic fragments to the memory cache; The global metadata management service packages all semantic fragments and the update operations of the corresponding data partitions in the batch processing unit into a batch processing request. The global metadata management service sends batch requests to the distributed storage system for asynchronous persistent updates, and sets a timer to periodically synchronize new semantic fragments and existence markers in the memory cache to the distributed storage system.

[0054] Specifically, when the global metadata management service receives change events from various data partitions, it does not immediately process each individual semantic fragment. Instead, it collects and integrates all semantic fragments contained in these change events, forming one or more batch processing units. This aggregation operation aims to reduce the granularity of individual operations and improve processing efficiency. To quickly determine whether a semantic fragment is a new semantic fragment, the global metadata management service maintains a cache of a global set of semantic fragments in memory. This cache stores all currently known semantic fragments existing in the global metadata directory. When a semantic fragment in a batch processing unit is processed, the system first queries this memory cache. If the semantic fragment is not found in the cache, it is identified as a new semantic fragment. This memory caching mechanism significantly speeds up the identification of new semantic fragments and avoids frequent access to persistent storage.

[0055] In practical applications, once new semantic fragments are identified, they are immediately added to the memory cache to ensure that subsequent judgments are based on the latest global set of semantic fragments. Subsequently, all semantic fragments (including new and existing ones) and their existence marker updates in the corresponding data partitions within the batch processing unit are packaged into one or more batch requests. These batch requests effectively reduce the number of interactions with the distributed storage system, lowering network overhead and reducing write pressure on the storage system. Furthermore, these batch requests are sent to the distributed storage system for asynchronous persistent updates. Asynchronous updates mean that the global metadata management service can continue processing other tasks without waiting for confirmation from the storage system to complete the write operation, thereby improving the overall throughput and response speed of the system. To ensure that the data in the memory cache is ultimately reliably written to persistent storage, the global metadata management service also sets a timer. This timer periodically triggers a synchronization operation, synchronizing the new semantic fragments identified in the memory cache and the updated existence markers to the distributed storage system, thus guaranteeing data consistency and durability.

[0056] In some preferred embodiments, it is assumed that within a certain time period, multiple data partitions of the cloud database receive a large number of new automotive parts information write requests. After semantic parsing, this new parts information generates thousands of semantic fragment change events, which are appended to the locally maintained semantic fragment change event streams of each data partition. The global metadata management service periodically pulls change events from these event streams. Upon receiving these change events, the global metadata management service does not immediately process each semantic fragment individually, but instead aggregates all semantic fragments contained in these events to form one or more batch processing units. For example, every 500 semantic fragments can be aggregated into one batch processing unit. Subsequently, for each semantic fragment in a batch processing unit, the global metadata management service first queries its in-memory global semantic fragment set cache. If a semantic fragment does not exist in the cache, it is identified as a new semantic fragment and immediately added to the cache. For example, new semantic fragments such as "engine model XYZ" and "brake pad brand ABC" are identified and added to the cache. Next, the global metadata management service packages all semantic fragments (including new and existing ones) and their corresponding data partition existence marker update operations in this batch processing unit into a batch processing request. For example, a batch processing request might contain the identification results and existence marker update instructions for 500 semantic fragments. This batch processing request is then sent to the distributed storage system for asynchronous persistent updates. The global metadata management service can continue processing the next batch processing unit without waiting for the storage system to complete the write. Simultaneously, the global metadata management service sets a timer, for example, triggered every 5 seconds. When the timer triggers, all new semantic fragments and existence marker updates that have not yet been persisted in the memory cache are uniformly synchronized to the distributed storage system. Even if a batch processing request fails to complete persistence immediately due to network fluctuations, the periodic synchronization mechanism ensures that this data is eventually written, thus guaranteeing the eventual consistency of the global metadata directory. In this way, even when facing high-concurrency component information writing and semantic fragment changes, the global metadata directory can maintain efficient and accurate updates.

[0057] This application further proposes a global metadata management service that sets a timer to periodically synchronize new semantic fragments and existence marker updates in the memory cache to the distributed storage system, including the following steps: The global metadata management service obtains the real-time write queue length and network bandwidth utilization of the distributed storage system. The global metadata management service dynamically adjusts the timer period based on the real-time write queue length and network bandwidth utilization of the distributed storage system. When the real-time write queue length or network bandwidth utilization of the distributed storage system exceeds the preset threshold, the timer period is extended; when both the real-time write queue length and network bandwidth utilization of the distributed storage system are lower than the preset threshold, the timer period is shortened. Before performing periodic synchronization, the global metadata management service verifies new semantic fragments and existence markers in the memory cache; When the verification fails, the global metadata management service triggers a retry mechanism to retry periodic synchronization within a preset number of retries and retry interval. When synchronizing new semantic fragments and existence markers from the memory cache to the distributed storage system, the global metadata management service employs a transactional write mechanism to ensure that all update operations of new semantic fragments and existence markers are completed as an atomic operation and to roll back in case of write failure.

[0058] Specifically, the global metadata management service is configured to continuously monitor the operational status of the distributed storage system. Here, "real-time write queue length" refers to the amount of data currently waiting to be written to the distributed storage system, reflecting the immediate write pressure on the storage system; "network bandwidth utilization" refers to the busy level of the data transmission channel between the distributed storage system and the global metadata management service, indicating the availability of network resources. By obtaining these key metrics, the global metadata management service can comprehensively assess the current load of the distributed storage system.

[0059] Furthermore, the global metadata management service intelligently adjusts the timer period based on the acquired real-time write queue length and network bandwidth utilization. Specifically, when either metric (real-time write queue length or network bandwidth utilization) exceeds a preset threshold, it indicates that the distributed storage system is under high load. In this case, the timer period will be extended to reduce the synchronization frequency and avoid placing additional burden on the already stressed storage system. Conversely, when both metrics are below the preset threshold, it indicates that the storage system resources are relatively idle. In this case, the timer period will be shortened to increase the synchronization frequency, ensuring that data in the memory cache can be persisted faster, thereby improving data consistency.

[0060] Furthermore, before each periodic synchronization operation is executed, the global metadata management service performs rigorous verification of new semantic fragments and existence tags in the memory cache. This verification aims to ensure the integrity and validity of the data to be synchronized, as well as potential conflicts with existing data in the distributed storage system. For example, verification may include checking whether the data format is correct, whether there are duplicate records, or logical errors.

[0061] When the verification process detects any anomalies or inconsistencies that cause verification failure, the global metadata management service will not immediately abandon synchronization. Instead, it will trigger a pre-defined retry mechanism. This mechanism allows the global metadata management service to retry periodic synchronization after a certain number of retries and retry intervals. This is designed to address transient network fluctuations or brief storage system failures, improving the success rate of synchronization operations and the robustness of the system.

[0062] Before performing periodic synchronization, the global metadata management service verifies new semantic fragments and existence markers in the memory cache, including the following steps: The global metadata management service obtains the latest version information of persisted semantic fragments and semantic fragment existence tags in the distributed storage system; The global metadata management service compares new semantic fragments and existence markers in the memory cache with the latest version information to identify conflict types; The global metadata management service executes conflict resolution strategies based on the conflict type; The global metadata management service synchronizes the new semantic fragments and existence markers after conflict resolution.

[0063] Specifically, before performing periodic synchronization operations, the global metadata management service first obtains the latest version information of the semantic fragments and their existence markers that have been persistently stored in the distributed storage system. This latest version information can be understood as the current actual data state stored in the distributed storage system, used as a benchmark for comparison. This information can be obtained by querying the distributed storage system's metadata service interface or by directly reading a specific metadata table.

[0064] Subsequently, the global metadata management service compares the new semantic fragments and existence markers to be synchronized in the memory cache with the latest version information obtained. The purpose of the comparison is to identify whether there are any data inconsistencies or conflicts. For example, if a semantic fragment in the memory cache has been deleted or modified in the distributed storage system, or its existence marker has changed, it will be identified as a conflict. Conflict types may include, but are not limited to: version conflicts (the same data has been modified by different sources), missing data (existing in memory but not in storage), and data redundancy (existing in storage but not in memory).

[0065] Once a conflict type is identified, the global metadata management service will handle these conflicts according to the preset conflict resolution strategy. The conflict resolution strategy can be configured according to actual business needs. For example, strategies such as "prioritize memory cache" (forcefully overwrite old data in the distributed storage system), "prioritize distributed storage system" (discard conflicting data in the memory cache), "merge resolution" (attempt to intelligently merge data in the memory cache and the distributed storage system), or "manual intervention" can be adopted.

[0066] Finally, after the conflict is resolved, the global metadata management service synchronizes the new semantic fragments and existence tags after the conflict resolution. This means that only data that has been verified and conflict-resolved will be written to the distributed storage system, thereby ensuring data consistency and accuracy.

[0067] When synchronizing new semantic fragments and existence marker updates from the memory cache to the distributed storage system, the global metadata management service employs a transactional write mechanism to ensure that all update operations on new semantic fragments and existence markers are completed as an atomic operation. The rollback steps in case of write failure include: The global metadata management service uses a distributed transaction coordinator; Before a transaction begins, the distributed transaction coordinator sends a pre-commit request to all participating nodes in the distributed storage system. Each participating node locks the resource locally and prepares to write, then returns a readiness message to the distributed transaction coordinator; After receiving the readiness information from all participating nodes, the distributed transaction coordinator sends a commit request to all participating nodes. Each participating node performs a write operation and releases resources; When the distributed transaction coordinator receives a response failure due to the failure of some participating nodes or network partition during the pre-commit or commit phase, the distributed transaction coordinator starts a compensation transaction. The distributed transaction coordinator sends rollback instructions to all participating nodes that have completed pre-commit or commit operations and records the rollback status. The distributed transaction coordinator periodically probes the recovery status of failed nodes or network partitions, and re-attempts to execute incomplete commits or rollbacks after recovery, ensuring that all participating nodes eventually reach a consistent state.

[0068] The distributed transaction coordinator can be understood as a component specifically responsible for coordinating the execution of distributed transactions. Its main responsibility is to ensure that operations on multiple participating nodes in a distributed storage system can be completed as a single, atomic transaction. This coordinator typically uses a two-phase commit (2PC) protocol to manage the transaction lifecycle. The pre-commit request is a request sent by the distributed transaction coordinator to all participating nodes in the first phase of the transaction, requesting them to be ready to execute the transaction operation and to lock the relevant resources, but not to actually commit yet. The readiness message is the confirmation message returned by the participating nodes to the distributed transaction coordinator after successfully locking the resources and being ready to write, indicating that they are ready to enter the commit phase. The commit request is the instruction sent by the distributed transaction coordinator to all participating nodes after receiving the readiness message, requiring them to formally execute the write operation and commit the transaction.

[0069] In practical applications, when the distributed transaction coordinator fails to receive the expected response from all participating nodes during the pre-commit or commit phase—for example, due to a failure of a participating node or communication interruption caused by a network partition—a compensation transaction is initiated. A compensation transaction is a mechanism for undoing or offsetting partially completed operations to ensure the atomicity of the entire distributed transaction. Rollback instructions are part of the compensation transaction, sent by the distributed transaction coordinator to participating nodes that have completed the pre-commit or commit operations, instructing them to undo their previous operations and restore the system to the state before the transaction began. Recording the rollback state is crucial so that after system recovery, it is possible to accurately determine which transactions need to be rolled back or undergo other compensation operations to ensure eventual consistency. Periodically probing the recovery status of failed nodes or network partitions and retrying incomplete commit or rollback operations is essential for handling transient failures or network fluctuations in the distributed system, ensuring that even in the event of a failure, the system can eventually reach a consistent state through retry mechanisms.

[0070] In some preferred embodiments, it is assumed that the global metadata management service needs to synchronize a batch of new semantic fragments and their presence markers in the data partitions to a distributed storage system consisting of three distributed storage nodes (node ​​A, node B, and node C).

[0071] First, the global metadata management service starts a distributed transaction coordinator. At the start of a transaction, the coordinator sends a pre-commit request to nodes A, B, and C, requesting them to be ready to receive and write the updated data.

[0072] After receiving the pre-commit request, nodes A, B, and C will each lock the relevant storage resources locally, verify the validity of the data, and then return "ready" information to the distributed transaction coordinator.

[0073] Once the distributed transaction coordinator has received the "ready" message from all three nodes, it will send a commit request to nodes A, B, and C, instructing them to perform the write operation and commit the transaction.

[0074] After receiving the submission request, nodes A, B, and C will each write the new semantic fragment and existence marker to their local storage and release the previously locked resources.

[0075] However, suppose that after the distributed transaction coordinator sends a commit request to nodes A, B, and C, node B suddenly experiences a network failure, causing the distributed transaction coordinator to fail to receive the commit confirmation from node B. In this case, the distributed transaction coordinator will recognize the failure of the commit phase response.

[0076] To ensure data consistency, the distributed transaction coordinator immediately initiates a compensation transaction. It sends rollback instructions to nodes A and C that have successfully committed their updates, instructing them to undo their previous updates and restore the system to its state before the transaction began. Simultaneously, the distributed transaction coordinator records the rollback status of node B, marking it as incomplete.

[0077] Subsequently, the distributed transaction coordinator periodically probes the network recovery status of node B. Once node B's network recovers, the distributed transaction coordinator will retry sending a rollback instruction to node B (if node B had entered the pre-commit phase before the failure), or retry executing the entire commit operation (if node B had not completed the pre-commit before the failure). Through this mechanism, even in the event of partial node failures or network partitions in the distributed storage system, the scheme in this application can ensure that all participating nodes eventually reach a consistent state, thereby guaranteeing the atomicity and reliability of global metadata directory updates.

[0078] When a write fails and a rollback is performed, the method also includes: The distributed transaction coordinator performs an initial health check on the recovery nodes to assess their resource availability and stability. Once the initial health check is passed, the distributed transaction coordinator adds the recovery node to the pending queue. The distributed transaction coordinator adjusts the retry interval for recovering nodes based on the historical failure frequency and current health status of nodes in the pending queue. The distributed transaction coordinator adjusts the maximum number of retries for the recovery node based on the historical failure frequency and current health status of the nodes in the pending queue. Before each retry operation, the distributed transaction coordinator performs a lightweight health check on the recovery node to confirm its status. When a retry operation fails, the distributed transaction coordinator increases the retry interval and records the number of failures. When the number of failures reaches the maximum number of retries, the distributed transaction coordinator will mark the recovery node as temporarily unavailable and trigger an alarm mechanism.

[0079] In distributed storage systems, when the global metadata management service synchronizes new semantic fragments and existence markers from the memory cache to the distributed storage system, it employs a transactional write mechanism to ensure that all update operations are completed as an atomic operation and to roll back in case of write failure. However, in real-world distributed environments, when a write operation fails and triggers a rollback, the system may face complex situations such as node failures and network partitions, leading to some participating nodes being in an uncertain state. While the aforementioned solutions propose periodically probing failed nodes to retry the operation, they do not elaborate on how to intelligently manage these recovering nodes. Especially for nodes that may experience intermittent failures or unstable resources, simple periodic probing may be inefficient and could even exacerbate the system burden or prolong recovery time due to repeated attempts to operate on unstable nodes. Therefore, this application further proposes a method for intelligently managing recovering nodes when a write operation fails and a rollback occurs, aiming to improve the system recovery efficiency and stability after a distributed transaction rollback.

[0080] Specifically, after detecting a write failure and initiating a rollback process, the distributed transaction coordinator identifies the nodes that need to be recovered—those participating nodes that failed to successfully complete the commit or rollback operation. For these recoverable nodes, the distributed transaction coordinator first performs an initial health check. This initial health check aims to comprehensively assess the current state of the recoverable nodes, including but not limited to CPU utilization, memory usage, disk I / O, network connectivity, and the running status of critical service processes. These metrics determine whether the node possesses basic resource availability and operational stability, thus avoiding ineffective retries on a completely failed or resource-exhausted node.

[0081] When the initial health check indicates that a recovery node meets the basic requirements for recovery operations, the distributed transaction coordinator adds the node to a pending queue. This queue is used to centrally manage all nodes that require subsequent recovery operations.

[0082] Furthermore, to improve recovery efficiency and avoid excessive attempts on unstable nodes, the distributed transaction coordinator dynamically adjusts the retry interval and maximum number of retries for each node in the pending queue based on its historical failure frequency and current health status. For example, for nodes with a high historical failure frequency or poor current health status, the retry interval can be appropriately extended and the maximum number of retries reduced to avoid resource waste or further deterioration of the node's state due to frequent attempts. Conversely, for nodes with good health and a low historical failure frequency, a shorter retry interval and more retries can be used to accelerate their recovery process.

[0083] Before each retry operation on a recoverable node, the distributed transaction coordinator performs a lightweight health check. Compared to the initial health check, the lightweight health check has less overhead and typically only checks the node's core service status and network connectivity to quickly confirm whether the node is still operational, thus avoiding wasting resources on nodes that have failed again.

[0084] If a retry operation fails, the distributed transaction coordinator increases the retry interval for that node and records the number of failures. This exponential backoff strategy helps reduce the retry frequency when a node remains unstable, giving it more time to recover. When the number of failures for a node reaches the preset maximum number of retries, the distributed transaction coordinator marks it as temporarily unavailable and triggers an alarm mechanism. This is intended to notify system administrators or automated operation and maintenance systems that the node may have a serious problem requiring manual intervention or deeper diagnostics, thus preventing the system from indefinitely attempting to recover an unrecoverable node.

[0085] In some preferred embodiments, suppose that in a cloud database, a global metadata management service is attempting to synchronize updates of a batch of semantic fragments to a distributed storage system, but due to a momentary network failure of a data partition node (e.g., node A), the transactional write fails and triggers a rollback.

[0086] At this point, the distributed transaction coordinator identifies node A as the node that needs to be recovered. First, the distributed transaction coordinator performs an initial health check on node A. This check may include sending a heartbeat request to node A, querying its resource usage (such as CPU and memory), and checking whether its storage service processes are running normally. If node A passes the initial health check, indicating that it has basic recovery capabilities, it is added to the processing queue.

[0087] Subsequently, the distributed transaction coordinator dynamically adjusts the retry interval and maximum number of retries for node A based on node A's historical failure record (e.g., node A experienced two transient network failures within the past week) and its current health status (e.g., the network has recovered, but CPU utilization is slightly high). For example, because node A has a history of failures, the coordinator may set its initial retry interval to 5 seconds and the maximum number of retries to 5.

[0088] Before the first retry, the distributed transaction coordinator performs a lightweight health check on node A to confirm its network connectivity. Then, the coordinator attempts to re-execute the commit or rollback operation on node A. If the retry is successful, node A's state is updated to be consistent, and the recovery process ends.

[0089] However, if the first retry fails (for example, node A's storage service briefly restarts), the distributed transaction coordinator increases the retry interval to 10 seconds and records the failure count as 1. A lightweight health check is performed again before the second retry. If the second retry also fails, the retry interval may increase to 20 seconds, and the failure count will be recorded as 2.

[0090] When the maximum number of retries (e.g., 5) is reached, if node A still fails to recover successfully, the distributed transaction coordinator will mark it as temporarily unavailable and trigger an alert to the operations team. Upon receiving the alert, the operations team can intervene to perform more in-depth diagnosis and repair of node A, while the system will not continue to perform unnecessary retries on that node, thus avoiding resource waste and ensuring the normal operation of other healthy nodes. Through this intelligent recovery management, the system can handle node failures in distributed transactions more efficiently and stably.

[0091] refer to Figure 2 This application proposes a cloud database-based automotive after-sales service information retrieval system, which is applied to a cloud database-based automotive after-sales service information retrieval method. The system includes: The processing module is used to obtain the vehicle part number and perform semantic processing on it, decomposing the part number into multiple semantic fragments. Specifically, the processing module is responsible for receiving the raw vehicle part number data and analyzing it using natural language processing technology or a predefined rule set, thereby breaking down a complete part number into fragments with independent semantics, such as brand, model, year, and part type, to facilitate subsequent storage and retrieval.

[0092] The storage module stores semantic fragments along with unique identifiers for automotive parts in a parts information table within the cloud database. Specifically, the storage module associates the semantic fragments generated by the processing module with the unique identifier of each automotive part and persistently stores this association in a specific data table within the cloud database (i.e., the parts information table). This parts information table is designed to support efficient semantic fragment indexing, providing a data foundation for subsequent retrieval operations.

[0093] The build module is used to construct a global metadata directory, which records the distribution information of semantic fragments in each data partition. Specifically, the build module is responsible for initializing and maintaining a global metadata directory. The core function of this directory is to map the relationship between semantic fragments and the data partitions in which they are actually stored in the cloud database. Through this directory, the system can quickly locate the data partition containing a specific semantic fragment, avoiding a full database scan.

[0094] The update module asynchronously updates the global metadata directory based on the semantic fragments of newly entered automotive parts and the partition information where these parts are located. Specifically, the update module incrementally updates the global metadata directory in a non-blocking manner, based on the semantic fragments contained in the newly entered automotive parts and the data partition information where they are stored. This asynchronous update mechanism ensures the real-time performance and data consistency of the metadata directory without impacting the performance of the main business processes.

[0095] The parsing module receives user query requests and performs semantic parsing to extract semantic tags. In practical applications, the parsing module receives query input from users and uses semantic analysis technology to identify and extract key semantic tags from the user's natural language query. These tags represent the accessory features or attributes that the user wishes to retrieve.

[0096] The sending module is used to direct query requests to the relevant data partitions containing the target data based on the query semantic tags and the asynchronously updated global metadata directory. Specifically, the sending module uses the query semantic tags extracted by the parsing module and the global metadata directory maintained by the update module to intelligently determine which data partitions may contain the target data required by the user, and accurately routes the query request to these relevant data partitions, thereby achieving distributed querying.

[0097] The retrieval module is used to perform local retrieval of query requests within relevant data partitions, based on the indexes built for semantic fragments in the parts information table, and obtain local retrieval results. Specifically, after receiving a query request sent by the sending module, the retrieval module efficiently performs local retrieval operations within its own data partition using the pre-built index structure for semantic fragments, quickly filters out parts information that meets the query conditions, and generates local retrieval results.

[0098] The backhaul module is used to send local search results back to the distributed semantic routing layer. Specifically, the backhaul module is responsible for sending the local search results obtained by the search module in each data partition back to the system's distributed semantic routing layer for subsequent aggregation processing.

[0099] The aggregation module is used to aggregate the search results received from the distributed semantic routing layer and returned from various data partitions to obtain the final search results. Specifically, the aggregation module receives local search results from different data partitions from the return module, performs operations such as merging, deduplication, and sorting on them, and finally generates a complete and consistent search result set, which is then presented to the user.

[0100] The content disclosed above is only a preferred and feasible embodiment of the present invention, and is not intended to limit the scope of protection of the present invention. Therefore, all equivalent technical changes made based on the content of the present invention specification and drawings are included within the scope of protection of the present invention. Furthermore, the elements therein can be updated as technology develops.

Claims

1. A method for retrieving automotive after-sales service information based on a cloud database, characterized in that, The method includes the following steps: Obtain the vehicle part number and perform semantic processing on the vehicle part number, decomposing the vehicle part number into multiple semantic fragments; Semantic fragments, along with unique identifiers for automotive parts, are stored in a parts information table in a cloud database. Construct a global metadata directory, which records the distribution information of semantic fragments in each data partition; Asynchronously update the global metadata directory, and asynchronously update the semantic fragments of newly entered auto parts and the partition information where the newly entered auto parts are located; Receive user query requests, perform semantic parsing on the user query requests, and extract query semantic tags; Based on the query semantic tags and the asynchronously updated global metadata directory, the query request is directed to the relevant data partition containing the target data; Within the relevant data partitions, based on the indexes created for semantic fragments in the parts information table, local retrieval is performed on the query requests to obtain local retrieval results; The local search results are sent back to the distributed semantic routing layer. The search results received by the distributed semantic routing layer from the data partitions are aggregated to obtain the final search results.

2. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 1, characterized in that, The steps for asynchronously updating the global metadata directory include: In the local maintenance semantic fragment change event stream of each data partition, whenever new part information is written to the corresponding data partition, after the semantic fragment of the new part information is parsed, the corresponding change is appended as an event to the local maintenance semantic fragment change event stream. The global metadata management service periodically pulls change events from the locally maintained semantic fragment change event stream of each data partition, and returns all new events since the last successful pull based on the pull progress indicator, which helps to improve the continuity of asynchronous updates. When the global metadata management service encounters network problems while pulling change events, it will retry pulling under the preset retry policy; After successfully retrieving the change events for each data partition, the global metadata management service iterates through all semantic fragments contained in the change events, identifies new semantic fragments and adds them to the semantic fragment list in the global metadata directory, and then updates the presence marker of the semantic fragments in the corresponding data partitions.

3. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 2, characterized in that, When data partitions use a high-availability replication architecture, the steps for asynchronously updating the global metadata directory include: When new auto parts information is written to a data partition of the cloud database, the system performs semantic parsing on the auto parts number, decomposing the auto parts number into multiple semantic fragments. In the local maintenance semantic fragment change event stream of the data partition, the change of the semantic fragment is appended as an event to the local maintenance semantic fragment change event stream; When a data partition adopts a high-availability replication architecture, after the primary replica of the data partition receives a request to write automotive parts information and parses out the semantic fragment, it appends the change event of the semantic fragment to the local maintenance semantic fragment change event stream of the primary replica. The primary replica synchronously replicates the semantic fragment change events to the local maintenance semantic fragment change event stream of all secondary replicas; When a master-slave switch occurs in a data partition, the new master replica takes over the write operations and continues to append the semantic fragment change events to the local maintenance semantic fragment change event stream of the new master replica, and synchronously replicates them to other replicas; The global metadata management service pulls semantic fragment change events from the local maintenance semantic fragment change event stream of the current primary replica of the data partition.

4. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 2, characterized in that, The global metadata management service periodically pulls change events from the locally maintained semantic fragment change event stream of each data partition, and returns all newly added events since the last successful pull based on the pull progress indicator. The steps include: The global metadata management service obtains the current cumulative amount of events in the local maintenance semantic fragment change event stream of each data partition; The global metadata management service adjusts the fetch interval for each data partition based on the cumulative amount of events. The global metadata management service maintains independent fetch tasks for each data partition; The global metadata management service adjusts the concurrency of each fetch task based on the load of each data partition; The global metadata management service uses independent pull tasks to pull change events from the locally maintained semantic fragment change event stream of each data partition with adjusted pull intervals and concurrency. Based on the pull progress indicator, it returns all new events since the last successful pull.

5. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 2, characterized in that, After successfully retrieving change events from each data partition, the global metadata management service iterates through all semantic fragments contained in the change events, identifies new semantic fragments and adds them to the semantic fragment list in the global metadata directory, and then updates the presence markers of the semantic fragments in the corresponding data partitions. The steps include: After receiving change events from each data partition, the global metadata management service aggregates all semantic fragments contained in the change events to form batch processing units. The global metadata management service maintains a cache of the global semantic fragment set in memory, and for each semantic fragment in the batch processing unit, it queries the memory cache to determine whether each semantic fragment is a new semantic fragment. The global metadata management service adds the newly identified semantic fragments to the memory cache; The global metadata management service packages all semantic fragments and the update operations of the corresponding data partitions in the batch processing unit into a batch processing request. The global metadata management service sends batch requests to the distributed storage system for asynchronous persistent updates, and sets a timer to periodically synchronize new semantic fragments and existence markers in the memory cache to the distributed storage system.

6. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 5, characterized in that, The steps of the global metadata management service to set a timer to periodically synchronize new semantic fragments and existence tags in the memory cache to the distributed storage system include: The global metadata management service obtains the real-time write queue length and network bandwidth utilization of the distributed storage system. The global metadata management service dynamically adjusts the timer period based on the real-time write queue length and network bandwidth utilization of the distributed storage system. When the real-time write queue length or network bandwidth utilization of the distributed storage system exceeds the preset threshold, the timer period is extended; when both the real-time write queue length and network bandwidth utilization of the distributed storage system are lower than the preset threshold, the timer period is shortened. Before performing periodic synchronization, the global metadata management service verifies new semantic fragments and existence markers in the memory cache; When the verification fails, the global metadata management service triggers a retry mechanism to retry periodic synchronization within a preset number of retries and retry interval. When synchronizing new semantic fragments and existence markers from the memory cache to the distributed storage system, the global metadata management service employs a transactional write mechanism to ensure that all update operations of new semantic fragments and existence markers are completed as an atomic operation, and to roll back in case of write failure.

7. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 6, characterized in that, Before performing periodic synchronization, the global metadata management service verifies new semantic fragments and existence markers in the memory cache, including the following steps: The global metadata management service obtains the latest version information of persisted semantic fragments and semantic fragment existence tags in the distributed storage system; The global metadata management service compares new semantic fragments and existence markers in the memory cache with the latest version information to identify conflict types; The global metadata management service executes conflict resolution strategies based on the conflict type; The global metadata management service synchronizes the new semantic fragments and existence markers after conflict resolution.

8. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 6, characterized in that, When synchronizing new semantic fragments and existence marker updates from the memory cache to the distributed storage system, the global metadata management service employs a transactional write mechanism to ensure that all update operations on new semantic fragments and existence markers are completed as an atomic operation. The rollback steps in case of write failure include: The global metadata management service uses a distributed transaction coordinator; Before a transaction begins, the distributed transaction coordinator sends a pre-commit request to all participating nodes in the distributed storage system. Each participating node locks the resource locally and prepares to write, then returns a readiness message to the distributed transaction coordinator; After receiving the readiness information from all participating nodes, the distributed transaction coordinator sends a commit request to all participating nodes. Each participating node performs a write operation and releases resources; When the distributed transaction coordinator receives a response failure due to the failure of some participating nodes or network partition during the pre-commit or commit phase, the distributed transaction coordinator starts a compensation transaction. The distributed transaction coordinator sends rollback instructions to all participating nodes that have completed pre-commit or commit operations and records the rollback status. The distributed transaction coordinator periodically probes the recovery status of failed nodes or network partitions, and re-attempts to execute incomplete commits or rollbacks after recovery, ensuring that all participating nodes eventually reach a consistent state.

9. The method for retrieving automotive after-sales service information based on a cloud database as described in claim 8, characterized in that, When a write fails and a rollback is performed, the method also includes: The distributed transaction coordinator performs an initial health check on the recovery nodes to assess their resource availability and stability. Once the initial health check is passed, the distributed transaction coordinator adds the recovery node to the pending queue. The distributed transaction coordinator adjusts the retry interval for recovering nodes based on the historical failure frequency and current health status of nodes in the pending queue. The distributed transaction coordinator adjusts the maximum number of retries for the recovery node based on the historical failure frequency and current health status of the nodes in the pending queue. Before each retry operation, the distributed transaction coordinator performs a lightweight health check on the recovery node to confirm its status. When a retry operation fails, the distributed transaction coordinator increases the retry interval and records the number of failures. When the number of failures reaches the maximum number of retries, the distributed transaction coordinator will mark the recovery node as temporarily unavailable and trigger an alarm mechanism.

10. A cloud database-based automotive after-sales service information retrieval system, applied to the cloud database-based automotive after-sales service information retrieval method as described in claim 1, characterized in that, The system includes: The processing module obtains the vehicle part number and performs semantic processing on the vehicle part number, decomposing the vehicle part number into multiple semantic fragments; The storage module stores semantic fragments along with the unique identifiers of automotive parts in the parts information table of the cloud database; The module builds a global metadata directory, which records the distribution information of semantic fragments in each data partition. The update module asynchronously updates the global metadata directory and asynchronously updates semantic fragments based on newly entered auto parts and the partition information where the newly entered auto parts are located. The parsing module receives user query requests, performs semantic parsing on the user query requests, and extracts query semantic tags; The sending module, based on the query semantic tags and the asynchronously updated global metadata directory, directs the query request to the relevant data partition containing the target data; The retrieval module performs local retrieval of query requests based on the index built for semantic fragments in the parts information table within the relevant data partitions, and obtains local retrieval results. The return module sends the local search results back to the distributed semantic routing layer; The aggregation module aggregates the search results received by the distributed semantic routing layer from each data partition to obtain the final search results.

Images