Micro-service data processing method, apparatus, device, storage medium, and product

Abstract

The application discloses a micro-service data processing method, device, equipment, storage medium and product, relates to the computer technical field, and discloses a micro-service data processing method, comprising the following steps: in the case that an exception occurs to a data call request sent to a server, determining the change condition of the key-value pair of the data call request in the distributed cache; determining the exception type of the data call request based on the change condition of the key-value pair; determining the exception processing strategy of the exception type, and executing the exception processing strategy to obtain an exception processing result. The application proposes a distributed cache, and in the case that an exception occurs to a data call request sent to a server, the root cause of the exception of the data call request can be determined according to the change condition of the key-value pair, and then the corresponding exception processing strategy is executed according to the root cause of the exception of the data call request, so that the requirement of micro-service data consistency is met.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to microservice data processing methods, apparatus, devices, storage media and products. Background Technology

[0002] Currently, with the development of computer technology, microservice architecture is widely used in software systems to meet the demands of rapid iteration and high concurrency. Microservice architecture decomposes complex applications into a series of small, autonomous services, each running in an independent process and collaborating with each other through lightweight communication mechanisms. However, the distributed nature of microservice architecture also brings challenges to data consistency; ensuring data consistency within a microservice architecture is a pressing technical problem that needs to be solved.

[0003] In related technologies, different servers in a distributed system exchange data and collaborate through remote method calls to ensure data consistency between servers. This method typically handles exceptions when a remote call request sent from the client to the server fails. However, if the server times out processing the request, this client-side retrying can lead to duplicate processing of the remote call request, thus compromising data consistency. Therefore, this method cannot meet the data consistency requirements of microservices.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a microservice data processing method, which aims to solve the technical problem that the requirements for microservice data consistency cannot be met in related technologies.

[0006] To achieve the above objectives, this application proposes a microservice data processing method applied to a client, wherein the client communicates with a distributed cache, and the microservice data processing method includes:

[0007] In the event of an anomaly in the data retrieval request sent to the server, the changes in the key-value pairs of the data retrieval request in the distributed cache are determined. The key-value pairs are generated based on the data retrieval request and stored in the distributed cache. The changes in the key-value pairs refer to the changes between the key-value pairs stored in the distributed cache and the processing results of the key-value pairs by the server under different circumstances. The changes in the key-value pairs reflect whether the server has received the data retrieval request.

[0008] Based on the changes in the key-value pairs, determine the exception type of the data retrieval request;

[0009] Determine the exception handling strategy for the exception type, execute the exception handling strategy, and obtain the exception handling result.

[0010] Optionally, the step of determining the exception type of the data retrieval request based on the changes in the key-value pairs includes:

[0011] If the key-value pair remains unchanged, then the exception type of the data retrieval request is determined to be the client transmission timeout type.

[0012] If the key-value pair changes to the condition that the key-value pair does not exist, then the exception type of the data call request is determined to be the server processing timeout type.

[0013] Optionally, the processing results of the key-value pairs stored in the distributed cache by the server under different circumstances include: if the server does not receive the data call request, it does not process the key-value pairs stored in the distributed cache; or, if the server receives the data call request, it deletes the key-value pairs stored in the distributed cache.

[0014] Optionally, the step of determining the changes in the key-value pairs corresponding to the data retrieval request in the distributed cache when an anomaly occurs in the data retrieval request sent to the server includes:

[0015] In response to a data retrieval request, generate a key-value pair corresponding to the data retrieval request at the first moment;

[0016] The key-value pair at the first moment is sent to the distributed cache, and the data retrieval request is sent to the corresponding server at the same time. The server performs different processing on the key-value pair at the first moment stored in the distributed cache under different circumstances.

[0017] Determine whether the data retrieval request is abnormal. If the data retrieval request is abnormal, obtain the key-value pair of the distributed cache at the second moment.

