Method and system for repairing abnormal service data based on SDK (Software Development Kit)

Abstract

The invention discloses an abnormal business data restoration method and system based on an SDK (Software Development Kit), and relates to the technical field of abnormal business data restoration, and the method comprises the steps that the SDK is designed by packaging a retry logic into an independent service, and the retry logic comprises idempotent verification, current-limiting degradation and failure record storage; and calling an SDK interface, obtaining an abnormal data recovery request, triggering an automatic recovery task by utilizing the SDK according to the configuration rule, and executing a callback notification. The problems of high repeated development cost, low repair efficiency, poor system stability and the like in an existing abnormal service data repair system are solved, and a standardized and sustainable technical scheme is provided for abnormal data repair in a multi-service scene.

Description

Technical Field

[0001] The present invention relates to the technical field of abnormal business data repair, and in particular to an SDK-based abnormal business data repair method and system. Background Art

[0002] With the increasing complexity of internet platform services, repairing abnormal business data has become a critical component in ensuring system stability. Existing technologies typically employ two approaches to repair abnormal data: 1. In-house retry logic: Each business line (such as order fulfillment, equity issuance, and level changes) independently develops retry jobs and maintains retry tables, repairing failed business data through scheduled tasks or manual triggering. 2. Universal platform-based solutions: Some companies attempt to build centralized anomaly repair systems, but these typically hard-code repair rules, lacking flexible configuration capabilities and low-intrusive access mechanisms.

[0003] While the above solution addresses the need for abnormal data repair to a certain extent, it still suffers from significant technical shortcomings, including the following: 1. System fragmentation and significant code redundancy: Each business line must independently implement retry logic (such as interface request retry, deduction failure retry, and level change failure retry), resulting in duplicate retry job development and retry table maintenance. For example, the order system and driver development system may each develop independent retry logic, resulting in code duplication exceeding 60%. Repair rules (such as retry counts, intervals, and failure thresholds) are often hard-coded in the business code and cannot be dynamically adjusted. 2. Lack of unified abnormal data governance capabilities: Abnormal data records are scattered across local tables in various business systems, lacking a unified abnormal data pool. For example, abnormal data for the order system is stored in the order_retry_record table, while abnormal data for the driver development system is stored in the driver_growth_retry table. The repair process relies on manual intervention (such as manual repair via SQL or scheduled jobs), lacking automated repair channels and real-time monitoring capabilities. 3. High integration cost and poor scalability: When integrating into the exception recovery system, businesses must develop their own adaptation interfaces (such as callback notifications and parameter parsing) and maintain independent configuration tables. For example, integrating the order retry feature requires defining the order_retry_config table, while integrating into the driver growth system requires defining the driver_growth_retry_config table. Adjustments to the recovery rules (such as adding new scenarios or modifying retry strategies) require code modifications and service redeployment, resulting in limited flexibility.

[0004] This demonstrates that existing exception repair systems lack a unified SDK toolchain, configurable governance capabilities, and automated repair mechanisms. Businesses must repeatedly develop retry logic, and repair rules are highly coupled with business code, making the system difficult to scale. Summary of the Invention

[0005] In order to solve the above problems, the purpose of the present invention is to provide a technical solution that can achieve unified management of abnormal data, configurable repair rules, and minimize access costs, so as to solve the current problems of system decentralization, high maintenance costs, and low repair efficiency.

[0006] To achieve the above technical objectives, this application provides an SDK-based abnormal business data repair method, including the following steps: The SDK was designed by encapsulating the retry logic as an independent service. The retry logic includes idempotency verification, rate limiting and degradation, and failure record storage. Call the SDK interface to obtain abnormal data repair requests, use the SDK to trigger automatic repair tasks according to configuration rules, and execute callback notifications.

[0007] Preferably, when designing the SDK, the abnormal data of each business system is uniformly written into the biz_retry_record table through the applyDataRetryAgain interface of the SDK.

