Microservice Patterns - Managing transactions with sagas - 4.3 Handling the lack of isolation

Reference


  • The isolation property of ACID transactions ensures that the outcome of executing multiple transactions concurrently is the same as if they were executed in some serial order
  • Isolation makes it a lot easier to write business logic that executes concurrently
  • The challenge with using sagas is that they lack the isolation property of ACID transactions.
  • Problem
    • other sagas can change the data accessed by the saga while it’s executing
    • other sagas can read its data before the saga has completed its updates, and consequently can be exposed to inconsistent data
  • saga to be ACD:
    • Atomicity—The saga implementation ensures that all transactions are executed or all changes are undone.
    • Consistency—Referential integrity within a service is handled by local databases. Referential integrity across services is handled by the services.
    • Durability—Handled by local databases.
  • Strategy to deal with the lack of isolation:  countermeasures

Overview of anomalies
  • Lost updates: Update a data and another Saga override the same data right away
  • Dirty reads: Read a data while another Saga update that data but not completed
  • Fuzzy/nonrepeatable reads: Different step of Saga read same data get different result because other saga has made update

Countermeasures for handling the lack of isolation
  • Semantic lock: application level lock
  • Commutative updates: Design update operations to be executable in any order
  • Pessimistic view: Reorder of saga steps to minimize business risk due to dirty read
  • Reread value: Reread data to verify it's unchanged before overwriting it
  • Version file: Record the update to a record so that they can be reordered. Ex. record the operations as they arrive and then execute them in the correct order
  • By value: Use request's business risk to dynamically to select the concurrency mechanism. Ex. transfer money, use distributed transaction. Simple status update, use Sagas.

THE STRUCTURE OF A SAGA

a saga consists of three types of transactions (One complete flow may have every kinds of transactions):
  • Compensatable transactions:  can potentially be rolled back. Ex. Delete a created Order
  • Pivot transaction:  The go/no-go point in a saga. Ex. verify before proceed, go or no-go after verify.
  • Retriable transactions: Follow pivot transaction but guarantee to succeed. Ex. Can retry when fail.



沒有留言:

張貼留言

別名演算法 Alias Method

 題目 每個伺服器支援不同的 TPM (transaction per minute) 當 request 來的時候, 系統需要馬上根據 TPM 的能力隨機找到一個適合的 server. 雖然稱為 "隨機", 但還是需要有 TPM 作為權重. 解法 別名演算法...