Database Library sub-table (sharding) series (iv) transaction processing of multiple data sources

After the sharding transformation of the system, the original single database will become multiple databases, how to ensure the simultaneous operation of multi-data source atomicity and consistency is a problem that has to be considered. Overall, there are currently three ways to transact transactions for a distributed system: Distributed transactions, transaction based on best efforts 1PC, and transaction compensation mechanisms. We analyze each of the three treatments below. This text link: http://blog.csdn.net/bluishglc/article/details/7793172 reprint please specify the source!

Distributed transactions

This is the most widely known multi-data source transaction mechanism. This article does not intend to introduce too many distributed transactions, readers can refer to this article: on distributed transactions, two-phase commit, one-phase commit, best efforts 1PC model and transaction compensation mechanism. Here you only want to analyze the pros and cons of distributed transactions.

Advantage:

1. Based on the two-phase commit, the "atomicity" of cross-database operation is guaranteed, which is the most rigorous method of transaction implementation under distributed System.
2. Simple implementation, small workload. Because most application servers and some independent distributed transaction coordinators do a lot of encapsulation work, the difficulty and effort of introducing distributed transactions in a project are largely negligible.

Disadvantage:

The

system "horizontal" telescopic rival. Distributed transactions that are based on two-phase commits need to be reconciled between multiple nodes when committing a transaction, delaying the time to commit the transaction to a maximum, and objectively prolonging the execution time of the transaction, which causes the transaction to increase the probability of conflict and deadlock when accessing the shared resource, and with the increase of the database nodes, This trend will become more and more serious, thus becoming the "shackles" of the system scaling horizontally at the database level, which is the main reason that many sharding systems do not adopt distributed transactions.

Transaction based on best efforts 1PC mode

Unlike the two-phase commit of a distributed transaction, the best efforts 1PC model uses a one-stage commit, sacrificing the security of the transaction in some special cases (when the machine, the network is interrupted, etc.), but gains good performance, especially the fatters cool for horizontal scaling. Distributed transactions in Spring, the with and without XA article describes the best efforts 1PC mode The demo code provided here is a direct example of a multi-data source transaction management that implements a one-phase commit in a spring environment. Note, however, that the original example is based on the version prior to 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 use spring 3.0+, you need to refer to the implementation of SPRING-DATA-NEO4J. Given the performance benefits of the best efforts 1PC model and its relatively simple implementation, it is used by most sharding frameworks and projects.

Transaction compensation mechanism

For those with high performance requirements, but not high consistency requirements of the system, often not demanding system real-time consistency, as long as the final consistency within an allowable time period, which makes the transaction compensation mechanism a feasible solution. The transaction compensation mechanism is initially proposed in the process of "long transaction", but it is very useful for the distributed system to ensure the consistency. In general, unlike transactions that roll back immediately after an error occurs in execution, transaction compensation is a measure of post-mortem and remediation, and it is only expected that a final consistent result will be obtained within an allowable time period. The implementation of transaction compensation is closely related to the system business, and there is no standard processing method. Some common implementations are: reconciliation of data, comparison of 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 the system horizontal scaling, most of the time is the most suitable choice; transaction compensation mechanism can only be applied to the system with low transactional requirements, allowing the data to be "finally consistent", sacrificing real-time consistency and maximizing performance return.

Database Library sub-table (sharding) series (iv) transaction processing of multiple data sources