[0018] By comparing the key-value pairs at the first time point and the key-value pairs at the second time point, the changes in the key-value pairs corresponding to the data retrieval request in the distributed cache are obtained.

[0019] Optionally, the distributed cache is a remote key-value store server, Redis.

[0020] Optionally, the microservice data processing method further includes:

[0021] If no error occurs in the data retrieval request sent to the server, the version identifier of the key-value pair corresponding to the data retrieval request in the distributed cache is determined, wherein the version identifier of the key-value pair is an identifier added by the server to the key-value pair according to the service version that processes the data retrieval request;

[0022] Determine whether the service version corresponding to the version identifier of the key-value pair is an abnormal version;

[0023] If the service version is an abnormal version, then the abnormal version's exception handling strategy is determined and executed to obtain the exception handling result.

[0024] Furthermore, to achieve the above objectives, this application also proposes a microservice data processing apparatus, which includes:

[0025] The change determination module is used to determine the change status of the key-value pairs of the data call request in the distributed cache when an anomaly occurs in the data call request sent to the server. The key-value pairs are generated based on the data call request and stored in the distributed cache. The change status of the key-value pairs refers to the change between the key-value pairs stored in the distributed cache and the processing results of the key-value pairs by the server under different circumstances. The change status of the key-value pairs reflects whether the server has received the data call request.

[0026] An exception type determination module is used to determine the exception type of the data retrieval request based on the changes in the key-value pairs.

[0027] The strategy execution module is used to determine the exception handling strategy for the exception type, execute the exception handling strategy, and obtain the exception handling result.

[0028] In addition, to achieve the above objectives, this application also proposes a microservice data processing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the microservice data processing method as described above.

[0029] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the microservice data processing method described above.

[0030] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the microservice data processing method described above.

[0031] One or more technical solutions proposed in this application have at least the following technical effects:

[0032] In related technologies, distributed systems exchange data and collaborate between different servers via remote invocation methods to ensure data consistency. In this method, when a remote invocation request sent by the client to the server encounters an anomaly, the client typically retryes the request. However, this retrying method can lead to duplicate processing of the remote invocation request if the server times out, failing to meet the data consistency requirements of microservices. In contrast, this application addresses this issue by determining the changes in the key-value pairs of the data invocation request stored in the distributed cache when the client's request to the server encounters an anomaly. These key-value pairs are generated based on the data invocation request and stored in the distributed cache. The changes in these key-value pairs refer to the changes between the key-value pairs stored in the distributed cache and the server's processing results for the key-value pairs under different circumstances. These changes reflect whether the server has received the data invocation request. Based on these changes, the anomaly type of the data invocation request is determined; an anomaly handling strategy for the anomaly type is determined and executed to obtain the anomaly handling result. Understandably, this application proposes a distributed cache that communicates with both the client and the server. Before the client sends a data call request to the server, a key-value pair about the data call request is stored in the distributed cache. If an exception occurs in the data call request sent by the client to the server, the server can determine whether the client's data call request was received by simply checking the changes in the key-value pair. This allows the server to determine the root cause of the data call request exception and then execute the corresponding exception handling strategy based on the root cause of the exception, rather than simply using a single strategy of retrying the remote call request by the client. This satisfies the data consistency requirements of microservices. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart illustrating the first embodiment of the microservice data processing method of this application.

[0036] Figure 2 This is a schematic diagram of the overall system interaction process of the microservice data processing method in this application;

[0037] Figure 3 This is a schematic diagram of the system interaction process in the client transmission timeout scenario of the microservice data processing method in this application;

[0038] Figure 4 This is a schematic diagram of the system interaction process for handling timeout scenarios on the server side in the microservice data processing method of this application.

[0039] Figure 5 This is a flowchart illustrating the second embodiment of the microservice data processing method of this application.

[0040] Figure 6 This is a schematic diagram of the module structure of the microservice data processing device according to an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the microservice data processing method in this application embodiment.