[0008] Preferably, when designing the SDK, the retry frequency is dynamically controlled through the max_retry_count and retry_time parameters.

[0009] Preferably, when designing the SDK, the request_no field is used to ensure that the same request is not processed repeatedly.

[0010] Preferably, when designing the SDK, Redis distributed locks are used to prevent concurrency conflicts.

[0011] Preferably, when executing the automatic repair task, according to the submitted abnormal data repair request, the abnormal data is written to the biz_retry_record table through the SDK, the scheduled task woodpeckerRetryJob triggers the repair according to the preset strategy, calls the service_method method to execute the repair logic, notifies the requester of the repair result through the callback RPC interface, and updates the biz_retry_record table status.

[0012] Preferably, when executing the automatic repair task, the repair task is also configured, including the following steps: Define the repair scenario through the system_access_filing table; Dynamically configure the number of retries and intervals; The woodpeckerRetryJob task reads the configuration table in real time and automatically applies new rules.

[0013] The present invention discloses an SDK-based abnormal business data repair system, which is used to implement the above-mentioned SDK-based abnormal business data repair method, including: The configuration module is used to design the SDK by encapsulating the retry logic as an independent service. The retry logic includes idempotency verification, rate limiting and degradation, and failure record storage. The repair module is used to call the SDK interface, obtain abnormal data repair requests, use the SDK to trigger automatic repair tasks according to configuration rules, and execute callback notifications.

[0014] Preferably, the configuration module is used to write the abnormal data of each business system into the biz_retry_record table through the applyDataRetryAgain interface of the SDK; The retry frequency is dynamically controlled by the max_retry_count and retry_time parameters.

[0015] The request_no field ensures that the same request is not processed repeatedly.

[0016] Prevent concurrency conflicts through Redis distributed locks.

[0017] Preferably, the repair module is used to write the abnormal data into the biz_retry_record table through the SDK according to the submitted abnormal data repair request, the scheduled task woodpeckerRetryJob triggers the repair according to the preset strategy, calls the service_method method to execute the repair logic, notifies the requester of the repair result through the callback RPC interface, and updates the biz_retry_record table status. When executing an automatic repair task, you also need to configure the repair task, including the following steps: Define the repair scenario through the system_access_filing table; Dynamically configure the number of retries and intervals; The woodpeckerRetryJob task reads the configuration table in real time and automatically applies new rules.

[0018] The present invention discloses the following technical effects: This invention solves the core problems of existing technologies such as system decentralization, low repair efficiency, and poor stability through three innovative means: SDK encapsulation of universal repair capabilities, unified abnormal data management, and stability assurance mechanism. The advantages of this technical solution are: Development and maintenance costs: Reduce repetitive development through SDK, and reduce maintenance costs through configuration.

[0019] Repair efficiency: The automated repair process reduces manual intervention and increases repair efficiency by 3 times.

[0020] System stability: Current limiting, idempotence, and degradation mechanisms ensure reliability in high-concurrency scenarios.

[0021] Through the above technical solutions, the enterprise-level abnormal data repair system can achieve a technological leap from a "chimney-style system" to a "general platform", providing a standardized and sustainable technical solution for abnormal data repair in multiple business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 This is the SDK access process described in the present invention; Figure 2 This is the automatic repair process described in the present invention; Figure 3 It is the configurable governance capability described in the present invention; Figure 4 It is a schematic flow chart of the method described in the present invention. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0025] like Figures 1-4 As shown, the present invention provides an abnormal business data repair technology based on SDK, including the following contents: 1. First, implement SDK access, which includes the following steps: Step 1.1: Apply for retry: The business party calls the SDK interface to submit a request to repair abnormal data.

[0026] Step 1.2: Perform request verification: The SDK verifies the legitimacy of the request (such as the scenario and parameter validity).

[0027] Step 1.3: Perform idempotence check: Generate a unique request number request_no to ensure that the same request is not processed repeatedly.

