Data processing method and device, equipment and medium

Abstract

The invention relates to the technical field of data processing, and discloses a data processing method and device, equipment and a medium, and the method comprises the steps: receiving a claim settlement dispatching message, and carrying out the analysis of the claim settlement dispatching message, and obtaining the key data of claim settlement; the interface calling task set comprises a case query interface, a whole case survey interface and a vehicle loss assessment interface; performing classified storage on the downstream interface data according to the access frequency and the data type to obtain storage data; wherein the storage data comprises high-frequency data in a local cache, low-frequency data in a distributed cache and uncovered data cached in a database; when it is detected that calling of the high-frequency data fails, corresponding data are read from the distributed cache and the database in sequence, and target standby data are obtained. The method can be applied to a financial science and technology and medical care service program system, an emergency data supply mechanism can be realized, and cross-domain high-availability guarantee is further realized, so that stable operation of a claim settlement operation system in a financial and medical service scene is ensured.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a data processing method, apparatus, device, and medium. Background Technology

[0002] As the digital transformation of the financial insurance, healthcare, and elderly care industries accelerates, mobile-oriented claims processing systems are playing an increasingly important role in business processing. In related technologies, claims processing systems typically employ a lightweight aggregated service architecture, relying on numerous downstream interfaces to complete functions such as case inquiry, overall case investigation, vehicle damage assessment, and compensation calculation. However, insurance claims in the financial sector often require calls to dozens or even hundreds of interfaces, resulting in complex interface dependencies and long call chains. If any interface malfunctions, the entire claims process can easily be interrupted, impacting user rights and financial risk management. Similarly, in the healthcare and elderly care sectors, medical claims and health insurance payments heavily rely on the collaboration of multiple systems, including hospital information systems, drug settlement systems, and health record platforms. Data transmission delays or interface failures directly affect patient medical expense settlements and elderly care service fund disbursements, causing social impact.

[0003] Therefore, there is an urgent need for a data processing method that can realize an emergency data supply mechanism, thereby achieving high availability across domains to ensure the stable operation of claims processing systems in financial and medical business scenarios. Summary of the Invention

[0004] This invention provides a data processing method, apparatus, device, and medium to solve the technical problem in related technologies that the emergency data supply mechanism cannot be realized, thus making it impossible to ensure high availability of data across domains.

[0005] Firstly, a data processing method is provided, the method comprising:

[0006] The system receives and parses claims dispatch messages to obtain key claims data, including the case number, vehicle license plate number, and complainant information.

[0007] Based on the key claims data, a set of interface call tasks is generated to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface.

[0008] The downstream interface data is classified and stored according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database;

[0009] When the high-frequency data call fails, the corresponding data is read sequentially from the distributed cache and the database to obtain the target backup data.

[0010] Secondly, a data processing apparatus is provided, comprising:

[0011] The parsing module is used to receive claims dispatch messages and parse the claims dispatch messages to obtain key claims data; wherein, the key claims data includes case number, license plate number and complainant information;

[0012] The generation module is used to generate a set of interface call tasks based on the key claims data to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface.

[0013] The storage module is used to classify and store the downstream interface data according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database;

[0014] The data reading module is used to read the corresponding data from the distributed cache and the database in sequence when the high-frequency data call failure is detected, so as to obtain the target backup data.

[0015] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described data processing method.

[0016] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described data processing method.

