http://blog.csdn.net/bluishglc/article/details/7612811
Author: Xie Zhaodong
Link : http://www .zhihu.com/question/29483490/answer/107142534
Source: Zhihu For
example , the transaction compensation mechanism: that is, any forward transaction operation in the transaction chain must have a reversible transaction that fully complies with the rollback rules.
Or two-phase commit, three-phase commit: Distributed Transaction Service (DTS) Alipay's DTS implementation! Recently I also saw a tcc solution GitHub - changmingxie/tcc-transaction: tcc-transaction is a TCC-type transaction java implementation that has not been tried online
or has used the message system (reproduced from the public account of the high-availability architecture)
Classic solution - eBay mode
This solution The core is to execute tasks that require distributed processing asynchronously by means of message logs. Message logs can be stored in local text, databases or message queues, and retry can be automatically or manually initiated by business rules. Manual retry is more used in payment scenarios, and the reconciliation system is used to deal with post-event problems.
The core of the message logging scheme is to ensure the idempotency of the service interface.
Considering the reasons such as network communication failure and data packet loss, if the interface cannot guarantee idempotency, the uniqueness of data will be difficult to guarantee.
The main idea of the eBay way is as follows.
Base: An Alternative to Acid
This solution is an article published by eBay architect Dan Pritchett to ACM in 2008. It is a classic article explaining the BASE principle, or eventual consistency. The paper discusses the basic differences between BASE and ACID principles in ensuring data consistency.
If ACID provides a consistent choice for a partitioned database, how can availability be achieved? The answer is
BASE (basically available, soft state, eventually consistent)
BASE's availability is achieved by supporting local failures rather than system-wide failures. Here's a simple example: If users are partitioned across 5 database servers, the BASE design encourages similar handling, and a failure of one user database affects only 20% of users on that particular host. There's no magic involved here, but it does lead to higher perceived system availability.
The article describes one of the most common scenarios. If a transaction is generated, it is necessary to add records in the transaction table and modify the amount in the user table. These two tables belong to different remote services, so the issue of distributed transaction consistency is involved.
A classic solution is proposed in this paper, and the main modification operation and the message of updating the user table are completed in a local transaction. At the same time, in order to avoid the problem of repeated consumption of user table messages and achieve the idempotency of multiple retries, an update record table updates_applied is added to record the processed messages.
The pseudo code of the system is as follows
Based on above method, in the first stage, transaction table and message queue are added through the transaction guarantee of the local database.
In the second stage, read the message queue separately (but not delete it), and check whether the relevant records are executed by judging the update record table updates_applied. The unexecuted records will modify the user table, and then add an operation record to updates_applied, and the transaction will be executed. After success, delete the queue.
Through the above methods, the eventual consistency of the distributed system is achieved. To learn more about eBay's solution, please refer to the link at the end of the article.
Or integrated at the business level, the way it integrates into local affairs.
Dubbo distributed transactions
http://javatar.iteye.com/blog/981787
http://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and- without-xa.html