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

Abstract

The invention discloses a micro-service data processing method and device, equipment, a storage medium and a product, relates to the technical field of computers, and discloses a micro-service data processing method which comprises the steps that when a data calling request sent to a server side is abnormal, the data calling request is sent to the server side; determining a change condition of a key value pair of the data calling request in the distributed cache; determining an exception type of the data calling request based on a change condition of the key value pair; and determining an exception handling strategy of the exception type, and executing the exception handling strategy to obtain an exception handling result. According to the method, a distributed cache is provided, under the condition that the data calling request sent to the server side by the client side is abnormal, the root cause of the abnormality of the data calling request can be determined according to the change condition of the key value pair, and then the corresponding abnormality processing strategy is executed according to the root cause of the abnormality of the data calling request. Therefore, the requirement of micro-service data consistency is met.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to microservice data processing methods, devices, equipment, storage media and products. Background Art

[0002] At present, with the development of computer technology, microservice architecture is widely used in software systems to meet the needs of rapid iteration and high concurrency of software systems. Microservice architecture decomposes complex applications into a series of small, autonomous services, each of which runs in an independent process and cooperates with each other through a lightweight communication mechanism. However, the distributed nature of microservice architecture also brings challenges to data consistency. That is, how to ensure the data consistency of microservice architecture is a technical problem that needs to be solved urgently.

[0003] In the related art, different servers of a distributed system exchange data and work together through remote call methods to ensure data consistency between the servers. In this method, when a remote call request sent by a client to a server is abnormal, the client usually retries the remote call request to handle the exception. However, when the client retries the remote call request, the remote call request will be repeatedly processed if the server processes the request timeout, thereby destroying data consistency. That is, this method cannot meet the requirements of microservice data consistency.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

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

[0006] To achieve the above purpose, the present application proposes a microservice data processing method, which is applied to a client, wherein the client is connected to a distributed cache for communication, and the microservice data processing method includes:

[0007] In the case where an exception occurs in a data call request sent to a server, determining a change in a key-value pair of the data call request in the distributed cache, wherein the key-value pair is generated according to the data call request and stored in the distributed cache, and the change in the key-value pair refers to a change between the key-value pair stored in the distributed cache and a result of the server processing the key-value pair under different circumstances, and the change in the key-value pair reflects whether the server has received the data call request;

[0008] Determine the abnormal type of the data call request based on the change of the key-value pair;

[0009] An exception handling strategy for the exception type is determined, and the exception handling strategy is executed to obtain an exception handling result.

[0010] Optionally, the step of determining the abnormal type of the data call request based on the change of the key-value pair includes:

[0011] When the change condition of the key-value pair is that the key-value pair has not changed, determining that the abnormal type of the data call request is a client transmission timeout type;

[0012] When the change condition of the key-value pair is that the key-value pair does not exist, it is determined that the exception type of the data call request is a server processing timeout type.

[0013] Optionally, the server processes the key-value pairs stored in the distributed cache under different circumstances, including that the server does not process the key-value pairs stored in the distributed cache when it does not receive the data call request; or that the server deletes the key-value pairs stored in the distributed cache when it receives the data call request.

[0014] Optionally, when an exception occurs in a data call request sent to a server, the step of determining a change in a key-value pair corresponding to the data call request in the distributed cache includes:

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

[0016] Sending the key-value pair at the first moment to the distributed cache, and synchronously sending the data call request 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;

[0017] Determine whether the data call request is abnormal, and if the data call request is abnormal, obtain the key-value pair of the distributed cache at the second moment;

[0018] The key-value pairs at the first moment are compared with the key-value pairs at the second moment to obtain changes in the key-value pairs corresponding to the data call request in the distributed cache.

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

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

[0021] In the case that no exception occurs in the data call request sent to the server, determining 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 to the key-value pair by the server according to the service version for processing the data call 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, an abnormality handling strategy for the abnormal version is determined, and the abnormality handling strategy for the abnormal version is executed to obtain an abnormality handling result.

[0024] In addition, to achieve the above-mentioned purpose, the present application also proposes a microservice data processing device, the microservice data processing device comprising:

