Fault-tolerant processing method for synchronizing upstream nonstandard data

Abstract

The invention relates to the field of data processing, discloses a fault-tolerant processing method for synchronizing upstream nonstandard data, and solves the problem that downstream business processing is abnormal due to nonstandard upstream data. The scheme of the invention comprises the following steps: an upstream service manages model data of the television terminal; the downstream service pulls full-amount model data of the upstream service at regular time, detects data normalization, and if the data normalization is detected, stores the corresponding relation between the movement and the platform into a historical mapping table, clears a data synchronization table of the downstream service, and stores the pulled data; an operator configures system information for the matched television terminal, and binds and archives the system information with the corresponding machine type and the platform after the verification is passed; when a television terminal triggers a system information acquisition request, the television terminal carries own movement and type parameters and sends the request to a downstream service; the downstream service matches the platforms from the data synchronization table according to the machine core parameters; if a unique platform is matched, the corresponding system information is obtained by combining the machine core parameters; and if a plurality of platforms are matched, matching historical platforms from the historical mapping table according to the machine core parameters, and obtaining corresponding system information in combination with the machine type parameters.

Description

Technical Field

[0001] This invention relates to the field of data processing, and specifically to a fault-tolerant processing method for synchronizing non-standard upstream data. Background Technology

[0002] In the R&D and production system of smart TVs, the TV model serves as a core identifier, encompassing key dimensions such as platform, chassis, and form factor, and is the foundation for achieving full lifecycle management and system configuration control of the device. According to industry default standards, model data must follow specific association rules: a one-to-one correspondence must be maintained between the platform and the chassis of the same series (the criterion is that the first set of numbers in the chassis identifier is the same; for example, XCM105B1 and XCM105B7 belong to the same chassis series and must correspond to the same platform because their first set of numbers is 105); while the relationship between chassis and form factor is many-to-many. This model data is uniformly entered into a cloud management system, which serves as the source control carrier for model data and is defined as an upstream service.

[0003] To achieve systematic configuration management of television terminals, another cloud system (i.e., downstream service) is deployed. Its core function is to retrieve full data on platforms, chassis, and models from upstream services and provide a visual configuration platform. Operators can select the target model and corresponding platform through the downstream service configuration platform to preset exclusive system information for that batch of television terminals. When a television terminal needs to obtain configuration data, it sends a system information request to the downstream service, carrying its own chassis and model parameters, thereby completing the acquisition and loading of configuration data.

[0004] However, the current data synchronization and processing flow has certain shortcomings, specifically: The lack of a primary key identifier in the synchronized data between upstream and downstream services leads to a full-scale update process for each synchronization, making it impossible to accurately trace data changes. More critically, the model data in the upstream service is manually entered, lacking a pre-emptive standardization check mechanism. Furthermore, the massive amount of data makes it highly susceptible to non-standard data that violates association rules. A typical problem is that the same series of turntables corresponds to multiple platforms. When such non-standard data is synchronized to downstream services, it causes multiple conflicting results when matching platforms based on turntable parameters during terminal requests, directly violating the configuration rule of one turntable corresponding to one platform. Ultimately, this results in the TV terminal being unable to obtain the correct system information.

[0005] To address the aforementioned issues, the current approach involves the downstream service retrieving data from the upstream and checking its compliance. If non-compliant data is found, a warning email is sent to the upstream service manager to request correction. However, this approach suffers from significant latency. From detecting non-compliant data and sending the warning email to the upstream service completing data correction and resynchronization, the entire process is time-consuming. This makes it difficult to promptly resolve abnormal configuration requests from TV terminals, resulting in a poor user experience and additional costs for operation and maintenance. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide a fault-tolerant processing method for synchronizing non-standard upstream data, thereby solving the problem that non-standard upstream data leads to abnormal processing in downstream business processes.