[0042] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0043] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0044] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0045] The main solution of this application embodiment is as follows: When an anomaly occurs in the data retrieval request sent to the server, determine the changes in the key-value pairs of the data retrieval request in the distributed cache. The key-value pairs are generated based on the data retrieval request and stored in the distributed cache. The changes in the key-value pairs refer to the changes between the key-value pairs stored in the distributed cache and the processing results of the key-value pairs by the server under different circumstances. The changes in the key-value pairs reflect whether the server has received the data retrieval request. Based on the changes in the key-value pairs, determine the anomaly type of the data retrieval request; determine the anomaly handling strategy for the anomaly type, and execute the anomaly handling strategy to obtain the anomaly handling result.

[0046] In related technologies, different servers in a distributed system exchange data and collaborate through remote invocation methods to ensure data consistency between servers. This method typically handles exceptions when a remote invocation request sent from the client to the server fails by retrying the request. However, if the server times out processing the request, this retrying method leads to duplicate processing of the remote invocation request, thus compromising data consistency. Therefore, this method cannot meet the data consistency requirements of microservices.

[0047] This application provides a solution that determines the root cause of an anomaly in a data call request and then executes a corresponding exception handling strategy based on the root cause, thereby meeting the requirements of microservice data consistency.

[0048] As can be seen from the above embodiments, this application proposes a distributed cache that communicates with both the client and the server. Before the client sends a data call request to the server, a key-value pair about the data call request is stored in the distributed cache. If the data call request sent by the client to the server encounters an error, the server can determine whether the client has received the data call request by simply checking the changes in the key-value pair. This allows the server to determine the root cause of the data call request error and then execute the corresponding exception handling strategy based on the root cause, rather than simply using a single strategy of retrying the remote call request by the client. This satisfies the data consistency requirements of microservices.

[0049] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or terminal system capable of performing the above functions. The following description uses a client as an example to illustrate this embodiment and the subsequent embodiments.

[0050] Based on this, embodiments of this application provide a microservice data processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the microservice data processing method of this application.

[0051] In this embodiment, the microservice data processing method is applied to a client, which communicates with a distributed cache. The microservice data processing method includes steps S100 to S300:

[0052] Step S100: In the event of an anomaly in the data retrieval request sent to the server, determine the changes in the key-value pairs of the data retrieval request in the distributed cache. The key-value pairs are generated based on the data retrieval request and stored in the distributed cache. The changes in the key-value pairs refer to the changes between the key-value pairs stored in the distributed cache and the processing results of the key-value pairs by the server under different circumstances. The changes in the key-value pairs reflect whether the server has received the data retrieval request.

[0053] It should be noted that the microservice data processing method of this application is applied to the client, which communicates with both the server and the distributed cache. The distributed cache is preferably a remote key-value store server, Redis. Redis (Remote Dictionary Server) is an open-source key-value store system, commonly used as a database, cache, or message passing system. Redis stores all data in memory, enabling it to provide extremely high read and write speeds. This application introduces Redis as a data consistency monitor, utilizing its high-speed memory storage characteristics to design a lightweight data consistency guarantee mechanism. Specifically, through simple key-value operations in Redis, timeout types can be accurately distinguished, and targeted measures can be taken. This reduces complexity while improving the efficiency of data consistency guarantee, demonstrating high practicality and flexibility. (See reference...) Figure 2 Before the client initiates a remote call, the request path is stored as a key-value pair in Redis. After the server receives the request, it deletes the corresponding key-value pair based on the path, thereby marking the lifecycle status of the request.