[0025] a change determination module, used for determining the change of the key-value pair of the data call request in the distributed cache when an exception occurs in the data call request sent to the server, 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 circumstances, and the change of the key-value pair reflects whether the server has received the data call request;

[0026] An exception type determination module, used to determine the exception type of the data call request based on the change of the key-value pair;

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

[0028] In addition, to achieve the above-mentioned objectives, the present application also proposes a microservice data processing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the microservice data processing method described above.

[0029] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the microservice data processing method described above are implemented.

[0030] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the microservice data processing method described above are implemented.

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

[0032] Compared with the related art, different servers of the distributed system exchange data and work together through remote call methods to ensure data consistency between the servers. In this method, when the remote call request sent by the client to the server is abnormal, the client usually retries the remote call request to handle the exception. However, when the client retries the remote call request, the remote call request will be repeatedly processed when the server processes the request timeout, which cannot meet the requirements of microservice data consistency. In this application, when the data call request sent by the client 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 circumstances, and the change of the key-value pair reflects whether the server has received the data call request; based on the change of the key-value pair, the abnormal type of the data call request is determined; the abnormal handling strategy of the abnormal type is determined, and the abnormal handling strategy is executed to obtain the abnormal handling result. It is understandable that the present application proposes a distributed cache that is respectively connected to the client and the server in communication. 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. When an exception occurs in the data call request sent by the client to the server, it is only necessary to determine whether the server has received the data call request sent by the client based on the change of the key-value pair, and then determine the root cause of the exception in the data call request, and then execute the corresponding exception handling strategy for the root cause of the exception in the data call request, rather than only adopting a single client retry remote call request strategy, so as to meet the requirements of microservice data consistency. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0035] Figure 1 A flowchart of the first embodiment of the microservice data processing method of the present application is provided;

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

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

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

[0039] Figure 5 A flowchart of the second embodiment of the microservice data processing method of the present application is provided;

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

[0041] Figure 7 Schematic diagram of the device structure of the hardware operating environment involved in the microservice data processing method in the embodiment of the present application.

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

[0043] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0044] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0045] The main solution of the embodiment of the present application is: in the event that an exception occurs in a data call request sent to a server, determining changes in the key-value pairs of the data call request in the distributed cache, wherein the key-value pairs are generated according to the data call request and stored in the distributed cache, and the changes in the key-value pairs refer to 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, and the changes in the key-value pairs reflect whether the server has received the data call request; based on the changes in the key-value pairs, determining the exception type of the data call request; determining an exception handling strategy for the exception type, and executing the exception handling strategy to obtain an exception handling result.

[0046] In the related art, different servers of a distributed system exchange data and work together through remote call methods to ensure data consistency between servers. In this method, when there is an exception in the remote call request sent by the client to the server, the client usually retries the remote call request to handle the exception. However, if the client retries the remote call request and the server processes the request timeout, the remote call request will be repeatedly processed, thereby destroying data consistency. That is, this method cannot meet the requirements of microservice data consistency.

[0047] The present application provides a solution to determine the root cause of the exception in the data call request, and then execute the corresponding exception handling strategy according to the root cause of the exception in the data call request, so as to meet the requirements of microservice data consistency.

[0048] It can be seen from the above embodiments that the present application proposes a distributed cache that is respectively connected to the client and the server in communication. 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. When an exception occurs in the data call request sent by the client to the server, it is only necessary to determine whether the server has received the data call request sent by the client based on the change of the key-value pair, and then determine the root cause of the exception in the data call request, and then execute the corresponding exception handling strategy for the root cause of the exception in the data call request, rather than only adopting a single client retry remote call request strategy, so as to meet the requirements of microservice data consistency.

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

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

[0051] In this embodiment, the microservice data processing method is applied to a client, the client is connected to a distributed cache for communication, and the microservice data processing method includes steps S100 to S300:

[0052] Step S100, in the case where an exception occurs in a data call request sent to a server, determining a change in a key-value pair of the data call request in the distributed cache, wherein the key-value pair is generated according to the data call request and stored in the distributed cache, and the change in the key-value pair refers to a change between the key-value pair stored in the distributed cache and a result of the server processing the key-value pair under different circumstances, and the change in the key-value pair reflects whether the server has received the data call request;