[0017] The solution implemented by the aforementioned data processing method, apparatus, computer equipment, and storage medium includes the following steps: receiving a claims dispatch message and parsing it to obtain key claims data; wherein the key claims data includes the case number, license plate number, and complainant information; generating an interface call task set based on the key claims data to obtain downstream interface data; the interface call task set includes a case query interface, a whole-case investigation interface, and a vehicle damage assessment interface; classifying and storing the downstream interface data according to access frequency and data type to obtain stored data; wherein the stored data includes high-frequency data in the local cache, low-frequency data in the distributed cache, and uncovered data cached in the database; when a high-frequency data call failure is detected, reading the corresponding data from the distributed cache and the database sequentially to obtain target backup data. In this invention, by parsing the claims dispatch message and extracting key data such as the case number, license plate number, and complainant information, an interface call task set can be efficiently generated, enabling accurate calls to downstream interfaces and significantly improving data processing efficiency. Meanwhile, by classifying and storing downstream interface data according to access frequency and data type, and establishing a multi-layered data management mechanism among local cache, high-frequency distributed cache, and database, not only is the overhead of repeated interface access reduced, but the overall system response speed and stability are also improved. In the event of a high-frequency data call failure, target backup data can be automatically retrieved from the distributed cache or database, ensuring the continuity and reliability of data acquisition and reducing the risk of business interruption due to single-point data source anomalies. This significantly enhances the processing efficiency, stability, and system reliability of claims processing. Consequently, an emergency data supply mechanism can be implemented, thereby achieving high availability across domains to ensure the stable operation of claims processing systems in financial and healthcare business scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an application environment for a data processing method according to an embodiment of the present invention;

[0020] Figure 2 This is a flowchart illustrating a data processing method according to an embodiment of the present invention;

[0021] Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S30;

[0022] Figure 4This is a schematic diagram of a data processing device in one embodiment of the present invention;

[0023] Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0024] Figure 6 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] The data processing method provided in this embodiment of the invention can be applied to, for example, Figure 1In this application environment, the client communicates with the server via a network. The server can receive claims dispatch messages from the client and parse them to obtain key claims data, including the case number, license plate number, and complainant information. Based on this key claims data, an interface call task set is generated to obtain downstream interface data. This interface call task set includes a case query interface, a whole-case investigation interface, and a vehicle damage assessment interface. The downstream interface data is categorized and stored according to access frequency and data type to obtain stored data. This stored data includes high-frequency data in the local cache, low-frequency data in the distributed cache, and uncovered data cached in the database. When a high-frequency data call fails, the corresponding data is sequentially read from the distributed cache and the database to obtain target backup data. In this invention, by parsing claims dispatch messages and extracting key data such as case number, license plate number, and complainant information, an interface call task set can be efficiently generated, enabling accurate calls to downstream interfaces and significantly improving data processing efficiency. Meanwhile, by classifying and storing downstream interface data according to access frequency and data type, and establishing a multi-layered data management mechanism among local cache, high-frequency distributed cache, and database, not only is the overhead of repeated interface access reduced, but the overall system response speed and stability are also improved. In the event of a high-frequency data call failure, target backup data can be automatically retrieved from the distributed cache or database, ensuring the continuity and reliability of data acquisition, reducing the risk of business interruption due to single-point data source anomalies, and thus significantly enhancing the processing efficiency, stability, and system reliability of claims processing. This enables an emergency data supply mechanism, thereby achieving high availability across domains to ensure the stable operation of the claims processing system in financial and medical business scenarios. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0027] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a data processing method provided in an embodiment of the present invention, the method comprising the following steps:

[0028] S10: Receive the claims dispatch message and parse the claims dispatch message to obtain key claims data.

[0029] The key data for claims processing includes the case number, vehicle license plate number, and information of the person who filed the claim.

[0030] For example, you can first receive a claims dispatch message from the claims management platform, which contains relevant information about the cases to be processed. Then, you can parse the claims dispatch message to extract key data, including the case number used to uniquely identify the claims case, the license plate number used to associate specific vehicle information, and the information of the person who reported the claim used to identify the claim applicant and subsequent contact.

[0031] The above embodiments can ensure that subsequent processing steps can perform operations such as case inquiry, case investigation and vehicle damage assessment based on accurate and complete core data, providing basic data support for claims business and improving overall processing efficiency.

[0032] In some embodiments, receiving a claims dispatch message and parsing the claims dispatch message to obtain key claims data includes: receiving the claims dispatch message and parsing the claims dispatch message to obtain candidate data; wherein, the candidate data includes candidate case number, candidate license plate number and candidate complainant information; and performing data verification and deduplication processing on the candidate data in sequence to obtain the key claims data.