[0054] Understandably, a data retrieval request refers to a data retrieval request sent by a client to a server, including its operations on data, including but not limited to reading, writing, or deleting; an abnormal data retrieval request refers to an abnormal situation that occurs during the request process, such as network problems or server errors, causing the request to fail to be processed normally; a distributed cache is a caching system that shares and stores data across multiple nodes or geographical locations, allowing data sharing across multiple servers or services, and Redis is preferred in this application; a key-value pair includes the key corresponding to the data retrieval request and its corresponding value; the change in the key-value pair refers to the change in the state of the key-value pair in the distributed cache, including but not limited to adding, modifying, or deleting operations, specifically referring to the change between the key-value pair stored in the distributed cache and the server's processing result of the key-value pair under different circumstances, that is, the server processes the key-value pair according to the client's request, and the processing result may change the content of the key-value pair in the cache; the change in the key-value pair reflects whether the server has received the data retrieval request, that is, by observing the change in the key-value pair, the client can infer whether the server has successfully received and processed the client's data retrieval request.

[0055] In its implementation, the above describes several scenarios, including: if the server successfully receives and processes the request, the corresponding key-value pairs in the distributed cache will change; this change could be an update of the value, an addition of the key-value pair, or a deletion of the key-value pair. If the server does not receive the request, or an exception occurs during request processing, the key-value pairs may not change as expected, or there may be error markers or special values ​​indicating that the request was not successfully processed. This application can determine whether the server has processed the client's request by checking the changes in the key-value pairs in the distributed cache. For example, if the key-value pairs have been updated, the request can be considered to have been processed; if the key-value pairs have not changed, it can be considered that the server has not received the data access request sent by the client.

[0056] In a specific implementation, the processing results of the key-value pairs stored in the distributed cache by the server under different circumstances include: if the server does not receive the data call request, it does not process the key-value pairs stored in the distributed cache; or, if the server receives the data call request, it deletes the key-value pairs stored in the distributed cache.

[0057] In a specific implementation, the step of determining the changes in the key-value pairs corresponding to the data retrieval request in the distributed cache when an anomaly occurs in the data retrieval request sent to the server includes:

[0058] In response to a data retrieval request, a key-value pair corresponding to the data retrieval request at a first moment is generated; the key-value pair at the first moment is sent to the distributed cache, and the data retrieval request is simultaneously sent to the corresponding server, wherein the server performs different processing on the key-value pair at the first moment stored in the distributed cache under different circumstances; it is determined whether the data retrieval request is abnormal; if the data retrieval request is abnormal, the key-value pair at a second moment is obtained from the distributed cache; the key-value pair at the first moment and the key-value pair at the second moment are compared to obtain the changes in the key-value pair corresponding to the data retrieval request in the distributed cache.

[0059] In the actual implementation, when a user initiates a data retrieval request on the client, the client generates a key-value pair associated with the request. This key-value pair represents the initial state of the request and is marked as the first-moment key-value pair. The client sends the first-moment key-value pair to a distributed cache for storage. At the same time, the original data retrieval request is also sent to the server so that the server can process the request.

[0060] In the specific implementation, the server performs corresponding processing based on whether it receives a data call request. The server's processing may cause changes to the key-value pairs stored in the distributed cache at the first moment. Specifically, if the server does not receive the data call request, it does not process the key-value pairs stored in the distributed cache; or, if the server receives the data call request, it deletes the key-value pairs stored in the distributed cache.

[0061] In the specific implementation, the client determines whether the data call request is abnormal. Specifically, the client can judge by the duration of no response after sending the data call request. For example, if the client does not receive a response within 10 seconds after sending the data call request, it determines that the data call request is abnormal. If an abnormal data call request is detected, the client retrieves the key-value pair of the current state from the distributed cache. This key-value pair is marked as the key-value pair of the second time period. That is, the key-value pair of the second time period is the key-value pair in the distributed cache within the time after the abnormal data call request is detected, while the key-value pair of the first time period is the key-value pair stored in the distributed cache after the client receives the data call request. The client compares the key-value pairs of the first time period and the second time period to determine whether there are any changes between them. By comparing, the client can obtain the changes in the key-value pairs. These changes may include value updates, key additions or deletions, etc. The changes can be used to determine whether the server successfully processed the data call request and whether the result of the request processing has been reflected in the distributed cache.