[0053] It should be noted that the microservice data processing method of the present application is applied to the client, and the client is respectively connected to the server and the distributed cache in communication, wherein the distributed cache is preferably a remote key-value storage server Redis. Redis (Remote Dictionary Server) is an open source key-value storage system, usually used as a database, cache or messaging system. Redis stores all data in memory, which enables it to provide extremely high read and write speeds. The present application introduces Redis as a data consistency supervisor and uses its high-speed memory storage characteristics to design a lightweight data consistency guarantee mechanism. Specifically, through Redis's simple key-value operations, the timeout type can be accurately distinguished, and targeted measures can be taken, which not only reduces the complexity but also improves the efficiency of data consistency guarantee, demonstrating a high degree of practicality and flexibility. Reference Figure 2 Before the client initiates a remote call, the request path is stored in Redis as a key-value pair. After receiving the request, the server deletes the corresponding key value according to the path to mark the life cycle status of the request.

[0054] It is understandable that a data call request refers to a data call request sent by a client to a server, including its operations on data, including but not limited to reading, writing or deleting; an exception in a data call request refers to an exception that occurs during the request process, such as a network problem, a server error, etc., which causes the request to fail to be processed normally; a distributed cache is a cache system that shares and stores data between multiple nodes or multiple geographical locations, which allows data sharing across multiple servers or services, and the present application is preferably Redis; a key-value pair includes a key corresponding to the data call request and its corresponding value; the change in the key-value pair refers to the state change of the key-value pair in the distributed cache, including but not limited to adding, modifying or deleting operations, specifically 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 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 call request, that is, the client can infer whether the server has successfully received and processed the client's data call request by observing the change in the key-value pair.

[0055] In the specific implementation, the above content describes multiple situations, including: if the server successfully receives and processes the request, the corresponding key-value pair in the distributed cache will change, and this change can be an update of the value, the addition or deletion of the key-value pair, etc.; if the server does not receive the request, or an exception occurs during the request processing, then the key-value pair may not have the expected change, or there may be an error mark or a special value 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 pair is updated, it can be considered that the request has been processed; if the key-value pair has not changed, it can be considered that the server has not received the data call request sent by the client.

[0056] In a specific implementation, the server processes the key-value pairs stored in the distributed cache under different circumstances, including that the server does not process the key-value pairs stored in the distributed cache when it does not receive the data call request; or that the server deletes the key-value pairs stored in the distributed cache when it receives the data call request.

[0057] In a specific implementation, when an exception occurs in a data call request sent to a server, the step of determining a change in a key-value pair corresponding to the data call request in the distributed cache includes:

[0058] In response to a data call request, generate a key-value pair at a first moment corresponding to the data call request; send the key-value pair at the first moment to the distributed cache, and synchronously send the data call request 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; determine whether the data call request is abnormal, and if the data call request is abnormal, obtain the key-value pair at a second moment of the distributed cache; compare the key-value pair at the first moment with the key-value pair at the second moment to obtain changes in the key-value pair corresponding to the data call request in the distributed cache.

[0059] In the specific implementation, when the user initiates a data call 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 key-value pair at the first moment. The client sends the key-value pair at the first moment to the distributed cache for storage. At the same time, the original data call request is also sent to the server so that the server can process the request.

[0060] In a specific implementation, the server performs corresponding processing according to whether a data call request is received, wherein the processing of the server may cause the key-value pairs stored in the distributed cache at the first moment to change. Specifically, if the server does not receive the data call request, the server does not process the key-value pairs stored in the distributed cache; or, if the server receives the data call request, the server deletes the key-value pairs stored in the distributed cache.

[0061] In a specific implementation, the client determines whether the data call request is abnormal. Specifically, the client can judge by the length of time after the data call request is sent and the corresponding response is not received. For example, if the client does not receive feedback within 10 seconds after sending the data call request, it is determined that the data call request is abnormal. If the data call request is detected to be abnormal, the client will obtain the key-value pair of the current state from the distributed cache. This key-value pair is marked as the key-value pair at the second moment, that is, the key-value pair at the second moment is the key-value pair in the distributed cache within the time after the data call request abnormality is detected, and the key-value pair at the first moment is the key-value pair stored in the distributed cache after the client receives the data call request. The client will compare the key-value pairs at the first moment and the second moment to determine whether there is any change between them. By comparing, the client can obtain the changes in the key-value pairs, which may include value updates, key additions or deletions, etc., where the changes can be used to determine whether the server has successfully processed the data call request and whether the result of the request processing has been reflected in the distributed cache.