[0033] For example, after receiving a claims dispatch message, the message can first be parsed to obtain candidate data, including candidate case number, candidate license plate number, and candidate complainant information. Then, these candidate data are verified in sequence to ensure the integrity and accuracy of the data, and duplicate or redundant information is deduplicated, thereby finally generating key claims data that can be used for subsequent claims processing.

[0034] The above embodiments can ensure that the obtained case information, vehicle and complainant information are accurate and unique, providing a reliable data foundation for interface calls and claims processing.

[0035] S20: Generate an interface call task set based on the key claims data to obtain downstream interface data; the interface call task set includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface.

[0036] Among them, such as Figure 3 As shown, step S20, which involves generating an interface call task set based on the key claims data to obtain downstream interface data, includes the following steps:

[0037] S21: Based on the key claims data, retrieve historical interface call records to obtain a candidate interface list.

[0038] S22: Perform dependency analysis on the candidate interface list to obtain the interface call sequence chain.

[0039] S23: Generate the set of interface call tasks according to the interface call sequence chain to obtain the list of interface data to be called.

[0040] S24: Call several interfaces in the interface data list to obtain the downstream interface data.

[0041] For example, a set of interface call tasks can first be generated based on the aforementioned key claims data to obtain downstream interface data. Specifically, step S21 retrieves historical interface call records through the key claims data, and filters out a candidate interface list to provide a reference and foundation for subsequent interface calls. Subsequently, step S22 performs dependency analysis on the candidate interface list to clarify the call order and dependencies between interfaces, thereby forming an interface call sequence chain to ensure the logical correctness and data integrity of the interface calls.

[0042] In step S23, an interface call task set can be generated according to the interface call sequence chain, and a list of interface data to be called can be compiled to prepare for the actual interface call. Then, in step S24, several interfaces in the interface data list can be called sequentially to obtain the data returned by the downstream interfaces, including case query results, case investigation information, and vehicle damage assessment information, thereby providing comprehensive and accurate support data for claims processing and improving the efficiency and reliability of claims processing.

[0043] S30: The downstream interface data is classified and stored according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database.

[0044] For example, acquired downstream interface data can be categorized and managed according to access frequency and data type. Frequently accessed data is stored in a local cache to improve read speed, while less frequently accessed data is stored in a distributed cache to balance efficiency and storage scalability. Data not covered by the cache is stored in the database to ensure data integrity. This multi-layered storage strategy not only optimizes data access efficiency but also improves system response performance and reliability, providing robust data support for the rapid processing of claims.

[0045] In some embodiments, classifying and storing the downstream interface data according to access frequency and data type to obtain stored data includes: performing access frequency statistics on the downstream interface data to obtain high-frequency data, low-frequency data, and uncovered data; storing the high-frequency data in the local cache to obtain a high-frequency data storage area; storing the low-frequency data in the distributed cache to obtain a business data storage area; and storing the uncovered data in the database to obtain a fallback data storage area.

[0046] For example, the access frequency of downstream interface data can first be statistically analyzed, dividing the data into three categories: high-frequency data, low-frequency data, and uncovered data. Then, high-frequency data is stored in a local cache to form a high-frequency data storage area for fast access; low-frequency data is stored in a distributed cache to form a business data storage area, balancing access efficiency and storage scalability; and uncovered data is stored in a database to form a fallback data storage area, ensuring reliable storage for all data. This tiered storage strategy not only improves the system's data access efficiency but also enhances the stability and reliability of claims processing.

[0047] S40: When the high-frequency data call failure is detected, the corresponding data is read from the distributed cache and the database in sequence to obtain the target backup data.

[0048] In some embodiments, when the high-frequency data failure is detected, reading the corresponding data sequentially from the distributed cache and the database to obtain the target backup data includes: detecting an exception log during the high-frequency data call process to obtain an exception trigger signal; when the exception trigger signal is received, reading the low-frequency data in the distributed cache to obtain a cache return result; when the cache return result is a distributed cache miss, reading the uncovered data in the database to obtain a database return result; and reading the database return result to obtain the target backup data.