[0007] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows: A fault-tolerant handling method for synchronizing non-standard upstream data includes the following steps: S1. The upstream service uniformly inputs and manages the model data of TV terminals, and follows the preset specifications: the platform and the same series of chassis have a one-to-one correspondence, and the chassis and the model have a many-to-many correspondence; S2. The downstream service periodically pulls the full model data of the upstream service and checks the standardization of the pulled model data. If there is non-standard data, an alert email is sent to the upstream. If the data is completely standard, the correspondence between the movement and the platform is stored in the historical mapping table. S3. The downstream service clears its own data synchronization table and stores the retrieved full model data into the table; S4. The operator logs into the downstream service configuration platform, selects the target model and the corresponding upstream platform, configures the system information for the matched TV terminal, and after the review is approved, binds and archives the system information with the corresponding model and platform. S5. When a TV terminal triggers a system information acquisition request, it sends the request to downstream services via HTTPS protocol, carrying its own core and model parameters. S6. After receiving the request, the downstream service matches the platform from the data synchronization table based on the core parameters: if a unique platform is matched, the corresponding system information is obtained by combining the model parameters; if multiple platforms are matched, the historical platform is matched from the historical mapping table based on the core parameters, and then the corresponding system information is obtained by combining the model parameters. S7. The downstream service returns the system information to the television terminal through the interface.

[0008] Furthermore, in step S1, the criterion for determining the same series of movements is: the first group of numbers in the movement identification is the same.

[0009] Furthermore, in step S1, the model data includes platform, movement, and model information.

[0010] Furthermore, in step S2, the non-standard data refers to data that violates the one-to-one rule between the platform and the same series of movements, that is, the same series of movements corresponds to multiple platforms.

[0011] Furthermore, in step S4, after the system information is bound and archived with the device model and platform, only query operations are supported, and modification and deletion operations are prohibited.

[0012] Furthermore, in step S2, the period for the downstream service to periodically pull full model data from the upstream service is configured according to business needs; and the pulling operation is executed asynchronously in the background, so it does not interfere with the downstream service's processing of TV terminal requests.

[0013] The beneficial effects of this invention are: (1) Resolve core business anomalies and ensure terminal configuration stability: By employing a dual storage architecture of a data synchronization table (real-time data) and a historical mapping table (standardized historical data), when upstream data exhibits non-standardization issues with multiple platforms corresponding to the same series of chassis, downstream services can automatically switch to the historical mapping table to match a unique platform. This avoids the core problem in traditional solutions where terminals cannot obtain system information due to matching conflicts, ensuring that TV terminal configuration requests are always effectively responded to.

[0014] Once the system information configured by the operators is bound to the model and platform and archived, it cannot be modified, completely eliminating terminal request anomalies caused by configuration changes, and further ensuring the stability of TV terminals in obtaining system information. This is especially suitable for smart TV mass production and after-sales maintenance scenarios.

[0015] (2) Optimize the data synchronization mechanism to reduce operation and maintenance costs: While retaining the warning emails for non-standard data, a new historical mapping table fault tolerance capability has been added. Downstream services can process terminal requests in real time through historical data without waiting for upstream services to correct the data. This solves the drawback of delayed waiting after warnings in traditional solutions and reduces the emergency handling pressure on operation and maintenance personnel.

[0016] (3) Improve user experience and adapt to business flexibility: When a TV terminal user triggers a system information retrieval operation, there is no need to wait for configuration loading due to non-standard data. The system information can be quickly obtained through fault-tolerant matching of downstream services, avoiding negative user experiences caused by function lag or loading failure, and improving user satisfaction with smart TVs.

[0017] The downstream service can flexibly configure the period for periodically pulling data, which can meet the needs of upstream services to update model data in batches, and also ensure that the pulling operation does not interfere with the terminal request processing through the background asynchronous pulling design. It balances the timeliness of data synchronization and the continuity of business processing, and adapts to the R&D and production rhythm of TV manufacturers of different sizes. Attached Figure Description

[0018] Figure 1 This is a flowchart of the fault-tolerant processing method for synchronizing non-standard upstream data in an embodiment of the present invention. Detailed Implementation

[0019] This invention aims to provide a fault-tolerant handling method for synchronizing non-standard upstream data, solving the problem of downstream business processing anomalies caused by non-standard upstream data. Its core idea is to address the core pain point of downstream business anomalies caused by non-standard upstream model data by constructing a dual fault-tolerant mechanism of real-time detection and early warning plus historical standard data as a backup. Without disrupting the existing upstream and downstream service architecture, it achieves the goal of both timely reminding upstream data correction and ensuring immediate response to downstream terminal requests. Essentially, it balances data standardization requirements and business continuity needs through layered data storage and intelligent switching matching.