[0062] Step S200, determining the abnormal type of the data call request based on the change of the key-value pair;

[0063] In a specific implementation, the client can determine the type of exception that the data call request may encounter by analyzing the changes in the key-value pairs in the distributed cache. The exception type refers to the root cause of the exception in the data call request.

[0064] In a specific implementation, the step of determining the abnormal type of the data call request based on the change of the key-value pair by the client includes:

[0065] When the change of the key-value pair is that the key-value pair has not changed, the exception type of the data call request is determined to be a client transmission timeout type; when the change of the key-value pair is that the key-value pair does not exist, the exception type of the data call request is determined to be a server processing timeout type.

[0066] In the specific implementation, refer to Figure 3 When the change of the key-value pair is that the key-value pair has not changed, it means that the server has not received the data call request sent by the client. When the server has not received the data call request sent by the client and the data call request is abnormal, it can be determined that the abnormal type of the data call request is the client transmission timeout type. In the case where the abnormal type of the data call request is the client transmission timeout type, a retry, fuse or downgrade strategy can be adopted to ensure the consistency of microservice data.

[0067] In the specific implementation, refer to Figure 4 When the change of the key-value pair is that the key-value pair does not exist, it means that the server has received the data call request sent by the client. If the server has received the data call request sent by the client and the data call request is abnormal, it can be determined that the abnormal type of the data call request is the server processing timeout type. In the case where the abnormal type of the data call request is the server processing timeout type, idempotent processing or skipping processing can be adopted to ensure the consistency of microservice data.

[0068] Step S300, determining an exception handling strategy for the exception type, and executing the exception handling strategy to obtain an exception handling result.

[0069] In the specific implementation, when the exception type of the data call request is the client transmission timeout type, a retry, fuse or downgrade strategy can be adopted to ensure the consistency of microservice data; when the exception type of the data call request is the server processing timeout type, idempotent processing or skip processing can be adopted to ensure the consistency of microservice data.

[0070] In the specific implementation, through the above mechanism, the client can accurately respond to various timeout scenarios, intelligently maintain data consistency, and strengthen the stability and reliability foundation of the microservice framework. That is, this application implements differentiated strategies for scenarios where network transmission and service processing time are timed out to ensure data consistency.

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

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

[0073] 2. Low invasiveness: No need to modify business logic, keep code clear and reduce coupling;

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

[0075] 4. Ultra-low latency: With the help of Redis memory storage characteristics, near real-time data processing is achieved and response speed is improved;

[0076] 5. Good scalability: Based on C / S architecture, it is easy to expand channels on demand to meet future growth needs.

[0077] Compared with the related art, different servers of the distributed system exchange data and work together through remote call methods to ensure data consistency between the servers. In this method, when the remote call request sent by the client to the server is abnormal, the client usually retries the remote call request to handle the exception. However, when the client retries the remote call request, the remote call request will be repeatedly processed when the server processes the request timeout, which cannot meet the requirements of microservice data consistency. In this application, when the data call request sent by the client 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 circumstances, and the change of the key-value pair reflects whether the server has received the data call request; based on the change of the key-value pair, the abnormal type of the data call request is determined; the abnormal handling strategy of the abnormal type is determined, and the abnormal handling strategy is executed to obtain the abnormal handling result. It is understandable that the present application proposes a distributed cache that is respectively connected to the client and the server in communication. 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. When an exception occurs in the data call request sent by the client to the server, it is only necessary to determine whether the server has received the data call request sent by the client based on the change of the key-value pair, and then determine the root cause of the exception in the data call request, and then execute the corresponding exception handling strategy for the root cause of the exception in the data call request, rather than only adopting a single client retry remote call request strategy, so as to meet the requirements of microservice data consistency.

[0078] Based on the above first embodiment, the present application also proposes another embodiment, referring to Figure 5 , the microservice data processing method includes:

[0079] Step A100, when no exception occurs in the data call request sent to the server, determining 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 to the key-value pair by the server according to the service version for processing the data call request;

[0080] In a specific implementation, the client sends a request to the server, and the request may include operations on data, such as reading, writing or deleting. If no errors or problems occur during the request processing and the request is successfully received and processed normally by the server, the client still checks the key-value pair of its data call request, specifically determining the version identifier of the key-value pair corresponding to the data call request in the distributed cache. Among them, the version identifier of the key-value pair is the identifier added to the key-value pair by the server according to the service version of processing the data call request, and the service version refers to the current version number of the server application or service. Specifically, after successfully processing the request, the server will add a version identifier to the key-value pair, and this identifier corresponds to the version of the server.

[0081] It should be noted that this application is based on microservice data consistency, and also takes into account the scenario where there are at least two logical processing versions on the server side, such as the old version and the new version. When the server side selects the old version to process its data call request, the data consistency of the microservice will be destroyed. The 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 failure to correctly process requests or incorrect data responses;

[0083] 2. Interface contract changes: If the interface contract (API) between the client and the server changes, the old version of the server may not be able to correctly parse the request or generate the correct response;

[0084] 3. Concurrency processing issues: In high-concurrency scenarios, the old version of the server may not optimize the concurrent processing logic, resulting in race conditions when updating data, thereby destroying data consistency;

[0085] 4. Transaction management: In a microservice environment, transaction management is more complex than in a monolithic application. If the old version of the server does not correctly implement transaction management, some updates may succeed while others fail, resulting in inconsistent data.

[0086] 5. Error handling: Older versions of the server may not have adequate error handling mechanisms, resulting in the inability to recover to a consistent state when an exception occurs;

[0087] 6. Lack of idempotence: If the old version of the server does not implement idempotence, the retry mechanism may cause repeated processing of requests, thereby destroying data consistency.

[0088] Therefore, in order to avoid data consistency damage caused by the above situation, the present application proposes that when the server successfully receives and normally processes the data call request, the server adds a version identifier to the key-value pair stored by the client, so that the client can confirm whether the data call request it sent is processed by the correct version.

[0089] It should be emphasized that in this method, the server adds a version identifier to the key-value pair stored by the client, which is inconsistent with the first embodiment in which the server deletes the key-value pair stored by the client when receiving a data call request. Therefore, in the scheme of the second embodiment, the way the server deletes the key-value pair is modified to add a receiving identifier to the key-value pair. That is, when the change of the key-value pair is that the key-value pair has a receiving identifier, it is determined that the exception type of the data call request is a server processing timeout type.

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

[0091] In a 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 sent by it is processed by the correct version.

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

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

[0094] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the microservice data processing method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0095] This application also provides a microservice data processing device, please refer to Figure 6 , the microservice data processing device comprises:

[0096] A change determination module 10 is used to determine the change of the key-value pair of the data call request in the distributed cache when an exception occurs in the data call request sent to the server, 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 circumstances, and the change of the key-value pair reflects whether the server has received the data call request;

[0097] An exception type determination module 20, used to determine the exception type of the data call request based on the change of the key-value pair;

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

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

[0100] A client transmission timeout type determination module, configured to determine that the abnormal type of the data call request is a client transmission timeout type when the change condition of the key-value pair is that the key-value pair has not changed;

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

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

[0103] A generating module, configured to generate, in response to a data call request, a key-value pair at a first moment corresponding to the data call request;

[0104] A sending module, used to send the key-value pair at the first moment to the distributed cache, and synchronously send the data call request 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;

[0105] A judging module, used for judging whether the data call request is abnormal, and if the data call request is abnormal, obtaining a key-value pair of the distributed cache at a second moment;

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

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

[0108] A version identification determination module, used to determine the version identification of the key-value pair corresponding to the data call request in the distributed cache when no exception occurs in the data call request sent to the server, wherein the version identification of the key-value pair is an identification added to the key-value pair by the server according to the service version for processing the data call request;

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

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