[0049] For example, in step S40, when retrieving high-frequency data, the exception log is monitored in real time. Once a call failure or exception is detected, an exception trigger signal is generated. This signal is used to activate the backup data acquisition mechanism to ensure that claims processing is not interrupted, thereby improving the stability and reliability of the system.

[0050] Furthermore, upon receiving an exception trigger signal, the system first reads the corresponding low-frequency data from the distributed cache to obtain the cached return result. If the distributed cache misses, it then accesses the uncovered data in the database to obtain the database return result. Ultimately, the database return result can be integrated as target backup data to replace the call result of high-frequency data, ensuring data continuity and business assurance in the event of high-frequency data call failure.

[0051] In some embodiments, the method further includes: performing a stress test on the set of interface call tasks to obtain a cache hit rate and a system concurrent processing capability; comparing the cache hit rate and the system concurrent processing capability with corresponding preset thresholds to obtain a performance comparison result; adjusting the cache level size based on the performance comparison result to obtain a tiered storage configuration; and re-executing the stress test based on the tiered storage configuration to obtain an updated performance comparison result.

[0052] For example, stress tests can be performed on the generated set of API call tasks to obtain performance metrics such as cache hit rate and system concurrency processing capability. These metrics are then compared with preset thresholds to obtain performance comparison results, which evaluate the efficiency of the current cache level and system configuration. Based on these comparison results, the cache level size can be dynamically adjusted to form an optimized tiered storage configuration. Stress tests can then be re-executed based on this configuration to obtain updated performance comparison results. This allows for continuous optimization of cache management and system concurrency processing capabilities, improving data processing efficiency and system stability in claims processing.

[0053] In some embodiments, the method further includes: synchronizing the stored data to a training dataset to obtain a claims business knowledge base; performing model training based on the claims business knowledge base to obtain a prediction model; adjusting the interface call order according to the prediction model to obtain an optimized execution plan; and executing the optimized execution plan to obtain the running result.

[0054] For example, downstream interface data stored in categories can be synchronized to a training dataset to build a claims business knowledge base containing case information, vehicle information, and claims process data. Based on this knowledge base, a model can be trained to generate a predictive model capable of predicting the effects of interface calls and the efficiency of business processing. Subsequently, the predictive model can be used to analyze the interface call sequence, optimize the interface call process, generate an optimized execution plan, and execute the plan to obtain the final result. This achieves intelligent scheduling of claims business processing, improving data retrieval efficiency and overall system performance.

[0055] As can be seen, the above solution, by parsing claims dispatch messages and extracting key data such as case number, license plate number, and complainant information, can efficiently generate a set of interface call tasks, enabling precise calls to downstream interfaces and significantly improving data processing efficiency. Simultaneously, by classifying and storing downstream interface data according to access frequency and data type, and establishing a multi-layered data management mechanism between local cache, high-frequency distributed cache, and database, not only is the overhead of repeated interface access reduced, but the overall system response speed and stability are also improved. In the event of a high-frequency data call failure, target backup data can be automatically retrieved from the distributed cache or database, ensuring the continuity and reliability of data acquisition and reducing the risk of business interruption due to single-point data source anomalies. This significantly enhances the processing efficiency, stability, and system reliability of claims operations. Therefore, an emergency data supply mechanism can be implemented, thereby achieving high availability across domains to ensure the stable operation of claims processing systems in financial and medical business scenarios.

[0056] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0057] In one embodiment, a data processing apparatus is provided, which corresponds one-to-one with the data processing methods described in the above embodiments. For example... Figure 4 As shown, the data processing device includes a parsing module 101, a generation module 102, a storage module 103, and a data reading module 104. Detailed descriptions of each functional module are as follows:

[0058] The parsing module 101 is used to receive claims dispatch messages and parse the claims dispatch messages to obtain key claims data; wherein, the key claims data includes case number, license plate number and information of the person who reported the incident;

[0059] The generation module 102 is used to generate an interface call task set based on the key claims data to obtain downstream interface data; the interface call task set includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface;

