CN111258723A - Transaction processing method, device, system, medium and equipment of distributed system - Google Patents

Abstract

The present disclosure relates to a transaction processing method, device, system, medium and device for a distributed system. The method includes: intercepting a service invocation request initiated by a service caller application, wherein the service invocation request includes the service requested to be invoked; There is a preset consistency identifier in the service invocation request, construct an event object according to the method metadata of the service invoked by the request, and store the event object in the published event list, wherein the initial state of the event object is Unavailable. Publish; select a target object from the event objects whose status is unpublished in the published event list, and publish a request message corresponding to the target object to the message middleware, where the request message includes the target corresponding to the target object Method metadata for a service to enable a service provider application that provides the target service to provide the target service based on the request message. Thus, the eventual consistency of transaction processing in the distributed system can be guaranteed.

Description

Transaction processing method, apparatus, system, medium and device for distributed system

technical field

The present disclosure relates to the field of computer technologies, and in particular, to a transaction processing method, apparatus, system, medium and device for a distributed system.

Background technique

With the popularity and popularity of distributed service architecture, multiple logical operations that were originally performed in a single application are now split into remote calls between multiple services. The challenge that comes with it is the problem of distributed transactions . Since each service uses its own separately maintained database, the data operations are not in the same transaction when different services are called remotely. For example, when service A calls service B, service A executes successfully, but service B fails. Since the transaction of service A has been committed and cannot be rolled back, this will lead to data inconsistency.

In the prior art, when solving the problem of data inconsistency in service calls, it is usually a distributed transaction based on TCC (TCC service is composed of Try/Confirm/Cancel services), message eventual consistency transactions and other flexible transactions. Among them, TCC It is implemented based on the compensation mechanism, and in the eventual consistent message transaction, when the transaction processing of the distributed system is performed, the service call request message of the service caller application may be repeatedly sent multiple times, so that the same message exists in the service provider application. Risk of being consumed multiple times. And when the network is interrupted or the network is unstable, the service invocation request or confirmation message needs to be resent multiple times to realize the transaction interaction between the service caller application and the service provider application.

SUMMARY OF THE INVENTION

The purpose of the present disclosure is to provide a transaction processing method, apparatus, system, medium and device for a secure and stable distributed system.

In order to achieve the above object, according to a first aspect of the present disclosure, a transaction processing method for a distributed system is provided, the method comprising:

Intercepting the service invocation request initiated by the service caller application, wherein the service invocation request includes the service requested to be invoked;

If there is a preset consistency identifier in the service invocation request, construct an event object according to the method metadata of the service invoked by the request and store the event object in the published event list, where the initial state of the event object is Unpublished;

Select a target object from the event objects whose status is unpublished in the published event list, and publish a request message corresponding to the target object to the message middleware, where the request message includes the target corresponding to the target object Method metadata for a service to enable a service provider application that provides the target service to provide the target service based on the request message.

Optionally, the publishing the request message corresponding to the target object to the message middleware includes:

The request message is published to a message queue corresponding to the identification information of the service provider application in the message middleware, so that the service provider application can obtain the request message from the message queue.

Optionally, the service caller application is initialized with a publishing lock; before the step of selecting a target object from the event objects whose status is unpublished in the publishing event list, the method further includes:

determining the state of the release lock;

If the state of the release lock is an idle state, update the state of the release lock to a use state, and perform the step of selecting a target object from the event objects whose state is unreleased in the release event list;

After the step of publishing the request message corresponding to the target object to the message middleware, the method further includes:

The state of the release lock is updated to an idle state.

According to a second aspect of the present disclosure, there is provided a transaction processing method for a distributed system, applied to a service provider application, the method comprising:

Obtain a request message from the message middleware, wherein the request message includes method metadata of the service;

Build an event object according to the method metadata of the service and store the event object in a list of processing events, wherein the initial state of the event object is unprocessed;

A target object is selected from the event objects whose status is unprocessed in the processing event list, and according to the method metadata of the target service corresponding to the target object, the method of the target service is executed, so as to initiate an event corresponding to the target object. The service caller application requesting the message provides the target service.

Optionally, the obtaining the request message from the message middleware includes:

The request message is acquired from a message queue corresponding to the identification information of the service provider application in the message middleware.

Optionally, the service provider application is initialized with a processing lock; before the step of selecting a target object from the event objects whose status is unprocessed in the processing event list, the method further includes:

determining the state of the processing lock;

When the state of the processing lock is an idle state, update the state of the processing lock to a use state, and perform the step of selecting a target object from the event objects whose state is unprocessed in the processing event list;

