Distributed Transactions
Distributed transactions, two common processing methods are two-stage commit and compensation.
The typical two-stage submission is XA. There is a transaction coordinator that tells everyone that they are ready to submit, everyone responds, and they are all ready, and then the coordinator tells everyone to submit together, and everyone submits.
Compensation is easy to understand. First, process the business, and then check whether the state is consistent in timing or callback. If it is inconsistent, adopt a certain strategy and force the state to a certain end state (usually a failure state), and then the world will be at peace. Typical is the flushing operation.
For example, for databases, there are redo logs. If a database is down at this time, when it restarts, it will perform the check first, and will also submit the last operations. Therefore, the data at each point is consistent.
Use message queues to avoid distributed transactions
If you look closely at life, many scenarios of life have given us hints.
For example, after ordering the fried liver and paying for it at the famous Yaoji fried liver in Beijing, they will not give you the fried liver you ordered directly, but give you a small ticket, and then let you take the small ticket. Queue in the shipping area to pick it up. Why would they separate payment and pickup? There are many reasons, one of which is a very important reason to enhance their reception capacity (higher concurrency).
Back to our question, as long as this receipt is there, you can finally get the fried liver. The same is true for the transfer service. When the Alipay account deducts 10,000 yuan, we only need to generate a voucher (message), which reads "Let Yu'ebao account increase by 10,000 yuan", as long as this voucher (message) If it can be saved reliably, we can finally use this certificate (message) to increase the Yu’ebao account by 10,000, that is, we can rely on this certificate (message) to achieve eventual consistency.
"Distributed Transaction Processing in Large-Scale SOA Systems"
Distributed transactions, two common processing methods are two-stage commit and compensation.
The typical two-stage submission is XA. There is a transaction coordinator that tells everyone that they are ready to submit, everyone responds, and they are all ready, and then the coordinator tells everyone to submit together, and everyone submits.
Compensation is easy to understand. First, process the business, and then check whether the state is consistent in timing or callback. If it is inconsistent, adopt a certain strategy and force the state to a certain end state (usually a failure state), and then the world will be at peace. Typical is the flushing operation.
For example, for databases, there are redo logs. If a database is down at this time, when it restarts, it will perform the check first, and will also submit the last operations. Therefore, the data at each point is consistent.
Use message queues to avoid distributed transactions
If you look closely at life, many scenarios of life have given us hints.
For example, after ordering the fried liver and paying for it at the famous Yaoji fried liver in Beijing, they will not give you the fried liver you ordered directly, but give you a small ticket, and then let you take the small ticket. Queue in the shipping area to pick it up. Why would they separate payment and pickup? There are many reasons, one of which is a very important reason to enhance their reception capacity (higher concurrency).
Back to our question, as long as this receipt is there, you can finally get the fried liver. The same is true for the transfer service. When the Alipay account deducts 10,000 yuan, we only need to generate a voucher (message), which reads "Let Yu'ebao account increase by 10,000 yuan", as long as this voucher (message) If it can be saved reliably, we can finally use this certificate (message) to increase the Yu’ebao account by 10,000, that is, we can rely on this certificate (message) to achieve eventual consistency.
"Distributed Transaction Processing in Large-Scale SOA Systems"