[0060] The storage module 103 is used to classify and store the downstream interface data according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database;

[0061] The data reading module 104 is used to read the corresponding data from the distributed cache and the database in sequence when the high-frequency data call failure is detected, so as to obtain the target backup data.

[0062] The parsing module 101 is used to receive the claims dispatch message and parse the claims dispatch message to obtain candidate data; wherein, the candidate data includes candidate case number, candidate license plate number and candidate complainant information; the candidate data is sequentially subjected to data verification and deduplication processing to obtain the key claims data.

[0063] The generation module 102 is used to retrieve historical interface call records based on the key claims data to obtain a candidate interface list; perform dependency analysis on the candidate interface list to obtain an interface call sequence chain; generate the interface call task set according to the interface call sequence chain to obtain a list of interface data to be called; and call several interfaces in the interface data list to obtain the downstream interface data.

[0064] The storage module 103 is used to perform access frequency statistics on the downstream interface data to obtain high-frequency data, low-frequency data, and uncovered data; store the high-frequency data in the local cache to obtain a high-frequency data storage area; store the low-frequency data in the distributed cache to obtain a business data storage area; and store the uncovered data in the database to obtain a fallback data storage area.

[0065] The data reading module 104 is used to detect abnormal logs during the retrieval of the high-frequency data and obtain an abnormal trigger signal; when the abnormal trigger signal is received, it reads the low-frequency data in the distributed cache and obtains the cache return result; when the cache return result is that the distributed cache is not hit, it reads the uncovered data in the database and obtains the database return result; and reads the database return result to obtain the target backup data.

[0066] In one embodiment, the data reading module 104 is further configured to: perform stress tests on the interface call task set to obtain cache hit rate and system concurrent processing capability; compare the cache hit rate and the system concurrent processing capability with corresponding preset thresholds to obtain performance comparison results; adjust the cache level size based on the performance comparison results to obtain a tiered storage configuration; and re-execute the stress test based on the tiered storage configuration to obtain updated performance comparison results.

[0067] In one embodiment, the data reading module 104 is further configured to: synchronize the stored data to the training dataset to obtain a claims business knowledge base; perform model training based on the claims business knowledge base to obtain a prediction model; adjust the interface call order according to the prediction model to obtain an optimized execution plan; and execute the optimized execution plan to obtain the running result.

[0068] This invention provides a data processing device that, by parsing claims dispatch messages and extracting key data such as case numbers, license plate numbers, and complainant information, can efficiently generate a set of interface call tasks, enabling precise calls to downstream interfaces and significantly improving data processing efficiency. Simultaneously, by classifying and storing downstream interface data according to access frequency and data type, and establishing a multi-layered data management mechanism among local cache, high-frequency distributed cache, and database, it not only reduces the overhead of repeated interface accesses but also improves the overall system response speed and stability. In the event of a high-frequency data call failure, target backup data can be automatically retrieved from the distributed cache or database, ensuring the continuity and reliability of data acquisition and reducing the risk of business interruption due to single-point data source anomalies. This significantly enhances the processing efficiency, stability, and system reliability of claims operations. Therefore, an emergency data supply mechanism can be implemented, thereby achieving high availability across domains to ensure the stable operation of claims processing systems in financial and medical business scenarios.

[0069] For specific limitations regarding the data processing device, please refer to the limitations regarding the data processing method above, which will not be repeated here. Each module in the aforementioned data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0070] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a data processing method on the server side.

[0071] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a data processing method on the client side.

[0072] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0073] The system receives and parses claims dispatch messages to obtain key claims data, including the case number, vehicle license plate number, and complainant information.

[0074] Based on the key claims data, a set of interface call tasks is generated to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface.

[0075] The downstream interface data is classified and stored according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database;

[0076] When the high-frequency data call fails, the corresponding data is read sequentially from the distributed cache and the database to obtain the target backup data.

[0077] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0078] The system receives and parses claims dispatch messages to obtain key claims data, including the case number, vehicle license plate number, and complainant information.