[0062] Step S200: Determine the exception type of the data retrieval request based on the changes in the key-value pairs;

[0063] In practice, the client can determine the types of exceptions that data retrieval requests might encounter by analyzing changes in key-value pairs in the distributed cache. Here, the exception type refers to the root cause of the data retrieval request exception.

[0064] In a specific implementation, the step of the client determining the exception type of the data retrieval request based on the changes in the key-value pairs includes:

[0065] If the key-value pair remains unchanged, the exception type of the data retrieval request is determined to be client transmission timeout; if the key-value pair does not exist, the exception type of the data retrieval request is determined to be server processing timeout.

[0066] In the specific implementation, refer to Figure 3 If the key-value pair remains unchanged, it indicates that the server has not received the data request from the client. If the server has not received the data request and the data request encounters an anomaly, the anomaly type of the data request can be determined to be a client transmission timeout. In cases where the anomaly type of the data request is a client transmission timeout, retry, circuit breaking, or degradation strategies can be implemented to ensure microservice data consistency.

[0067] In the specific implementation, refer to Figure 4 When the key-value pair changes to the point where it no longer exists, it indicates that the server has received the data request from the client. If the server has received the data request and the request encountered an error, the error type can be determined to be a server-side processing timeout. In cases where the error type is a server-side processing timeout, idempotent processing or skipping the process can be implemented to ensure microservice data consistency.

[0068] Step S300: Determine the exception handling strategy for the exception type and execute the exception handling strategy to obtain the exception handling result.

[0069] In practical implementation, when the exception type of the data call request is client transmission timeout, retry, circuit breaking, or degradation strategies can be adopted to ensure microservice data consistency; when the exception type of the data call request is server processing timeout, idempotent processing or skipping processing can be adopted to ensure microservice data consistency.

[0070] In its implementation, the aforementioned mechanism enables clients to accurately respond to various timeout scenarios, intelligently maintain data consistency, and strengthen the stability and reliability of the microservice framework. Specifically, this application implements differentiated strategies for network transmission and service processing timeout scenarios to ensure data consistency.

[0071] Specifically, this application has the following significant advantages:

[0072] 1. Zero additional framework burden: Relying solely on Redis, avoiding the introduction of new dependencies and reducing system complexity;

[0073] 2. Low intrusion: No need to modify business logic, keeping code clear and reducing coupling;

[0074] 3. Easy to learn and use: No need to master complex frameworks, making it easy to get started quickly;

[0075] 4. Ultra-low latency: Leveraging Redis's in-memory storage capabilities, it achieves near real-time data processing, improving response speed;

[0076] 5. Excellent scalability: Based on a C / S architecture, it is easy to expand channels as needed to meet future growth requirements.

[0077] In related technologies, distributed systems exchange data and collaborate between different servers via remote invocation methods to ensure data consistency. In this method, when a remote invocation request sent by the client to the server encounters an anomaly, the client typically retryes the request. However, this retrying method can lead to duplicate processing of the remote invocation request if the server times out, failing to meet the data consistency requirements of microservices. In contrast, this application addresses this issue by determining the changes in the key-value pairs of the data invocation request stored in the distributed cache when the client's request to the server encounters an anomaly. These key-value pairs are generated based on the data invocation request and stored in the distributed cache. The changes in these key-value pairs refer to the changes between the key-value pairs stored in the distributed cache and the server's processing results for the key-value pairs under different circumstances. These changes reflect whether the server has received the data invocation request. Based on these changes, the anomaly type of the data invocation request is determined; an anomaly handling strategy for the anomaly type is determined and executed to obtain the anomaly handling result. Understandably, this application proposes a distributed cache that communicates with both the client and the server. Before the client sends a data call request to the server, a key-value pair about the data call request is stored in the distributed cache. If an exception occurs in the data call request sent by the client to the server, the server can determine whether the client's data call request was received by simply checking the changes in the key-value pair. This allows the server to determine the root cause of the data call request exception and then execute the corresponding exception handling strategy based on the root cause of the exception, rather than simply using a single strategy of retrying the remote call request by the client. This satisfies the data consistency requirements of microservices.