[0111] The microservice data processing device provided by the present application adopts the microservice data processing method in the above embodiment, which can solve the technical problems of microservice data processing. Compared with the prior art, the beneficial effects of the microservice data processing device provided by the present application are the same as the beneficial effects of the microservice data processing method provided by the above embodiment, and other technical features in the microservice data processing device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0112] The present 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice data processing method in the above-mentioned embodiment 1.

[0113] Reference below Figure 7 , which shows a schematic diagram of the structure of a microservice data processing device suitable for implementing an embodiment of the present application. The microservice data processing device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The microservice data processing device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0114] like Figure 7 As shown, the microservice data processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the microservice data processing device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the microservice data processing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a microservice data processing device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0115] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

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

[0117] It should be understood that the various parts disclosed in this application can be implemented by 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 one or more embodiments or examples in a suitable manner.

[0118] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0119] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the microservice data processing method in the above-mentioned embodiment.

[0120] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. 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 combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

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

[0122] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the microservice data processing device, the microservice data processing device performs microservice data processing.

[0123] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0126] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned microservice data processing method, and can solve 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-mentioned embodiment, and will not be repeated here.

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

[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 embodiment, which will not be repeated here.

[0129] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A microservice data processing method, characterized in that: Applied to a client, the client is connected to a distributed cache for communication, and the method for processing microservice data includes: In the case where an exception occurs in a data call request sent to a server, determining a change in a key-value pair of the data call request in the distributed cache, wherein the key-value pair is generated according to the data call request and stored in the distributed cache, and the change in the key-value pair refers to a change between the key-value pair stored in the distributed cache and a result of the server processing the key-value pair under different circumstances, and the change in the key-value pair reflects whether the server has received the data call request; Determine the abnormal type of the data call request based on the change of the key-value pair; An exception handling strategy for the exception type is determined, and the exception handling strategy is executed to obtain an exception handling result.

2. The microservice data processing method according to claim 1, characterized in that: The step of determining the abnormal type of the data call request based on the change of the key-value pair includes: When the change condition of the key-value pair is that the key-value pair has not changed, determining that the abnormal type of the data call request is a client transmission timeout type; When the change condition of the key-value pair is that the key-value pair does not exist, it is determined that the exception type of the data call request is a server processing timeout type.

3. The microservice data processing method according to claim 1, characterized in that: The server's processing results for the key-value pairs stored in the distributed cache under different circumstances include the server not processing the key-value pairs stored in the distributed cache when it has not received the data call request; or the server deleting the key-value pairs stored in the distributed cache when it has received the data call request.

4. The microservice data processing method according to claim 1, characterized in that: The step of determining changes in the key-value pairs corresponding to the data call request in the distributed cache when an exception occurs in the data call request sent to the server includes: In response to a data call request, generating a key-value pair at a first moment corresponding to the data call request; Sending the key-value pair at the first moment to the distributed cache, and synchronously sending the data call request 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; Determine whether the data call request is abnormal, and if the data call request is abnormal, obtain the key-value pair of the distributed cache at the second moment; The key-value pairs at the first moment are compared with the key-value pairs at the second moment to obtain changes in the key-value pairs corresponding to the data call request in the distributed cache.

5. The microservice data processing method according to claim 1, characterized in that: The distributed cache is a remote key-value storage server Redis.

6. The microservice data processing method according to claim 1, characterized in that: The microservice data processing method further includes: In the case that no exception occurs in the data call request sent to the server, determining 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 to the key-value pair by the server according to the service version for processing the data call request; Determine 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 abnormality handling strategy for the abnormal version is determined, and the abnormality handling strategy for the abnormal version is executed to obtain an abnormality handling result.

7. A microservice data processing device, characterized in that: The device comprises: a change determination module, used for determining the change of the key-value pair of the data call request in the distributed cache when an exception occurs in the data call request sent to the server, 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 circumstances, and the change of the key-value pair reflects whether the server has received the data call request; An exception type determination module, used to determine the exception type of the data call request based on the change of the key-value pair; The strategy execution module is used to determine the exception handling strategy of the exception type and execute the exception handling strategy to obtain the exception handling result.

8. A microservice data processing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the microservice data processing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the microservice data processing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the microservice data processing method according to any one of claims 1 to 6 are implemented.

Images