After the step of executing the method for the target service according to the method metadata of the target service corresponding to the target object, the method further includes:

The state of the processing lock is updated to an idle state.

According to a third aspect of the present disclosure, there is provided a transaction processing apparatus of a distributed system, the apparatus comprising:

An interception module, configured to intercept a service invocation request initiated by a service caller application, wherein the service invocation request includes the service requested to be invoked;

a first storage module, configured to construct an event object according to the method metadata of the service invoked by the request in the case of a preset consistency identifier in the service invocation request, and store the event object in a published event list, Wherein, the initial state of the event object is unpublished;

A publishing module, configured to select a target object from the event objects whose status is unpublished in the publishing event list, and publish a request message corresponding to the target object to the message middleware, wherein the request message includes the Method metadata of the target service corresponding to the target object, so that the service provider application that provides the target service provides the target service based on the request message.

Optionally, the publishing module includes:

The request message is published to a message queue corresponding to the identification information of the service provider application in the message middleware, so that the service provider application can obtain the request message from the message queue.

Optionally, the service caller application is initialized with a release lock; the device further includes:

a first determining module, configured to determine the state of the release lock before the release module selects a target object from the event objects whose state is unreleased in the release event list;

a first update module, configured to update the state of the release lock to a use state when the state of the release lock is an idle state, and trigger the release module to change the state from the release event list to unreleased Select the target object from the event object;

The device also includes:

The second update module is configured to update the state of the release lock to an idle state after the release module releases the request message corresponding to the target object to the message middleware.

According to a fourth aspect of the present disclosure, there is provided a transaction processing apparatus of a distributed system, applied to a service provider application, the apparatus comprising:

an obtaining module, configured to obtain a request message from the message middleware, wherein the request message includes method metadata of the service;

a second storage module, configured to construct an event object according to the method metadata of the service and store the event object in the processing event list, wherein the initial state of the event object is unprocessed;

The execution module is used to select a target object from the event objects whose status is unprocessed in the processing event list, and execute the method of the target service according to the method metadata of the target service corresponding to the target object, so as to initiate all the events. The service caller application of the request message corresponding to the target object provides the target service.

Optionally, the obtaining module includes:

The request message is acquired from a message queue corresponding to the identification information of the service provider application in the message middleware.

Optionally, the service provider application is initialized with a processing lock; the device further includes:

a second determining module, configured to determine the state of the processing lock before the execution module selects a target object from the event objects whose status is unprocessed in the processing event list;

A third update module, configured to update the state of the process lock to a use state when the state of the process lock is an idle state, and trigger the execution module to select the unprocessed event from the process event list Select the target object in the object;

The device also includes:

The fourth update module is configured to update the state of the processing lock to an idle state after the execution module executes the method of the target service according to the method metadata of the target service corresponding to the target object.

According to a fifth aspect of the present disclosure, there is provided a transaction processing system of a distributed system, the system comprising:

a message publishing component, the message publishing component is coupled to the service caller application, and the message publishing component is configured to perform the steps of any one of the methods in the first aspect above;

Message middleware, which is used to store request messages;

A service provider application, where the service provider application is configured to perform the steps of any one of the methods of the second aspect above.

According to a sixth aspect of the present disclosure, there is provided a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, implements the steps of any of the methods described in the first and second aspects above.

According to a seventh aspect of the present disclosure, there is provided an electronic device, comprising:

a memory on which a computer program is stored;

A processor, configured to execute the computer program in the memory, so as to implement the steps of the method in any one of the first aspect and the second aspect.

In the above technical solution, the service call request initiated by the service caller application is intercepted. If there is a preset consistency identifier in the service call request, an event object can be constructed according to the method metadata of the service called by the request and stored in the event object. to the list of published events. Therefore, when publishing the request message corresponding to the service invocation request, it is not directly based on the service invocation request, but selects the target object from the event objects whose status is unpublished in the local publishing event list, so that the corresponding The request message is published to the message middleware, and the request message corresponding to the service call request is published. Through the above technical solution, the request message corresponding to the service invocation request is released based on the release event list, and the remote service invocation request can be converted into local message release, so that in the process of distributed transaction processing, network interruption and transaction exception can be effectively avoided. The problem that the service caller application initiates service invocation requests multiple times due to other reasons can not only avoid the waste of resources caused by repeated service invocation requests, but also ensure that the request message corresponding to the service invocation request can be published to the message middleware, and then Ensure the eventual consistency of transactions and improve the transaction stability and security of distributed systems. In addition, in the above technical solution, by intercepting the service invocation request and determining whether there is a preset consistency identifier in the service invocation request, the intrusiveness of the microservice application when realizing the eventual consistency of the transaction can also be effectively reduced, thereby The complexity of transaction processing of distributed systems can be reduced, and the security and robustness of transaction processing can be further improved.