[0078] Based on the first embodiment described above, this application also proposes another embodiment, which is referred to below. Figure 5 The microservice data processing method includes:

[0079] Step A100: If no abnormality occurs in the data call request sent to the server, determine the version identifier of the key-value pair corresponding to the data call request in the distributed cache, wherein the version identifier of the key-value pair is an identifier added by the server to the key-value pair according to the service version that processes the data call request;

[0080] In the specific implementation, the client sends a request to the server. This request may include data operations such as reading, writing, or deleting. If no errors or problems occur during request processing, and the request is successfully received and processed normally by the server, the client still checks the key-value pairs of its data retrieval request. Specifically, it determines the version identifier of the corresponding key-value pair in the distributed cache. The version identifier of the key-value pair is an identifier added by the server based on the service version used to process the data retrieval request. The service version refers to the current version number of the server application or service. Specifically, after successfully processing the request, the server adds a version identifier to the key-value pair, which corresponds to the server's version.

[0081] It should be noted that this application, based on microservice data consistency, also considers scenarios where there are at least two logical processing versions on the server side, such as an old version and a new version. When the server selects the old version to process data call requests, it will disrupt the data consistency of the microservice. Specific reasons include:

[0082] 1. Data model mismatch: The old version of the server may use an outdated data model that is incompatible with the current data model, resulting in the inability to process requests correctly or to generate incorrect data responses;

[0083] 2. Changes in API Contract: If the API contract between the client and the server changes, older versions of the server may not be able to correctly parse requests or generate correct responses.

[0084] 3. Concurrency issues: In high-concurrency scenarios, older versions of the server may not have optimized concurrency processing logic, leading to race conditions during data updates and thus compromising data consistency.

[0085] 4. Transaction Management: In a microservices environment, transaction management is more complex than in a monolithic application. If older versions of the server do not implement transaction management correctly, some updates may succeed while others fail, leading to data inconsistency.

[0086] 5. Error handling: Older versions of the server may not have adequate error handling mechanisms, making it impossible to restore to a consistent state when an exception occurs;

[0087] 6. Lack of idempotency: If the old version of the server does not implement idempotency, the retry mechanism may cause duplicate requests, thereby compromising data consistency.

[0088] Therefore, to avoid data inconsistency issues caused by the above situations, this application proposes that when the server successfully receives and processes the data call request normally, the server adds a version identifier to the key-value pair stored on the client, so that the client can confirm whether the data call request it sent has been processed by the correct version.

[0089] It should be emphasized that the method in which the server adds a version identifier to the key-value pairs stored on the client contradicts the first embodiment, which deletes the key-value pairs stored on the client when the server receives a data call request. Therefore, in the second embodiment, the method of deleting key-value pairs by the server is modified to add a receiving identifier to the key-value pairs. That is, when the change of the key-value pairs is that the key-value pairs have a receiving identifier, the exception type of the data call request is determined to be the server processing timeout type.

[0090] Step A200: Determine whether the service version corresponding to the version identifier of the key-value pair is an abnormal version;

[0091] In the specific implementation, the client determines whether the service version corresponding to the version identifier of the key-value pair is an abnormal version, that is, the client confirms whether the data call request it sent is processed by the correct version.

[0092] Step A300: If the service version is an abnormal version, then determine the abnormal version's exception handling strategy and execute the abnormal version's exception handling strategy to obtain the exception handling result.

[0093] In the specific implementation, if the service version is an abnormal version, the client determines the exception handling strategy for the abnormal version and executes the exception handling strategy to obtain the exception handling result. Specifically, the exception handling strategy for the abnormal version may be to discard / cancel the previous data call request and display a prompt that the version is too low and to update the version.