[0028] Step 1.4: Record exception data after verification: Write the exception data to the biz_retry_record table, recording information such as request parameters and retry strategy.

[0029] In step 1.5, a repair task is triggered for abnormal data: the scheduled task woodpeckerRetryJob triggers the repair according to the preset strategy (such as the number of retries and the interval time).

[0030] Step 1.6: After the repair, execute callback notification: After the repair is completed, notify the business party of the processing results through the callback RPC interface.

[0031] 2. Secondly, when repairing abnormal data, perform automatic repair, including the following steps: Step 2.1: Before executing the automatic repair, submit the request: the business party calls the SDK interface to submit the abnormal data repair request.

[0032] Step 2.2: Record data based on the submitted request: The SDK writes the exception data to the biz_retry_record table.

[0033] Step 2.3: After the abnormal data is written, a task is triggered: the scheduled task woodpeckerRetryJob triggers repair according to the preset strategy.

[0034] Step 2.4: After receiving the trigger instruction, perform task repair: call the service_method method of the business system to execute the repair logic.

[0035] Step 2.5: Provide feedback based on the repair results: The repair results are notified to the business party through the callback RPC interface, and the biz_retry_record table status is updated.

[0036] 3. Finally, perform configuration-based governance, which includes the following processes: Step 3.1: Define configurations based on repair scenarios: The business side defines repair scenarios (such as access_code, scene, and retry_time) through the system_access_filing table.

[0037] Step 3.2: Set policies based on the defined repair scenarios: Dynamically configure parameters such as the number of retries and interval time without requiring code changes.

[0038] Step 3.3: Apply rules based on the designed strategy: The woodpeckerRetryJob task reads the configuration table in real time and automatically applies the new rules.

[0039] This invention encapsulates universal retry capabilities through SDK, abstracting retry logic (such as idempotence verification, current limiting and degradation, and failure record storage) into independent services. Business parties only need to call the SDK interface to complete abnormal data repair, without the need to repeatedly develop retry modules. Among them, the SDK provides an out-of-the-box retry framework. Business parties only need to focus on repair logic and do not need to maintain retry trigger timing and error data records. Through the design of this invention, 80% of retry requirements can be completed through configuration, development time is shortened from 7 days to 3 days, and maintenance costs are reduced by 50%. This invention integrates the SDK with a unified exception data pool to achieve centralized management and automated repair of exception data. Standardized access to exception data is achieved through the SDK's applyDataRetryAgain interface, which writes exception data from each business system to the biz_retry_record table, eliminating data silos. The automated repair process, based on the woodpeckerRetryJob task, automatically triggers repairs based on preset policies (such as the number of retries and intervals), reducing manual intervention. This design improves exception data repair efficiency by three times, reducing the manual error rate to below 0.1%.

[0040] The present invention lowers the threshold for business access and improves system scalability through the SDK's low-intrusive access mechanism. Configuration drives repair rules: repair scenarios (such as access_code, scene, and retry_time) are dynamically configured through the system_access_filing table, allowing retry strategies to be adjusted without modifying the code. A universal interface adapts to multiple businesses: The SDK adapts the repair logic of different businesses through the service_method and service_impl parameters, supporting the rapid expansion of new scenarios. Through the design of the present invention, the time required to access new businesses is reduced from five man-days to one man-day, and 80% of repair rules can be adjusted through configuration without requiring code changes.

[0041] The present invention ensures the reliability and consistency of the repair process through the SDK's built-in stability assurance capabilities, including current limiting and degradation: dynamically controlling the retry frequency through the max_retry_count and retry_time parameters to prevent sudden increases in traffic; and quickly turning off the repair function through a global degradation switch. Idempotence verification: ensuring that the same request is not processed repeatedly through the request_no field (unique request number) to avoid the risk of asset loss. Distributed locks and anti-duplication: preventing concurrency conflicts through Redis distributed locks. The design of the present invention improves system stability by 30%, reduces the risk of asset loss to less than 0.01%, and supports reliable repair in high-concurrency scenarios.