Other features and advantages of the present disclosure will be described in detail in the detailed description that follows.

Description of drawings

The accompanying drawings are used to provide a further understanding of the present disclosure, and constitute a part of the specification, and together with the following detailed description, are used to explain the present disclosure, but not to limit the present disclosure. In the attached image:

FIG. 1 is a flowchart of a transaction processing method of a distributed system provided according to an embodiment of the present disclosure.

FIG. 2 is a flowchart of a transaction processing method of a distributed system provided according to an embodiment of the present disclosure;

3 is a block diagram of a transaction processing apparatus of a distributed system provided according to an embodiment of the present disclosure;

4 is a block diagram of a transaction processing apparatus of a distributed system provided according to an embodiment of the present disclosure;

5 is a block diagram of an electronic device according to an exemplary embodiment;

Fig. 6 is a block diagram of an electronic device according to an exemplary embodiment.

Detailed ways

The specific embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present disclosure, but not to limit the present disclosure.

In a distributed service architecture, it is necessary to ensure data consistency during transaction processing. When asynchronous calls are made between microservice applications, the invocation of some microservices only needs to ensure the eventual consistency of transactions. The eventual consistency of transactions means that all data copies in the system can eventually reach a consistent state after a certain period of time. . For example, in a scenario that does not require real-time performance, for example, when user A transfers X to user B, after deducting X from user A's account, it is guaranteed that user B's account can eventually be credited to X, so as to ensure data consistency, that is, Realize the eventual consistency of the transfer transaction.

Based on this, the present disclosure provides a transaction processing system of a distributed system, the system comprising:

a message publishing component, the message publishing component is coupled with the service caller application, and the message publishing component is used to publish a request message corresponding to a service invocation request;

Message middleware, which is used to store request messages;

A service provider application, where the service provider application is used to process the request message to provide a corresponding service.

Hereinafter, specific embodiments of the present solution will be described in detail.

The present disclosure provides a transaction processing method for a distributed system. FIG. 1 is a flowchart of a transaction processing method of a distributed system provided according to an embodiment of the present disclosure. The method can be applied to a message publishing component coupled with a service caller application, and the message publishing component can be independent of The service caller application can also be integrated in the service caller application, as shown in FIG. 1 , the method includes:

In S11, intercept the service invocation request initiated by the service caller application, wherein the service invocation request includes the service requested to be invoked.

The service caller application may be a microservice application, and remote calls may be made between the microservice applications. For example, if microservice application A calls microservice application B, the service invocation request may include identification information corresponding to microservice application B, and the identification information may be the application name of microservice application B. For example, in the application scenario of issuing vouchers to users, this can be achieved by invoking the voucher service through the user service, and the user service can send a service invocation request including the application name of the voucher service to invoke the voucher service. Optionally, intercepting the service invocation request initiated by the service caller application may be implemented by an interceptor, and when the user service initiates the service invocation request, the service invocation request may be intercepted by the interceptor. For example, in the Dubbo service framework, an interceptor (filter) can be used to intercept, and for the Spring Cloud service framework, it can be intercepted in feign's interceptor. Among them, the interception methods in the Dubbo service framework and the Spring Cloud service framework are all existing technologies, which will not be repeated here.

In S12, if there is a preset consistency identifier in the service invocation request, construct an event object according to the method metadata of the service invoked by the request and store the event object in the published event list, wherein the initial state of the event object is unpublished .

Among them, for the calling service that needs to ensure the eventual consistency of the transaction, a preset consistency identifier can be added to the interface when calling the remote service. For example, the consistency identifier can be an annotation, and the annotation is used to indicate that the service is being called. , the eventual consistency of the transaction needs to be guaranteed. Among them, the preset consistency identification can be set and added according to actual usage scenarios.

For example, the intercepted service call request is as follows:

That is, in the above service invocation request, the service requested to be invoked is sayHi, and TestServerBLO is the interface for invoking the service sayHi. By intercepting the service invocation request, it is determined that there is a consistency identifier in the service invocation request, that is, the annotation @BaseTransaction, which is used to indicate that the final consistency of the transaction needs to be guaranteed when the service is invoked, that is, it can be determined at this time. When invoking the service based on the service invocation request, it is necessary to ensure the eventual consistency of the transaction.