[0094] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the microservice data processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0095] This application also provides a microservice data processing apparatus; please refer to [reference needed]. Figure 6 The microservice data processing device includes:

[0096] The change determination module 10 is used to determine the change status of the key-value pairs of the data call request in the distributed cache when an anomaly occurs in the data call request sent to the server. The key-value pairs are generated based on the data call request and stored in the distributed cache. The change status of the key-value pairs refers to the change between the key-value pairs stored in the distributed cache and the processing results of the key-value pairs by the server under different circumstances. The change status of the key-value pairs reflects whether the server has received the data call request.

[0097] The exception type determination module 20 is used to determine the exception type of the data retrieval request based on the changes in the key-value pairs;

[0098] The strategy execution module 30 is used to determine the exception handling strategy for the exception type, execute the exception handling strategy, and obtain the exception handling result.

[0099] Optionally, the exception type determination module 20 includes:

[0100] The client transmission timeout type determination module is used to determine the exception type of the data call request as client transmission timeout type when the key-value pair has not changed.

[0101] The server-side processing timeout type determination module is used to determine the exception type of the data call request as server-side processing timeout when the change of the key-value pair is that the key-value pair does not exist.

[0102] Optionally, the change determination module 10 includes:

[0103] The generation module is used to generate key-value pairs corresponding to the data call request in the first moment in response to the data call request;

[0104] The sending module is used to send the key-value pairs at the first moment to the distributed cache and simultaneously send the data call request to the corresponding server. The server performs different processing on the key-value pairs at the first moment stored in the distributed cache under different circumstances.

[0105] The judgment module is used to determine whether the data call request is abnormal. If the data call request is abnormal, the key-value pair of the distributed cache at the second moment is obtained.

[0106] The comparison module is used to compare the key-value pairs at the first time point and the key-value pairs at the second time point to obtain the changes in the key-value pairs in the distributed cache corresponding to the data call request.

[0107] Optionally, the microservice data processing device further includes:

[0108] The version identifier determination module is used to determine the version identifier of the key-value pair corresponding to the data call request in the distributed cache when no abnormality occurs in the data call request sent to the server. The version identifier of the key-value pair is an identifier added by the server to the key-value pair according to the service version that processes the data call request.

[0109] An abnormal version determination module is used to determine whether the service version corresponding to the version identifier of the key-value pair is an abnormal version;

[0110] An exception handling strategy execution module is used to determine the exception handling strategy for the exception version if the service version is an exception version, and execute the exception handling strategy for the exception version to obtain the exception handling result.

[0111] The microservice data processing apparatus provided in this application, employing the microservice data processing method in the above embodiments, can solve the technical problems of microservice data processing. Compared with the prior art, the beneficial effects of the microservice data processing apparatus provided in this application are the same as those of the microservice data processing method provided in the above embodiments, and other technical features in the microservice data processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a microservice data processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the microservice data processing method in Embodiment 1 above.

[0113] The following is for reference. Figure 7 This document illustrates a structural diagram of a microservice data processing device suitable for implementing embodiments of this application. The microservice data processing device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The microservice data processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 7 As shown, the microservice data processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the microservice data processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the microservice data processing device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a microservice data processing device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The microservice data processing device provided in this application, employing the microservice data processing method in the above embodiments, can solve the technical problems of microservice data processing. Compared with the prior art, the beneficial effects of the microservice data processing device provided in this application are the same as those of the microservice data processing method provided in the above embodiments, and other technical features in this microservice data processing device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the microservice data processing method in the above embodiments.

[0120] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable storage medium may be included in the microservice data processing device; or it may exist independently and not assembled into the microservice data processing device.

[0122] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the microservice data processing device, cause the microservice data processing device to: microservice data processing.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0126] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described microservice data processing method, and is capable of solving the technical problems of microservice data processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the microservice data processing method provided in the above embodiments, and will not be repeated here.