[0020] Specifically, the present invention achieves the above core idea through the following means: (1) It is clear that the upstream model data must follow the preset standard of "one-to-one between platform and same series of movement, and many-to-many between movement and model", and the complete compliance of the downstream first data pull is taken as a key premise. The "historical mapping table" is constructed through the initial compliant data to provide a unique and reliable standard data benchmark for subsequent fault-tolerant matching, and to avoid the failure of the fallback mechanism due to the non-standard nature of the historical data itself.

[0021] (2) When downstream services synchronize upstream data, a layered storage design of "data synchronization table + historical mapping table" is adopted: the former stores the full data pulled in real time (which may include non-standard data) for routine business matching; the latter only stores the compliant machine-platform correspondence (i.e., historical standard data) as a fault-tolerant backup. This design not only preserves the real-time nature of data synchronization, but also builds security redundancy through historical standard data, avoiding the dilemma of business interruption caused by non-standard data once full-coverage synchronization has no primary key.

[0022] (3) When downstream services process information requests from TV terminal systems, they prioritize matching the platform based on the real-time data synchronization table according to the TV chassis. If a unique match is found, a normal response is given. If multiple platform conflicts occur due to non-standard data, the system automatically switches to the historical mapping table. The unique platform is then locked through the historically standardized chassis-platform correspondence, thereby obtaining the correct system information. The entire switching process requires no manual intervention, achieving seamless fault tolerance for terminal requests and completely solving the core problem that traditional early warning email delay correction cannot respond to terminal needs in a timely manner.

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0024] This embodiment provides a fault-tolerant handling method for synchronizing non-standard upstream data. Before implementation, it is necessary to clarify the data association specifications and system storage architecture to lay the foundation for subsequent data synchronization, configuration, and request processing. Data specification definition: Clearly define the core association rules for TV model data. Platforms and chassis of the same series have a one-to-one correspondence, while chassis and models have a many-to-many correspondence. The criterion for determining "chassis of the same series" is that the first set of numbers in the chassis identifier is the same. For example, chassis "XCM105B1" and "XCM105B7" are considered to be chassis of the same series because their first set of numbers is "105," and they must be bound to the same platform. The same chassis can be associated with multiple models.

[0025] System storage architecture setup: Downstream services need to deploy two core data tables: Data synchronization table: Used to store full model data (including platform, mechanism, and model association information) pulled from upstream services, supporting full coverage updates, and serving as the main source for real-time data queries.

[0026] Historical mapping table: It only stores the "machine core-platform" correspondence that has been tested and confirmed to be compliant, and does not store machine model information. It serves as a fault-tolerant backup when the data is not standardized and is only called when real-time matching fails.

[0027] System Information Table: Used to store the associated data of machine type, platform and system information configured by the operators. Once the data is archived, it can only be queried and cannot be modified or deleted.

[0028] Based on the aforementioned preparatory work, for specific implementation, please refer to... Figure 1 The implementation process of this embodiment is as follows: 1. Upstream data entry and downstream synchronization process: Upstream data entry: The upstream service manager manually enters the TV terminal model data (including platform, chassis, and model information) through a dedicated management interface. During the entry process, the upstream service does not perform real-time standardization testing, but only serves as a data storage carrier.

[0029] Downstream timed data retrieval and detection: Downstream services retrieve full model data from upstream services via an interface according to a preset period (e.g., every 2 hours). The first time the data is retrieved, it must be manually confirmed that the data is fully compliant to ensure the validity of the initial data in the historical mapping table.

[0030] After the data is retrieved, the downstream service automatically performs compliance checks: it iterates through the movement information in the data synchronization table to determine if there are any movements from the same series corresponding to multiple platforms. If non-compliant data is detected (e.g., movement XCM105B1 is associated with both platform A and platform B), an alert email is automatically generated and sent to the upstream service manager's email address, indicating that "movement XCM105B1 has multiple platform associations and needs to be corrected to a single platform"; if all data is found to be compliant, the current movement-platform correspondence is written to the historical mapping table, overwriting the original historical data.

[0031] Data synchronization table update: Regardless of whether the data pulled is standardized, the downstream service will first clear the original data in the data synchronization table, and then write the full model data pulled this time into the table to complete the real-time data update.

[0032] 2. System Information Configuration Process: Operators configure and archive TV terminal system information through the downstream service's configuration platform (which requires account and password login). The specific steps are as follows: Scope Delineation: On the configuration platform interface, operators can select the target TV model and its corresponding parent platform through drop-down menus or search functions. The system will automatically display the number of TV terminals corresponding to the "model-platform" combination, thereby ensuring accurate configuration scope.