For example, the method metadata of the service may include the signature of the method of the service, the parameters of the method, and the description of the parameters, etc. The event object constructed according to the method metadata of the service called by the request may be the method metadata of the service called by the request. Structural processing is performed according to the structure corresponding to the event object (EVENT object), thereby constructing the event object, and storing the event object in the published event list, so as to facilitate unified management of the method metadata of the service invoked by the request. It should be noted that the service caller application may correspond to multiple service instances, the multiple service instances are in the same database, the published event list is stored in the database, and the multiple service instances share the published event list.

In S13, a target object is selected from the event objects whose status is unpublished in the published event list, and a request message corresponding to the target object is published to the message middleware, wherein the request message includes the target corresponding to the target object Method metadata for a service to enable a service provider application that provides the target service to provide the target service based on the request message.

Among them, there can be multiple event objects whose status is unpublished in the publishing event list. When selecting the target object, all the event objects whose status is unpublished in the publishing event list can be used as the target object, or the publishing event can be selected as the target object. The event objects whose status is unpublished in the list are the top N event objects in the order of creation time from early to late as the target object, where N can be set according to the actual usage scenario.

For example, the target object may be selected by means of regular polling. For example, the step of selecting the target object from the event objects whose status is unpublished in the published event list may be performed every 2s. In addition, publishing the request message based on the event object in the local publishing event list can make the request message corresponding to the event object whose status is unpublished stored in the publishing event list can be finally published, ensuring data processing. reliability.

In the above technical solution, the service call request initiated by the service caller application is intercepted. If there is a preset consistency identifier in the service call request, an event object can be constructed according to the method metadata of the service called by the request and stored in the event object. to the list of published events. Therefore, when publishing the request message corresponding to the service invocation request, it is not directly based on the service invocation request, but selects the target object from the event objects whose status is unpublished in the local publishing event list, so that the corresponding The request message is published to the message middleware, and the request message corresponding to the service call request is published. Through the above technical solution, the request message corresponding to the service invocation request is released based on the release event list, and the remote service invocation request can be converted into local message release, so that in the process of distributed transaction processing, network interruption and transaction exception can be effectively avoided. The problem that the service caller application initiates service invocation requests multiple times due to other reasons can not only avoid the waste of resources caused by repeated service invocation requests, but also ensure that the request message corresponding to the service invocation request can be published to the message middleware, and then Ensure the eventual consistency of transactions and improve the transaction stability and security of distributed systems. In addition, in the above technical solution, by intercepting the service invocation request and determining whether there is a preset consistency identifier in the service invocation request, the intrusiveness of the microservice application when realizing the eventual consistency of the transaction can also be effectively reduced, thereby The complexity of transaction processing of distributed systems can be reduced, and the security and robustness of transaction processing can be further improved.

The present disclosure also provides a transaction processing method for a distributed system, which is applied to a service provider application. As shown in FIG. 2 , the method includes:

In S21, a request message is obtained from the message middleware, wherein the request message includes method metadata of the service. Therefore, the service provider application can obtain the method metadata of the service by obtaining the request message. For example, the message middleware may be an MQ message queue, and the service provider application may subscribe to messages from the message middleware to obtain the request message.

In S22, an event object is constructed according to the method metadata of the service, and the event object is stored in the processing event list, wherein the initial state of the event object is unprocessed.

The method of constructing the event object according to the method metadata of the service has been described in detail above, and will not be repeated here. For example, the service provider application is a microservice application, the microservice application corresponds to multiple service instances, and the multiple service instances are in the same database, the processing event list is stored in the database, and multiple service instances share A list of the processing events.

In S23, the target object is selected from the event objects whose status is unprocessed in the processing event list, and according to the method metadata of the target service corresponding to the target object, the method of the target service is executed, so as to initiate the service of the request message corresponding to the target object The caller application provides the target service.

Among them, there can be multiple event objects whose status is unprocessed in the processing event list. When selecting the target object, all the event objects whose status is unprocessed in the processing event list can be used as the target object, or the processing event can be selected as the target object. The event objects whose status is unprocessed in the list are the event objects with the top M in the order of creation time from early to late as the target object, where M can be set according to the actual usage scenario.

Similarly, the target object can be selected by regular polling, and the message processing is performed based on the event objects in the local processing event list, so as to ensure that the unprocessed event objects in the processing event list will eventually be processed, ensuring that the transaction eventual consistency.

For example, according to the method metadata of the target service corresponding to the target object, the method of the target service is executed, and the method of the called target service can be reflected according to the method name and parameters in the method metadata. For example, in the above application scenario of issuing vouchers to users, the service provider application can serve vouchers, and the voucher service can reflect the method of calling the voucher service according to the method metadata, so as to execute the method to issue vouchers to users . The transmitting and calling of the method is the prior art, which will not be repeated here.

