After the system is reformed by Sharding, the original single database will become multiple databases, how to ensure the atomicity and consistency of simultaneous operation of multiple data sources is a problem that has to be considered. Overall, there are currently three ways of dealing with a distributed system: distributed transactions, best efforts 1PC-mode transactions, and transaction compensation mechanisms. We analyze each of the three approaches below. This text link: http://blog.csdn.net/bluishglc/article/details/7793172 reprint, please indicate the source.
Distributed Transactions
This is the most well-known multiple data source transaction processing mechanism. This article does not intend to introduce a lot of distributed transactions, readers can refer to this article: on distributed transactions, two-phase commit, one stage submission, best efforts 1PC mode and transaction compensation mechanism. Here you only want to analyze the pros and cons of distributed transactions.
Advantage:
1. Based on two-phase submission, the "atomicity" of cross database operation is guaranteed, which is the most stringent transaction implementation method under distributed system.
2. Simple to achieve, small workload. Because most application servers and some independent distributed transaction coordinators do a lot of encapsulation work, the difficulty and the workload of introducing distributed transaction in the project can be neglected basically.
Disadvantage:
System of "horizontal" telescopic rivals. Distributed transactions based on two-phase commit need to coordinate between multiple nodes when committing a transaction, minimizing the point at which the transaction is committed is an objective extension of the transaction's execution time, which results in a higher probability of conflicts and deadlocks in accessing shared resources, and as the number of database nodes increases, This trend will become more and more serious, thus becoming the system at the database level scale of the "shackles", which is the main reason many sharding systems do not use distributed transactions.
Best efforts 1PC-mode transactions
Unlike two-phase submissions for distributed transactions, the best efforts 1PC model uses a one-stage-side commit, sacrificing the security of a transaction under certain special circumstances (such as machine, network interruption, and so on), but with good performance, in particular the elimination of carry cool for horizontal scaling. Distributed transactions in Spring, with and without XA, describes the best efforts 1PC mode in detail. The demo code provided in this paper is a direct example of multiple data source transaction management for a phase commit in a spring environment. Note, however, that the original example is based on the previous version of Spring 3.0, and if you use Spring 3.0+, you get the following error:
java.lang.IllegalStateException:Cannot Activate transaction synchronization-already active, if you are using spring 3.0+, you need to refer to the implementation of SPRING-DATA-NEO4J. Given the performance advantages of best efforts 1PC mode, as well as the relatively simple implementation approach, it is used by most sharding frameworks and projects.
transaction compensation Mechanism
For those systems with high performance requirements but not high consistency requirements, the real-time consistency of the system is often not critical, as long as the final consistency can be achieved within a given time period, which makes the transaction compensation mechanism a feasible scheme. The transaction compensation mechanism was first proposed in the process of "long transaction", but it also has a good reference meaning for the distributed system to ensure the consistency. In general, unlike the way in which a transaction is rolled back immediately after an error in execution, transaction compensation is a measure of hindsight and remediation, and it only expects the result to be consistent within a permissible time period. The implementation of transaction compensation is closely related to the system business and does not have a standard processing method. Some common implementations are: reconciliation of data, alignment based on logs, regular synchronization with standard data sources, and so on.
Summary
Distributed transactions, the most stringent transaction implementation, but performance is a big problem; Best efforts 1PC mode, performance and transaction reliability balance, support system level scaling, most of the most appropriate choice; The transaction compensation mechanism can only be applied to systems where transactional requirements are not high enough to allow data to be "ultimately consistent", sacrificing real-time consistency and maximizing performance returns.
Related reading: Database Classification (sharding) series (v) a sharding expansion scheme that supports free planning without data migration and modification of routing codes Database sub- table (sharding) series (iv) Transaction processing database for multiple data sources (sharding) Series (iii) On the use of frameworks or autonomous development as well as sharding implementation Dimensions Database sub-table (sharding) series (ii) Global primary key generation policy Database sub-table ( sharding) Series (i) Split implementation policies and examples demonstrates the basic idea and segmentation strategy of the granularity database sharding of vertical splitting vertical sharding
