Microservice architecture design pattern-(8) SAGA

saga (a message-driven sequence of local transactions)

2PC

• Reference: https://zhuanlan.zhihu.com/p/35616810
  • The coordinator asks the participants if they can execute normally
    • Participant executes transaction but does not commit
  • The coordinator initiates a notification (commit or rollback) based on the result
• shortcoming
  • synchronous blocking
    • During this phase of the transaction, resources are locked.
  • single point of failure
    • Coordinator failure, participants blocked
      • Especially in the second stage, everyone is waiting for you to send a message.
  • Data is inconsistent
    • If the participant does not receive the notification in the second step, the data will be inconsistent.
  • unsolvable problem
    • In the second stage, the coordinator goes down after issuing the commit, and the only machine that receives the commit goes down. Then no one knows how this transaction is executed.

3PC

• step
  • can commit
    • The coordinator asks if it can be executed
  • pre commit
    • Coordinator sends pre-execution
  • do commit
    • The coordinator sends a commit or interrupt
• Differences from 2PC
  • If in phase 3, the participant does not receive the message, after the timeout, submit
  • can commit, does not lock resources, and reduces possible resource waste

SAGA

• The execution of transactions is distributed among several services
• serial execution
  • three parts
    • compensable matters
      • The transaction after it fails and it needs to be rolled back, but it has already been committed, so it needs to compensate when subsequent tasks fail.
        • One of the compensation methods: For example, when creating an order, set a status to indicate the order status. During the creation process, a new order was inserted with a status of creating, but subsequent verification failed. The compensatory action is to set the status to reject.
          • This state is called semantic lock. Indicates that it has been submitted but may be subject to change
          • Of course, at the end of the transaction, the status needs to be changed to approve.
    • critical matters
      • followed by transactions that cannot fail
        • After this is successful, subsequent transactions must be successful.
    • repeatable transactions
      • Always succeeds. If it doesn't succeed, try again until it succeeds
        • For example, change the order status to approve. Just modify the value of a field?

collaborative saga

• The logic and execution sequence of the saga are written to the participating services
  • If the execution order is A ->B -> C
    • After A is executed successfully, publish the message
    • B receives the message from A and executes
    • C receives the message from B and executes
• benefit
  • Simple
• question
  • There may be circular dependencies
  • rather difficult to understand
    • It is difficult to see which services are involved in this transaction
  • Risk of tight coupling
    • The transaction executed by B may be affected by many events, so it must pay attention to multiple message events of A

choreographed saga

• There is an orchestrator class that tells the participants what to do
• Good approach to orchestrator modeling
  • state machine
    • A set of states and a set of state transitions triggered by events
• benefit
  • simple dependency
    • Does not introduce circular dependencies
    • Orchestrator dependent parties
    • Participants do not rely on the orchestrator
  • Less coupling
    • Participants only provide service APIs and do not care about published events.
      • I am providing services, if you want to use them, just call me. I don't care about your situation (posted event)
  • Isolate concerns and simplify business logic
    • Participants only need to relate to their own business
    • The orchestrator only needs to worry about state transitions
• Disadvantages
  • The orchestrator may have too much business logic
• question
  • During the execution of saga, if data is read/modified, data inconsistency may be exposed. What should I do?
    • It’s a matter of transaction isolation
    • Solution
      • semantic lock
        • For example, the creation status of the order
      • Reasonably arrange the order of execution
      • reread value
        • Function: Prevent lost updates
        • Method: Before updating, read the data and verify whether any modifications have been made
          • Read the main library