In the above technical solution, the event object is constructed according to the request message obtained from the message middleware, and the event object is stored in the processing event list. Therefore, when processing the request message, it is not directly processed based on the request message, but is processed based on the selected target object in the local processing event list. Since the target object is the unprocessed event object in the processing event list, repeated processing of the same request message can be avoided, and the event object whose status is unprocessed in the processing event can be finally processed, ensuring the eventual consistency of the transaction. and reliability. At the same time, request message processing is performed based on local transactions, so that message retransmission is not required by message middleware, which can not only avoid resource waste caused by sending request messages multiple times, but also avoid repeated processing of the same message, and improve the transaction processing stability of the distributed system. sex and safety.

Optionally, an exemplary manner of publishing the request message corresponding to the target object to the message middleware is as follows, and this step may include:

The request message is published to a message queue corresponding to the identification information of the service provider application in the message middleware, so that the service provider application can obtain the request message from the message queue.

Correspondingly, when the method is applied to the service provider application, the obtaining the request message from the message middleware includes:

The request message is acquired from a message queue corresponding to the identification information of the service provider application in the message middleware.

Wherein, when each microservice application is started, a message queue and route corresponding to the identification information of the microservice application may be initialized in the message middleware, wherein the identification information of the microservice application may be the microservice application application name. Among them, each microservice application can be used as the identity of the service caller application, and can also be used as the identity of the service provider application, and its specific identity can be determined according to the actual service invocation scenario. For example, when microservice application A calls microservice application B, microservice application B acts as a service provider application; when microservice application B calls microservice application C, microservice application B acts as a service caller application.

For example, the identification information is the application name. When microservice application A calls microservice application B, when publishing a request message corresponding to calling microservice application B, the request message can be published to the message middleware based on the initialized routing In the message queue corresponding to the application name of microservice application B. Therefore, when microservice application B subscribes to messages from the message middleware, the request message can be obtained directly with the application name of microservice application B, that is, the request message can be directly obtained from the message queue corresponding to the application name of microservice application B .

Through the above technical solution, when a service invocation is performed in a distributed system, the request message can be directly sent to the message queue corresponding to the identification information of the service provider application in the message middleware. Management, on the other hand, enables the service provider application to quickly and accurately obtain the request messages it needs to process, reduces the overhead of message subscription, and improves the processing efficiency of request messages. Consistent processing efficiency.

Optionally, when the microservice application is initialized, a publishing lock and a processing lock can be initialized respectively, wherein the publishing lock is used to ensure that the query of the list of published events at the same time is unique, and the processing lock is used to ensure that the query at the same time is unique. Queries that process the list of events are unique at all times.

Exemplarily, the service caller application is initialized with a publishing lock; before the step of selecting a target object from the event objects whose status is unpublished in the publishing event list, the method further includes:

determining the state of the release lock, wherein the initial state of the release lock is an idle state;

If the state of the release lock is the idle state, the state of the release lock is updated to the use state, and the step of selecting a target object from the event objects whose state is unreleased in the release event list is performed.

After the step of publishing the request message corresponding to the target object to the message middleware, the method further includes:

The state of the release lock is updated to an idle state.

In this technical solution, when the service caller application publishes the request message to the message middleware, it needs to ensure that each request message needs to be published, and each request message is unique on the message middleware. Based on this, in order to ensure the high efficiency and throughput of the distributed system, a release lock is initialized for the microservice application in this disclosure, so that when the service caller application publishes the request message, the query of the published event list is unique, thereby Guarantee the uniqueness of request message publication. Before selecting the target object from the unpublished event objects in the publishing event list, by determining the state of the publishing lock, it can be determined whether there is currently a service instance in the microservice application querying the publishing event list, if the status of the publishing lock is In the idle state, it means that there is currently no service instance to query the published event list. At this time, the step of selecting the target object from the event objects whose state is unpublished in the published event list can be performed; if the state of the publishing lock is in the use state, then Indicates that there is currently a service instance querying the publishing event list. At this time, it is necessary to wait for the status of the publishing lock to be updated to the idle state before allowing the querying of the publishing event list.

In the above technical solution, the application of the service caller is initialized with a release lock. When the state of the release lock is idle, it can query the release event list and select the target object from the event objects whose state is unreleased in the release event list. Thus, the request message corresponding to the target object is published to the message middleware. Through the above technical solution, the release lock can ensure that the query for the release event list at the same time is unique, and the release lock is an application lock corresponding to the microservice application, that is, it does not affect database resources (such as the release event list). Locking can effectively improve the high concurrency performance requirements of distributed systems while ensuring the consistency of database resources, effectively reduce lock conflicts, and improve system throughput.