[0127] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the microservice data processing method described above.

[0128] The computer program product provided in this application can solve the technical problem of microservice data processing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the microservice data processing method provided in the above embodiments, and will not be repeated here.

[0129] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A microservice data processing method, characterized in that, The micro-service data processing method is applied to a client connected with a distributed cache, and comprises the following steps: In the case that the data call request sent to the server is abnormal, the change of the key-value pair of the data call request in the distributed cache is determined, wherein the key-value pair is generated according to the data call request and stored in the distributed cache, and the change of the key-value pair refers to the change between the key-value pair stored in the distributed cache and the processing result of the key-value pair by the server under different conditions, and the change of the key-value pair reflects whether the data call request is received by the server; Based on the change of the key-value pair, the type of the abnormal data call request is determined; The abnormal processing strategy of the abnormal type is determined, and the abnormal processing result is obtained by executing the abnormal processing strategy. 2.The micro-service data processing method of claim 1, wherein, The step of determining the type of the abnormal data call request based on the change of the key-value pair comprises: When the change of the key-value pair is that the key-value pair does not change, it is determined that the type of the abnormal data call request is the client transmission timeout type; When the change of the key-value pair is that the key-value pair does not exist, it is determined that the type of the abnormal data call request is the server processing timeout type. 3.The micro-service data processing method of claim 1, wherein, The processing result of the key-value pair stored in the distributed cache by the server under different conditions comprises that the server does not process the key-value pair stored in the distributed cache in the case that the data call request is not received, or the server deletes the key-value pair stored in the distributed cache in the case that the data call request is received. 4.The micro-service data processing method of claim 1, wherein, The step of determining the change of the key-value pair of the data call request in the distributed cache in the case that the data call request sent to the server is abnormal comprises: In response to the data call request, the key-value pair corresponding to the first time of the data call request is generated; The key-value pair of the first time is sent to the distributed cache, and the data call request is sent to the corresponding server at the same time, wherein the server executes different processing on the key-value pair of the first time stored in the distributed cache under different conditions; It is judged whether the data call request is abnormal, and if the data call request is abnormal, the key-value pair of the second time of the distributed cache is obtained; The key-value pair of the first time and the key-value pair of the second time are compared to obtain the change of the key-value pair of the data call request in the distributed cache. 5.The micro-service data processing method of claim 1, wherein, The distributed cache is a remote key-value storage server Redis.

6. The microservice data processing method of claim 1, wherein, The micro-service data processing method further comprises: In the case that the data call request sent to the server is not abnormal, the version identifier of the key-value pair corresponding to the data call request in the distributed cache is determined, wherein the version identifier of the key-value pair is an identifier added to the key-value pair by the server according to the service version of processing the data call request; It is judged whether the service version corresponding to the version identifier of the key-value pair is an abnormal version; If the service version is an abnormal version, an abnormal processing strategy of the abnormal version is determined, and the abnormal processing strategy of the abnormal version is executed to obtain an abnormal processing result.

7. A microservice data processing apparatus, characterized by, The device comprises: The change determination module is configured to determine a change of a key-value pair of the data call request in the distributed cache in the case that the data call request sent to the server is abnormal, wherein the key-value pair is generated according to the data call request and stored in the distributed cache, the change of the key-value pair refers to a change between the key-value pair stored in the distributed cache and a processing result of the key-value pair by the server under different conditions, and the change of the key-value pair reflects whether the data call request is received by the server; The exception type determination module is configured to determine an exception type of the data call request based on the change of the key-value pair; The strategy execution module is configured to determine an abnormal processing strategy of the exception type and execute the abnormal processing strategy to obtain an abnormal processing result.

8. A microservices data processing device, characterized by, The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the micro-service data processing method according to any one of claims 1 to 6.

9. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the micro-service data processing method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the steps of the micro-service data processing method according to any one of claims 1 to 6.

Images