[0033] System Information Configuration: For the selected "device model-platform" combination, the operations personnel configure the corresponding system information, such as system version, pre-installed application list, resolution parameters, etc.

[0034] Review and Archiving: After configuration, operations personnel submit the configuration for review, which is then conducted by the operations and maintenance administrators of downstream services. Once approved, the system automatically writes system information and other data into the system information table and locks the data. Subsequent queries are permitted, but modification or deletion is not allowed, ensuring the stability of configuration information when requested by the terminal.

[0035] 3. TV terminal request and downstream response process: When a TV user triggers the system information viewing function, the terminal and downstream services complete data interaction through the following process: Terminal initiates request: The user clicks "Refresh System Information" on the TV terminal, and the TV terminal automatically obtains its own core and model parameters, and sends a request to the downstream service via the HTTPS protocol.

[0036] Downstream service matching and fault tolerance: After receiving the request, the downstream service first parses out the movement parameters and then queries the data synchronization table to find the platform corresponding to that movement. If the query result is a unique platform, the downstream service will continue to query the system information table for the system information corresponding to "model + platform" to complete the normal matching.

[0037] If the query results are for multiple platforms, a fault tolerance mechanism is triggered: the downstream service automatically switches to the historical mapping table, queries the historical platform corresponding to the mechanism, and then obtains the corresponding system information from the system information table based on "model + historical platform" to avoid matching failure due to non-standard data.

[0038] Results returned and displayed on the terminal: The downstream service encapsulates the obtained system information (including system version, resolution, etc.) into JSON format and returns it to the TV terminal through the interface. After parsing the data, the terminal displays the latest system information on the interface.

[0039] Although embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the present invention, and all such changes and alterations shall not depart from the protection scope of the present invention.

Claims

1. A fault-tolerant processing method for synchronizing non-standard upstream data, characterized in that, Includes the following steps: S1. The upstream service uniformly inputs and manages the model data of TV terminals, and follows the preset specifications: the platform and the same series of chassis have a one-to-one correspondence, and the chassis and the model have a many-to-many correspondence; S2. The downstream service periodically pulls the full model data of the upstream service and checks the standardization of the pulled model data. If there is non-standard data, an alert email is sent to the upstream. If the data is completely standard, the correspondence between the movement and the platform is stored in the historical mapping table. S3. The downstream service clears its own data synchronization table and stores the retrieved full model data into the table; S4. The operator logs into the downstream service configuration platform, selects the target model and the corresponding upstream platform, configures the system information for the matched TV terminal, and after the review is approved, binds and archives the system information with the corresponding model and platform. S5. When a TV terminal triggers a system information acquisition request, it sends the request to downstream services via HTTPS protocol, carrying its own core and model parameters. S6. After receiving the request, the downstream service matches the platform from the data synchronization table based on the core parameters: if a unique platform is matched, the corresponding system information is obtained by combining the model parameters; if multiple platforms are matched, the historical platform is matched from the historical mapping table based on the core parameters, and then the corresponding system information is obtained by combining the model parameters. S7. The downstream service returns the system information to the television terminal through the interface.

2. The fault-tolerant processing method for synchronizing non-standard upstream data as described in claim 1, characterized in that, In step S1, the criterion for determining the same series of movements is: the first group of numbers in the movement identification is the same.

3. The fault-tolerant processing method for synchronizing non-standard upstream data as described in claim 1, characterized in that, In step S1, the model data includes platform, mechanism, and model information.

4. The fault-tolerant processing method for synchronizing non-standard upstream data as described in claim 1, characterized in that, In step S2, the non-standard data refers to data that violates the one-to-one rule between the platform and the same series of movements, that is, the same series of movements corresponds to multiple platforms.

5. The fault-tolerant processing method for synchronizing non-standard upstream data as described in claim 1, characterized in that, In step S4, after the system information is bound and archived with the device model and platform, only query operations are supported, and modification and deletion operations are prohibited.

6. A fault-tolerant processing method for synchronizing non-standard upstream data as described in any one of claims 1-5, characterized in that, In step S2, the period for downstream services to periodically pull full model data from upstream services is configured according to business needs; and the pulling operation is executed asynchronously in the background, so it does not interfere with the downstream service's processing of TV terminal requests.

Images