Optionally, the method further includes:

If it is determined that the request message corresponding to the target object is successfully published to the message middleware, the status of the target object in the publication event list is updated to published, thereby avoiding repeated publication of the successfully published request message.

As an example, it can be determined whether the request message corresponding to the target object is successfully published to the message middleware by means of the message middleware feedback message, and when the feedback message from the message middleware is received, it is determined that the request message corresponding to the feedback message is successfully published to the message middleware in the message middleware.

Optionally, when the method is applied to a service provider application, the service provider application is initialized with a processing lock; before the step of selecting a target object from the event objects whose status is unprocessed in the processing event list , the method also includes:

determining the state of the processing lock;

When the state of the processing lock is an idle state, update the state of the processing lock to a use state, and perform the step of selecting a target object from the event objects whose state is unprocessed in the processing event list;

After the step of executing the method for the target service according to the method metadata of the target service corresponding to the target object, the method further includes:

The state of the processing lock is updated to an idle state.

In this technical solution, the service provider application can execute the target service according to the method metadata of the target service corresponding to the target object, so as to process the request message corresponding to the target object. In this process, it is necessary to ensure that the request message can only be successfully processed once. Based on this, in order to avoid repeated processing of request messages, a processing lock is initialized for the microservice application in this disclosure, so that the service provider application executes the method of the target service according to the method metadata of the target service corresponding to the target object, and only Processed by one of its service instances.

For example, before selecting the target object from the event objects whose status is unprocessed in the processing event list, by determining the status of the processing lock, it can be determined whether there are other service instances in the microservice application currently querying the processing event list, if If the status of the processing lock is in the idle state, it means that there is currently no service instance to query the processing event list. At this time, the step of selecting the target object from the event objects whose status is unprocessed in the processing event list can be performed; if the status of the processing lock is in If the status is used, it means that there is currently a service instance querying the processing event list. In order to avoid repeated processing of request messages, it is necessary to wait for the status of the processing lock to be updated to the idle state before allowing the query processing event list.

In the above technical solution, the application of the service caller is initialized with a processing lock. When the status of the processing lock is idle, it can query the processing event list and select the target object from the unprocessed event objects in the processing event list. Thus, the method of the target service is executed according to the method metadata of the target service corresponding to the target object. Through the above technical solution, the processing lock can ensure that the query of the processing event list at the same time is unique, thereby effectively avoiding repeated processing of the request message, and ensuring that the request message corresponding to the target object in the processing event list can be processed. processing, so that the eventual consistency of transaction processing in distributed systems can be guaranteed. And the processing lock is an application lock corresponding to the microservice application, that is, the processing event list resource in the database will not be locked, which improves the concurrency of transaction processing and ensures the stable operation of the distributed system.

Optionally, the method further includes:

If it is determined that the execution of the method of the target service is completed, the status of the target object in the processing event list is updated to published, which can avoid repeated execution of the completed request message and ensure transaction processing consistency. At the same time, the processing status of the request message can also be maintained and recorded based on the release event list and the processing event list, so as to facilitate retrospective.

The present disclosure also provides a transaction processing device for a distributed system. As shown in FIG. 3 , the device 10 includes:

An interception module 101, configured to intercept a service invocation request initiated by a service caller application, wherein the service invocation request includes the service requested to be invoked;

The first storage module 102 is configured to construct an event object according to the method metadata of the service invoked by the request and store the event object in a published event list when there is a preset consistency identifier in the service invocation request , wherein the initial state of the event object is unpublished;

The publishing module 103 is configured to select a target object from the event objects whose status is unpublished in the publishing event list, and publish a request message corresponding to the target object to the message middleware, wherein the request message includes all Method metadata of the target service corresponding to the target object, so that the service provider application that provides the target service provides the target service based on the request message.

Optionally, the publishing module includes:

The request message is published to a message queue corresponding to the identification information of the service provider application in the message middleware, so that the service provider application can obtain the request message from the message queue.

Optionally, the service caller application is initialized with a release lock; the device further includes:

a first determining module, configured to determine the state of the release lock before the release module selects a target object from the event objects whose state is unreleased in the release event list;

a first update module, configured to update the state of the release lock to a use state when the state of the release lock is an idle state, and trigger the release module to change the state from the release event list to unreleased Select the target object from the event object;

The device also includes:

The second update module is configured to update the state of the release lock to an idle state after the release module releases the request message corresponding to the target object to the message middleware.

The present disclosure also provides a transaction processing device for a distributed system, which is applied to a service provider application. As shown in FIG. 4 , the device 20 includes:

an obtaining module 201, configured to obtain a request message from the message middleware, wherein the request message includes method metadata of the service;

The second storage module 202 is configured to construct an event object according to the method metadata of the service and store the event object in the processing event list, wherein the initial state of the event object is unprocessed;

The execution module 203 is configured to select a target object from the event objects whose status is unprocessed in the processing event list, and execute the method of the target service according to the method metadata of the target service corresponding to the target object, in order to initiate The service caller application of the request message corresponding to the target object provides the target service.

Optionally, the obtaining module includes:

The request message is acquired from a message queue corresponding to the identification information of the service provider application in the message middleware.

Optionally, the service provider application is initialized with a processing lock; the device further includes:

a second determining module, configured to determine the state of the processing lock before the execution module selects a target object from the event objects whose status is unprocessed in the processing event list;

A third update module, configured to update the state of the process lock to a use state when the state of the process lock is an idle state, and trigger the execution module to select the unprocessed event from the process event list Select the target object in the object;

The device also includes:

The fourth update module is configured to update the state of the processing lock to an idle state after the execution module executes the method of the target service according to the method metadata of the target service corresponding to the target object.

Regarding the apparatus in the above-mentioned embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be described in detail here.

FIG. 5 is a block diagram of an electronic device 700 according to an exemplary embodiment. As shown in FIG. 5 , the electronic device 700 may include: a processor 701 and a memory 702 . The electronic device 700 may also include one or more of a multimedia component 703 , an input/output (I/O) interface 704 , and a communication component 705 .

Wherein, the processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the above-mentioned transaction processing method of the distributed system. The memory 702 is used to store various types of data to support operations on the electronic device 700, such data may include, for example, instructions for any application or method operating on the electronic device 700, and application-related data, Such as contact data, messages sent and received, pictures, audio, video, and so on. The memory 702 can be implemented by any type of volatile or nonvolatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, SRAM for short), electrically erasable programmable read-only memory ( Electrically Erasable Programmable Read-Only Memory (EEPROM for short), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), read-only Memory (Read-Only Memory, ROM for short), magnetic memory, flash memory, magnetic disk or optical disk. Multimedia components 703 may include screen and audio components. Wherein the screen can be, for example, a touch screen, and the audio component is used for outputting and/or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may be further stored in memory 702 or transmitted through communication component 705 . The audio assembly also includes at least one speaker for outputting audio signals. The I/O interface 704 provides an interface between the processor 701 and other interface modules, and the above-mentioned other interface modules may be a keyboard, a mouse, a button, and the like. These buttons can be virtual buttons or physical buttons. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC for short), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or one or a combination of them , which is not limited here. Therefore, the corresponding communication component 705 may include: Wi-Fi module, Bluetooth module, NFC module and so on.

In an exemplary embodiment, the electronic device 700 may be implemented by one or more Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing (Digital Signal) Processing Device (DSPD for short), Programmable Logic Device (PLD for short), Field Programmable Gate Array (FPGA for short), controller, microcontroller, microprocessor or other electronic components , which is used to execute the above-mentioned transaction processing method of the distributed system.

In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned transaction processing method of a distributed system are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 702 including program instructions, and the above-mentioned program instructions can be executed by the processor 701 of the electronic device 700 to complete the above-mentioned transaction processing method of the distributed system.

FIG. 6 is a block diagram of an electronic device 1900 according to an exemplary embodiment. For example, the electronic device 1900 may be provided as a server. 6 , the electronic device 1900 includes a processor 1922 , which may be one or more in number, and a memory 1932 for storing computer programs executable by the processor 1922 . A computer program stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processor 1922 may be configured to execute the computer program to perform the above-described transaction processing method of the distributed system.

In addition, the electronic device 1900 may also include a power supply component 1926, which may be configured to perform power management of the electronic device 1900, and a communication component 1950, which may be configured to enable communication of the electronic device 1900, eg, wired or wireless communication. Additionally, the electronic device 1900 may also include an input/output (I/O) interface 1958 . Electronic device 1900 may operate based on an operating system stored in memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, and the like.

In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned transaction processing method of a distributed system are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 1932 including program instructions, and the above-mentioned program instructions can be executed by the processor 1922 of the electronic device 1900 to complete the above-mentioned transaction processing method of the distributed system.

