li>

• (1). Overview of the eventual consistency solution based on reliable messages
• (2), TCC transaction compensation solution
• (3), best-effort notification type

• (1), message sending Consistency
• (2), workarounds to ensure message consistency
• (3), routine MQ message processing procedures and features
• (4), message duplication Sending problems and idempotent design of business interfaces
• (5), local message service plan
• (6), independent message service plan
• (7), Design and Implementation of Message Service Subsystem /h1>
  • Transaction: A transaction is a reliable independent unit of work composed of a set of operations. The transaction has the characteristics of ACID, that is, atomicity, consistency, isolation, and durability.
  • Local transaction: When the transaction is managed locally by the resource manager, it is called a local transaction. The advantage of local transactions is that they support strict ACID features, are efficient and reliable, their state can be maintained only in the resource manager, and the application programming model is simple. However, local transactions do not have the ability to process distributed transactions, and the smallest unit of isolation is limited by the resource manager.
  • Global transaction: When a transaction is globally managed by the global transaction manager, it becomes a global transaction. The transaction manager is responsible for managing the global transaction status and participating resources, and the consistent commit and rollback of the collaborative resources.
  • TX protocol: the interface between application or application server and transaction manager.
  • XA protocol: the interface between the global transaction manager and the resource manager. XA is a distributed transaction specification proposed by the X/Open organization. The specification mainly defines the interface between the global transaction manager and the local resource manager. The mainstream database products all implement the XA interface. The XA interface is a two-way system interface that acts as a communication bridge between the transaction manager and multiple resource managers. The reason why XA is needed is that in a distributed system, theoretically speaking, two machines cannot achieve a consistent state, so a single point is introduced for coordination. The transactions managed and coordinated by the global transaction manager can span multiple resources and processes. The global transaction manager generally uses the XA two-phase protocol to interact with the database.
  • AP: Application program, which can be understood as a program that uses DTP (Data Tools Platform).
  • RM: Resource manager, here can be a DBMS or message server management system, the application program controls the resource through the resource manager, and the resource must implement the interface defined by XA. The resource manager is responsible for controlling and managing the actual resources.
  • TM: Transaction manager, responsible for coordinating and managing affairs, providing AP programming interface and managing resource manager. The transaction manager controls the global transaction, manages the life cycle of the transaction, and coordinates resources.
  • Two-phase commit protocol: XA is a mechanism used to coordinate multiple resources in a global transaction. A two-phase submission scheme is adopted between TM and RM to solve the consistency problem. Two-node submission requires a coordinator (TM) to control the operation results of all participant (RM) nodes and direct these nodes whether they need to be submitted finally. The limitations of the two-phase commit are the cost of the agreement, the persistent cost of the preparation phase, the persistent cost of the global transaction state, and the vulnerability caused by multiple potential failure points. After preparation, the failure before the commit causes a series of isolation and recovery problems.
  • BASE theory: BA refers to basic business availability, support for partition failures, S means flexible state, which means that it is not synchronized in a short period of time, E means final consistency, and the data is ultimately consistent, but real-time Is inconsistent. Atomicity and durability must be fundamentally guaranteed. For the needs of availability, performance, and service degradation, there are only requirements for reducing consistency and isolation.
  • CAP theorem: For a shared data system, you can only have at most two of the CAPs at the same time, and any two of them have their own adaptation scenarios. Real business systems are usually a mixture of ACID and CAP. The most important thing in a distributed system is to meet business needs, not to pursue highly abstract and absolute system characteristics. C means consistency, that is, all users see the same data. A means availability, which means that a usable copy of the data can always be found. P stands for partition fault tolerance and can tolerate failures such as network interruptions.
  • Service mode in flexible transaction:
    1. Queryable operation: Service operation has a globally unique identifier, and the operation has a uniquely determined time.
    2. Idempotent operation: The business result produced by repeated calls is the same as the result produced by one call. One is to achieve idempotence through business operations, and the other is that the system caches all requests and processing results, and finally, after detecting repeated requests, it automatically returns the previous processing results.
    3. TCC operation: Try stage, try to execute business, complete all business checks, achieve consistency; reserve necessary business resources to achieve quasi-isolation. Confirm phase: The business is actually executed without any checks. Only the business resources reserved in the Try phase are used. The Confirm operation must also satisfy idempotence. Cancel phase: Cancel the execution of the business, release the business resources reserved in the Try phase, and the Cancel operation must satisfy idempotence. The difference between TCC and 2PC (two-phase submission) protocol: TCC is located at the business service layer instead of the resource layer. TCC does not have a separate preparation phase. The Try operation has both resource operation and preparation capabilities. The Try operation in TCC can flexibly select business resources and lock granularity. The development cost of TCC is higher than that of 2PC. In fact, TCC is also a two-stage operation, but TCC is not equivalent to 2PC operation.
    4. Compensable operation: Do stage: The actual business processing is performed, and the business processing results are externally visible. Compensate stage: offset or partially cancel the business result of the forward business operation, and the compensation operation satisfies the idempotence. Constraints: The compensation operation is feasible in the business, and the risks and costs caused by the unisolated business execution results or incomplete compensation are controllable. In fact, the Confirm and Cancel operations of TCC can be regarded as compensation operations.

  Two, Flexible Transaction Solution Architecture

  In the field of e-commerce In other Internet scenarios, traditional transactions have exposed bottlenecks in database performance and processing capabilities. Flexible transactions have two characteristics: basic availability and flexible status. The so-called basic availability means that when a distributed system fails, a part of the availability is allowed to be lost. Flexible state refers to allowing the system to have an intermediate state, which will not affect the overall availability of the system, such as the master-slave synchronization delay of the database read and write separation. The consistency of flexible transactions refers to the final consistency.

  (1) An overview of the eventual consistency scheme based on reliable messages

  

  • Realization: The business processing service sends a real-time message before the business transaction is submitted The service requests to send a message, and the real-time message service only records the message data, not the actual sending. After the business transaction is submitted, the business processing service confirms the delivery to the real-time message service. The real-time message service will only be sent after receiving the confirmation sending instruction.
  • Message: The business processing service cancels sending to the real-time message service after the business transaction is rolled back. The message sending status confirmation system regularly finds unconfirmed or rolled back messages, and asks the business processing service for the message status, and the business processing service confirms whether the message is valid according to the message ID or message content. The processing result of the passive party does not affect the processing result of the active party, and the message processing operation of the passive party is an idempotent operation.
  • Cost: The cost of building a reliable message system. One message sending requires two requests, and the business processing service needs to implement the message status back-check interface.
  • Advantages: independent storage of message data, independent scaling, reducing the coupling between the business system and the message system. It is highly sensitive to the final consistency time and reduces the implementation cost of the passive side of the business. Compatible with all MQ middleware that implement the JMS standard, and ensure the ultimate consistency of the business under the premise of reliable business data. Ideally, it is quasi-real-time consistency.

  (two), TCC transaction compensation plan

  

  • Realization: A complete business activity consists of a main business serving several slave business services. The main business service is responsible for initiating and completing the entire business activity. Provide TCC-type business operations from business services. The business activity manager controls the consistency of the business activity. It registers the operation of the business activity and confirms the Confirm operation of all TCC-type operations when the business activity is submitted, and calls the Cancel operation of all the TCC-type operations when the business activity is cancelled.
  • Cost: The cost of implementing TCC operations is high, and the execution cost of Confirm and Cancel operations at the end of the business activity. Log costs of business activities.
  • Scope of use: strong isolation, business activities with strict consistency requirements. It is suitable for businesses with a short execution time, such as processing accounts or charging, etc.
  • Features: It is not coupled with a specific service framework, and is located at the business service layer instead of the resource layer. It can flexibly select the locking granularity of business resources. The operation of each service resource in TCC is a local transaction, the data is locked for a short time, and the scalability is good. It can be said that it is designed for independent deployment of SOA services.

  (three), best-effort notification type

  

  • Realization: The active party of the business activity sends a message to the passive party of the business activity after the completion of the processing, allowing the message to be lost. The passive party of the business activity queries the active party of the business activity according to the timing strategy, and restores the lost business message.
  • Restriction: The processing result of the passive party does not affect the processing result of the active party.
  • Cost: the construction cost of the business query and proofreading system.
  • Scope of use: Low sensitivity to the eventual consistency of the business. Cross-enterprise business activities.
  • Feature: After the active party of the business activity completes the business processing, it sends a notification message to the passive party of the business activity. The proactive party can set time ladder notification rules, repeat the notification according to the rules after the notification fails, and no longer notify after knowing the notification N times. The active party provides a proofreading query interface for the passive party to proofread and query on demand, and the user recovers the lost business messages.
  • Applicable scope: Bank notice, merchant notice.

  Three. Detailed Explanation of the Final Consistency Scheme Based on Reliable Messages

  (1). Message sending consistency

  The core role of message middleware in distributed systems is asynchronous communication, application decoupling and concurrent buffering (also known as traffic peaking). In a distributed environment, the need to communicate through the network introduces the uncertainty of data transmission, which is the partition fault tolerance in the CAP theory.

  

  The consistency of message sending is Means that the business action that generates the message is consistent with the message sending, that is, if the business operation is successful, the message generated by this business operation must be sent out, otherwise it will be lost.

  Processing method one

  public void completeOrderService() {// order processing order.process(); // send accounting original Voucher message pipe.sendAccountingVouchetMessage();}

  In the above case, if the business operation is successful, the application fails before the executed message is sent, and the message cannot be sent, resulting in the loss of the message, and an order system will be generated Inconsistent with the data of the accounting system. If the message system or network is abnormal, the message will not be sent out, and the data will be inconsistent.

  Processing method two

  public void completeOrderService() {// Send accounting original voucher message pipe.sendAccountingVouchetMessage(); // Order processing order.process();}

  If the order of the above two operations is reversed, this situation will become even more uncontrollable. The business order may fail if the message is sent, which will cause the order The data of the system and the business system are inconsistent. So can the XA protocol in the JMS standard guarantee the consistency of sending?

  • In the JMS protocol standard API, there are many interfaces beginning with XA, which are actually the global transactional interfaces that support the XA protocol (based on the two-phase commit protocol) mentioned earlier.

    XAConnection.classXAConnectionFactory.classXAQueueConnection.classXAQueueConnectionFactory.classXASession.classXATopicConnection.classXATopicConnectionFactory.classXATopicSession.class

  • The XA series interface in JMS can provide distribution Support for style transactions. However, the use of distributed transactions in the XA mode will bring many limitations.
    1. The resources required for business operations must support the XA protocol, but not all resources support the XA protocol.
    2. The cost of a two-phase submission agreement.
    3. DTP model limitations such as persistence cost, such as global locking, high cost, and low performance.
    4. Using the XA protocol violates the original intention of flexible transactions.

  (two) workarounds to ensure message consistency

  

  1. Send message: The active party now sends the message to the application Message middleware, the message status is marked as “to be confirmed” status.
  2. After receiving the message, the message middleware persists the message in the message storage, but does not affect the delivery of the message by the passive party.
  3. The message middleware returns the message persistence result, and the active party judges how to process the business operation according to the returned result:
     1. Failure: Abandon the execution of the business operation process, end, if necessary, to the upper level Return the processing result.
     2. Success: Perform business operation processing.
  4. After the business operation is completed, the result of the business operation is returned to the message middleware.
  5. After the message middleware receives the business operation structure, it processes it according to the business result:
     1. Failure: Delete the message in the message store, and end.
     2. Success: Update the message status in the message store to “to be sent”, and then perform message delivery.
  6. After the previous positive processes are successful, deliver messages to the passive application.

  However, in the above processing flow, there may be problems in any link.

  (three), conventional MQ message processing procedures and characteristics

  

  • The conventional MQ queue processing process cannot achieve message consistency.
  • The essence of message delivery is message consumption, which can be refined.

  (four), message repeated sending problem and idempotent design of business interface

  < img alt="Share a picture" src="/wp-content/uploads/images/architecture/system-architecture/1626815418808.png" >

  For unconfirmed messages, repost according to the rules To process. For the above process, repeated sending of messages will cause repeated calls to the business processing interface. The main reason for repeated message sending in the message consumption process is that after the consumer successfully receives and processes the message, the message middleware fails to update the delivery status in time. If the message is allowed to be sent repeatedly, then the consumer should implement the idempotent design of the business interface.

  (five), local message service plan

  

  • Implementation ideas:
    1. The active party application system completes business data operations through business operations, and is ready to send messages Store one copy of the message in the active application system, and send the other copy to the real-time messaging service
    2. The passive application system monitors the messages in the real-time message system, and when the passive party completes the message processing, it calls the active interface Complete message confirmation
    3. The active party deletes the message data after receiving the message confirmation.
    4. Resend the message through the message recovery system if no ACK confirmation message is returned within the specified time after the message is received by the message query service.
  • Advantages:
    1. The timeliness of the message is relatively high
    2. From the perspective of application design, the reliability of message data is realized. The reliability of data does not depend on the MQ middleware, which weakens the dependence on the characteristics of the MQ middleware.
    3. The solution is lightweight and easy to implement.
  • Disadvantages:
    1. Binding to specific business scenarios, strong coupling, and cannot be shared.
    2. Message data is synchronized with business data, occupying business system resources.
    3. When the business system uses the relational database, the message service performance will be limited by the concurrency performance of the relational database.

  (6), Independent message service plan

  

  • Implementation ideas:
    1. Pre-sent message: Active party application The system pre-sends the message, and the message service subsystem stores the message. If the storage fails, business operations cannot be performed. If the return storage is successful, then perform the business operation.
    2. Execute business operation: If the execution of the business operation is successful, the status of the successful execution of the business operation is sent to the message service subsystem. The message service subsystem modifies the message’s identity to the “sendable” state.
    3. Send a message to the real-time message service: When the status of the message changes, the message is immediately sent to the real-time message service. Next, the message will be monitored by the consumer of the message service and then consumed.
    4. Message status subsystem: equivalent to a timed task system. In the message service subsystem, the message that confirms the timeout is regularly searched, and the active party application system is also regularly searched for tasks that have not been processed successfully, and corresponding handle.
    5. Message consumption: When a message is consumed, an ACK is sent to the real-time message service, and then the real-time message service deletes the message. At the same time, the message service subsystem is called to modify the message to the “consumed” state.
    6. Message recovery subsystem: When the consumer returns a message, the message is not confirmed in time due to network interruption and other reasons, then the message recovery subsystem needs to periodically find out the unconfirmed messages in the message service subsystem information. Put unconfirmed messages into the real-time message service and redo, because the interface of the passive application system is idempotent.
  • Advantages:
    1. The message service is deployed independently, maintained independently, and scaled independently.
    2. The message storage can be integrated and realized by selecting different databases as needed.
    3. Message services can be used in the same usage scenarios, reducing the cost of repeated construction services.
    4. From the perspective of distributed service application design and development, the reliability of message data is realized. The reliability of message data does not depend on MQ middleware, which weakens the dependence on the characteristics of MQ middleware.
    5. The coupling between the business system and the message system is reduced, which is conducive to the expansion and maintenance of the system.
  • Disadvantages:
    1. A message sending requires two requests.
    2. The active party application system needs to implement the verification and query interface of the business operation status.

  (VII), Message Service Subsystem Design and Implementation

  Example Message data table:

  < /tr>

  td>

  td>

  < /tr>

  Name	Data type	Allow null	Default value	Attribute	Interpretation
  uuid	varchar(50)	No	—	unique	UUID
  version	int(11)	No	0	—	Version number
  editer	varchar(100)	Yes	NULL	—	Editor
  creater	varchar(100)	Yes	NULL	—	Creator
  edit_time	datetime	Yes	0000-00-00 00:00:00	—	Last modified time
  create_tim e	datetime	No	0000-00-00 00:00:00	—	Create Time
  msg_id	varchar( 50)	No	—	—	Message ID
  msg_body	longtext	No	—	—	Message content
  msg_date_type	varchar(50)	Yes	—	—	Message data type
  consumer_queue	varchar(100)	No	—	—	Consumption queue
  send_times	int(6)	No	0	—	Number of message retransmissions
  is_dead	varchar(20)	No	—	—	Is it dead
  status	varchar(20)	No	—	—	Status
  remark	varchar(200)	Yes	—	—	Remarks
  field0	varchar(200)	Yes	—	—	Extended field 0
  field1	varchar(200)	Yes	—	—	Extension Field 1
  field2	varchar (200)	Yes	—	—	Extension field 2

  Contents

  • First, the prelude to distributed transactions
  • Second, flexible transaction solutions Architecture
    • (1), an overview of the eventual consistency solution based on reliable messages
    • (2), TCC transaction compensation solution
    • (3), best-effort notification Type
  • 3. Detailed explanation of the final consistency scheme based on reliable messages
    • (1), message sending consistency
    • (2 ), workarounds to ensure message consistency
    • (3), conventional MQ message processing flow and characteristics
    • (4), message repeated sending problem and business interface idempotence design
    • (3) li>
    • (5), local message service plan
    • (6), independent message service plan
    • (7) Design and implementation of message service subsystem
  • 1. Distribution Prelude to the type of transaction
  • 2. Flexible transaction solution architecture
    • (1). Overview of the eventual consistency program based on reliable messages
    • (2), TCC transaction compensation Type scheme
    • (3), best-effort notification type
  • 3. Detailed explanation of the final consistency scheme based on reliable information
    • ( One), message sending consistency
    • (2), workarounds to ensure message consistency
    • (3), conventional MQ message processing procedures and features
    • ( Four) Repeated message sending problem and idempotent design of business interface
    • (5), local message service plan
    • (6), independent message service plan
    • (7) Design and implementation of message service subsystem