# Distributed transaction in the mircoservice --- # Dealing with transactions in monolithic service ---- ## No need to worry It's a widespread problem while our services must deal with multiple requests parallelly and concurrently. We don’t need to handle it alone, thanks to **the ACID properties and isolation levels in RDBMS**. ---- ## ACID ![](https://i.imgur.com/gaEw1IP.png) https://www.geeksforgeeks.org/acid-properties-in-dbms/ ---- ## Isolation levels ![](https://i.imgur.com/d2rj7KX.png) https://www.geeksforgeeks.org/transaction-isolation-levels-dbms/?ref=lbp --- # Dealing with transactions in distributed(microservice) system ---- ## Hard question in the distributed(microservice) system There are many solutions to process a transaction in the distributed system, and **none is perfect**. We will meet many problems in a distributed system, e.g., **network failure/latency, clock issues, process pause, etc**. We need to consider the trade-off between each solution, but we can separate them into two scenarios. - Strong consistency (Synchronous) - Eventual consistency (Asynchronous) ---- ### Solutions in Strong consistency (Synchronous) - 2 phase commit (2pc) - 3 phase commit (3pc) - ... ---- ### Solutions in Eventual consistency (Asynchronous) Data inconsistent time range SAGA > 2 phase MSG > TCC > XA Short inconsistent window - XA - TCC(Try, Confirm, Cancel) Long inconsistent window - 2 phase MSG - SAGA --- ## Strong consistency We can still meet the properties of ACID in this situation. It will be a **synchronous** process since we want to have **strong consistency**. The most common reason we use these solutions is that **we have yet to migrate our full service to microservice**. It means we divide our data into different data stores and use the lock or the native solution in our storage. Of course, **you can still use these practices in a microservice architecture if your service must provide strong consistency**, but you must deal with the lock mechanism yourself. ---- ### 2 phase commit (2PC) 2 phase commit is a very common solution for distributed system. There is 2 phase (of cource) in this solution. 1. Can commit 2. Commit/Abort And two kinds of role in it. 1. Coordinator 2. Participant ---- ### 2 phase commit ![](https://i.imgur.com/DyB2GXq.png) ---- ### 2 phase commit failure The pain point of 2PC is the coordinator. The case is that we have three roles: Coordinator, A, B If the coordinator submits the commit request to A and A commits the request, but before B receives the request, the coordinator is down. It would be a problem because A finishes the transaction, but B does not. After this failure, it's hard to let the new coordinator who takes over the responsibility know which we need to start at which status. ![](https://i.imgur.com/siNVdwW.png) ---- ### 3 phase commit (3PC) 3 phase commit is the extension of 2PC, but more is needed to solve the pain point of 2PC. It’s still there, and we will discuss it later. It provides an additional phase and changes the term participant to cohorts. 1. Coordinator 2. Cohort Phases: 1. canCommit 2. preCommit 3. doCommit/Abort ---- ### 3 phase commit (3PC) ![](https://i.imgur.com/GFd8M1H.png) ---- #### Difference with 2PC As I mentioned, we know there is a failure about the coordinator failed in 2PC. 3PC provides the timeout mechanism and one additional phase to let the took-over coordinator know which stage they are in now. --- ## Eventual consistency In this situation, we cannot meet the ACID properties so we down to **BASE (Basic availability, soft state and eventual consistency)** and we can **asychronously** process a transaction. ---- ### TTC (Try, Confirm, Cancel) ---- ### XA ---- ### SAGA --- ## Conclusion --- ## References - https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf - https://en.dtm.pub/practice/msg.html#success-process - https://dev.to/yedf2/how-to-implement-saga-pattern-in-microservices-2gj3?utm_source=dormosheio&utm_campaign=dormosheio - https://microservices.io/patterns/data/saga.html - https://chrisrichardson.net/post/sagas/2019/08/04/developing-sagas-part-2.html - https://chrisrichardson.net/post/sagas/2019/08/15/developing-sagas-part-3.html - https://www.lifewire.com/abandoning-acid-in-favor-of-base-1019674 - https://blog.csdn.net/L13763338360/article/details/106254840 --- ### Thank you! :sheep: <style> .reveal { font-size: 24px; } </style>
{"metaMigratedAt":"2023-06-17T14:15:45.206Z","metaMigratedFrom":"YAML","title":"Distributed transaction in the mircoservice","breaks":true,"description":"SAGA note","slideOptions":"{\"theme\":\"solarized\"}","contributors":"[{\"id\":\"661583cb-db49-43b5-b24d-5ae18d46764b\",\"add\":7308,\"del\":4999}]"}
    191 views