[0079] Based on the key claims data, a set of interface call tasks is generated to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface.

[0080] The downstream interface data is classified and stored according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database;

[0081] When the high-frequency data call fails, the corresponding data is read sequentially from the distributed cache and the database to obtain the target backup data.

[0082] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0083] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0085] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A data processing method, characterized in that, The method, applied to a claims processing system, includes: The system receives and parses claims dispatch messages to obtain key claims data, including the case number, vehicle license plate number, and complainant information. Based on the key claims data, a set of interface call tasks is generated to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface. The downstream interface data is classified and stored according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database; When the high-frequency data call fails, the corresponding data is read sequentially from the distributed cache and the database to obtain the target backup data.

2. The method according to claim 1, characterized in that, The process of receiving and parsing claims dispatch messages to obtain key claims data includes: The system receives the claims dispatch message and parses it to obtain candidate data; wherein, the candidate data includes candidate case number, candidate license plate number, and candidate complainant information; The candidate data are sequentially validated and deduplicated to obtain the key claims data.

3. The method according to claim 1, characterized in that, The process of generating an interface call task set based on the key claims data to obtain downstream interface data includes: Based on the aforementioned key claims data, historical interface call records are retrieved to obtain a list of candidate interfaces; Dependency analysis is performed on the candidate interface list to obtain the interface call sequence chain; The interface call task set is generated based on the interface call sequence chain to obtain the interface data list to be called; The downstream interface data is obtained by calling several interfaces in the interface data list.

4. The method according to claim 1, characterized in that, The process of classifying and storing the downstream interface data according to access frequency and data type to obtain stored data includes: Access frequency statistics are performed on the downstream interface data to obtain high-frequency data, low-frequency data, and uncovered data; The high-frequency data is stored in the local cache to obtain the high-frequency data storage area; The low-frequency data is stored in the distributed cache to obtain the business data storage area; The uncovered data is stored in the database to obtain a fallback data storage area.

5. The method according to claim 1, characterized in that, When the high-frequency data failure is detected, the corresponding data is sequentially read from the distributed cache and the database to obtain the target backup data, including: During the retrieval of the high-frequency data, anomaly logs are detected to obtain anomaly trigger signals; When the abnormal trigger signal is received, the low-frequency data in the distributed cache is read to obtain the cache return result; When the cache returns a result indicating a cache miss, the uncovered data in the database is read to obtain the database return result. The target backup data is obtained by reading the results returned by the database.

6. The method according to claim 1, characterized in that, The method further includes: Stress tests were performed on the set of interface call tasks to obtain the cache hit rate and system concurrency processing capacity; The cache hit rate and the system's concurrent processing capability are compared with their respective preset thresholds to obtain performance comparison results; Based on the performance comparison results, the cache level size is adjusted to obtain a tiered storage configuration; The stress test was re-executed based on the tiered storage configuration to obtain updated performance comparison results.

7. The method according to claim 1, characterized in that, The method further includes: The stored data is synchronized to the training dataset to obtain the claims business knowledge base; Based on the claims business knowledge base, the execution model is trained to obtain the prediction model; The interface call order is adjusted according to the prediction model to obtain an optimized execution plan; The optimized execution plan was executed to obtain the running results.

8. A data processing apparatus, characterized in that, Applied to claims processing systems, including: The parsing module is used to receive claims dispatch messages and parse the claims dispatch messages to obtain key claims data; wherein, the key claims data includes case number, license plate number and complainant information; The generation module is used to generate a set of interface call tasks based on the key claims data to obtain downstream interface data; the set of interface call tasks includes a case query interface, a whole case investigation interface, and a vehicle damage assessment interface. The storage module is used to classify and store the downstream interface data according to access frequency and data type to obtain stored data; wherein, the stored data includes high-frequency data in local cache, low-frequency data in distributed cache, and uncovered data cached in database; The data reading module is used to read the corresponding data from the distributed cache and the database in sequence when the high-frequency data call failure is detected, so as to obtain the target backup data.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the data processing method as described in any one of claims 1 to 7.

Images