In another exemplary embodiment, there is also provided a computer program product comprising a computer program executable by a programmable apparatus, the computer program having, when executed by the programmable apparatus, for performing the above The code part of the transaction processing method of the distributed system.

The preferred embodiments of the present disclosure have been described above in detail with reference to the accompanying drawings. However, the present disclosure is not limited to the specific details of the above-mentioned embodiments. Various simple modifications can be made to the technical solutions of the present disclosure within the scope of the technical concept of the present disclosure. These simple modifications all fall within the protection scope of the present disclosure. E.g.

In addition, it should be noted that each specific technical feature described in the above-mentioned specific implementation manner may be combined in any suitable manner under the circumstance that there is no contradiction. In order to avoid unnecessary repetition, various possible combinations are not described in the present disclosure.

In addition, the various embodiments of the present disclosure can also be arbitrarily combined, as long as they do not violate the spirit of the present disclosure, they should also be regarded as the contents disclosed in the present disclosure.

Claims (10)

1. A method for transaction processing in a distributed system, the method comprising:

intercepting a service calling request initiated by a service caller application, wherein the service calling request comprises a service required to be called;

if the service calling request has a preset consistency identification, constructing an event object according to method metadata of the service called by the request and storing the event object to a published event list, wherein the initial state of the event object is not published;

selecting a target object from the event objects with unpublished states in the published event list, and publishing a request message corresponding to the target object to message middleware, wherein the request message comprises method metadata of a target service corresponding to the target object, so that a service provider application providing the target service provides the target service based on the request message.

2. The method of claim 1, wherein publishing the request message corresponding to the target object to message middleware comprises:

and publishing the request message to a message queue corresponding to the identification information of the service provider application in message middleware so as to obtain the request message from the message queue by the service provider application.

3. The method of claim 1, wherein the service caller application initializes an issue lock; before the step of selecting a target object from the event objects whose states are not published in the published event list, the method further comprises:

determining a status of the issue lock;

if the state of the issue lock is an idle state, updating the state of the issue lock to a use state, and executing the step of selecting a target object from the event objects of which the states in the issue event list are not issued;

after the step of issuing the request message corresponding to the target object to the message middleware, the method further includes:

and updating the state of the issue lock into an idle state.

4. A transaction processing method for a distributed system, applied to a service provider application, the method comprising:

acquiring a request message from message middleware, wherein the request message comprises service method metadata;

constructing an event object according to the service method metadata and storing the event object in a processing event list, wherein the initial state of the event object is unprocessed;

and selecting a target object from the event objects with unprocessed states in the processing event list, and executing a method of the target service according to the method metadata of the target service corresponding to the target object so as to provide the target service for a service caller application initiating a request message corresponding to the target object.

5. The method of claim 4, wherein the obtaining the request message from the message middleware comprises:

and acquiring the request message from a message queue corresponding to the identification information of the service provider application in the message middleware.

6. A transaction processing apparatus for a distributed system, the apparatus comprising:

the system comprises an interception module, a service calling module and a service processing module, wherein the interception module is used for intercepting a service calling request initiated by a service caller application, and the service calling request comprises a service required to be called;

the first storage module is used for constructing an event object according to the method metadata of the service called by the request and storing the event object to a published event list under the condition that a preset consistency identifier exists in the service calling request, wherein the initial state of the event object is not published;

and the publishing module is used for selecting a target object from the event objects with unpublished states in the published event list and publishing a request message corresponding to the target object to message middleware, wherein the request message comprises method metadata of a target service corresponding to the target object, so that a service provider application providing the target service provides the target service based on the request message.

7. A transaction processing apparatus for a distributed system, the apparatus being adapted for use with a service provider application, the apparatus comprising:

an obtaining module, configured to obtain a request message from a message middleware, where the request message includes method metadata of a service;

the second storage module is used for constructing an event object according to the method metadata of the service and storing the event object in a processed event list, wherein the initial state of the event object is unprocessed;

and the execution module is used for selecting a target object from the event objects with unprocessed states in the processing event list, and executing the method of the target service according to the method metadata of the target service corresponding to the target object so as to provide the target service for the service caller application initiating the request message corresponding to the target object.

8. A transaction processing system for a distributed system, the system comprising:

a message publishing component coupled with a service caller application, the message publishing component to perform the steps of the method of any of claims 1-3;

the message middleware is used for storing the request message;

a service provider application for performing the steps of the method of claim 4 or 5.

9. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 5.

10. An electronic device, comprising:

a memory having a computer program stored thereon;

a processor for executing the computer program in the memory to carry out the steps of the method of any one of claims 1 to 5.

Images