[0042] This invention achieves full-link observability of the repair process through the SDK's built-in monitoring and snapshot capabilities. Specifically, in the case of point-of-care monitoring, the SDK automatically records the call link (trace_link), status (status), and result (result_record) of the repair request, supporting real-time alerts. Snapshot information: The growth_member_snapshot table saves the configuration and data status before the repair, supporting backtracking to historical versions. This invention reduces problem locating time from hours to minutes, and increases the repair success rate to 99.9%.

[0043] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0044] In the description of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, "plurality" means two or more, unless otherwise specifically defined.

[0045] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A method for repairing abnormal business data based on SDK, characterized in that: The following steps are involved: Design an SDK by encapsulating retry logic as an independent service, where the retry logic includes idempotency verification, rate limiting and degradation, and failure record storage; Call the SDK interface to obtain abnormal data repair requests, use the SDK to trigger automatic repair tasks according to configuration rules, and execute callback notifications.

2. The SDK-based abnormal business data repair method according to claim 1, characterized in that: When designing the SDK, the exception data of each business system is written uniformly into the biz_retry_record table through the SDK's applyDataRetryAgain interface.

3. The SDK-based abnormal business data repair method according to claim 2, characterized in that: When designing the SDK, the retry frequency is dynamically controlled through the max_retry_count and retry_time parameters.

4. The SDK-based abnormal business data repair method according to claim 3, characterized in that: When designing the SDK, use the request_no field to ensure that the same request is not processed repeatedly.

5. The SDK-based abnormal business data repair method according to claim 4, characterized in that: When designing the SDK, Redis distributed locks are used to prevent concurrency conflicts.

6. The SDK-based abnormal business data repair method according to claim 5, characterized in that: When executing an automatic repair task, based on the submitted abnormal data repair request, the abnormal data is written to the biz_retry_record table through the SDK. The scheduled task woodpeckerRetryJob triggers the repair according to the preset strategy, calls the service_method method to execute the repair logic, notifies the requester of the repair result through the callback RPC interface, and updates the status of the biz_retry_record table.

7. The SDK-based abnormal business data repair method according to claim 6, characterized in that: When executing an automatic repair task, you also need to configure the repair task, including the following steps: Define the repair scenario through the system_access_filing table; Dynamically configure the number of retries and intervals; The woodpeckerRetryJob task reads the configuration table in real time and automatically applies new rules.

8. An abnormal business data repair system based on SDK, used to implement the abnormal business data repair method based on SDK as claimed in claim 1, characterized in that: include: A configuration module for designing an SDK by encapsulating retry logic as an independent service, where the retry logic includes idempotency verification, rate limiting and degradation, and failure record storage; The repair module is used to call the SDK interface, obtain abnormal data repair requests, use the SDK to trigger automatic repair tasks according to configuration rules, and execute callback notifications.

9. The SDK-based abnormal business data repair system according to claim 8, characterized in that: The configuration module is used to write the abnormal data of each business system into the biz_retry_record table through the applyDataRetryAgain interface of the SDK; dynamically control the retry frequency through the max_retry_count and retry_time parameters; ensure that the same request is not processed repeatedly through the request_no field; and prevent concurrency conflicts through Redis distributed locks.

10. The SDK-based abnormal business data repair system according to claim 9, characterized in that: The repair module is used to write the abnormal data into the biz_retry_record table through the SDK according to the submitted abnormal data repair request, the scheduled task woodpeckerRetryJob triggers the repair according to the preset strategy, calls the service_method method to execute the repair logic, notifies the requester of the repair result through the callback RPC interface, and updates the biz_retry_record table status; wherein, When executing an automatic repair task, you also need to configure the repair task, including the following steps: Define the repair scenario through the system_access_filing table; Dynamically configure the number of retries and intervals; The woodpeckerRetryJob task reads the configuration table in real time and automatically applies new rules.

Images