What is a transaction
Transaction (Transaction) and ACID properties
A transaction is a logic processing unit consisting of a set of SQL statements, a transaction with the following four attributes, commonly referred to as ACID properties of transactions:
- Atomicity (Atomicity): the transaction is an atomic operation unit which modification of data, either all executed or not executed full.
- Consistency (Consistent): at the start and completion of the transaction, the data must be consistent state. This means that all relevant data rules must be applied to modify the transaction, in order to maintain the integrity of the data; at the end of the transaction, all of the internal data structures (such as B-tree indexes or doubly linked list) must also be correct.
- Isolation (Isoation): database systems provide some isolation mechanism to ensure transaction concurrency "independent" environmental performance is not affected by external operations. This means that the intermediate state in the transaction process is not visible on the outside, and vice versa.
- Persistent (Durabe): After the transaction is complete, it is permanent modifications to the data, even if a system failure occurs can be maintained.
What is micro-services
In short, micro-services architecture is a single application as a methodology developed by small service, each application runs in its own process, and the lightweight mechanism (usually HTTP API resources ) to communicate. These services are built around business functions, and can be deployed independently by automatic deployment mechanism. Centralized management of these services are already the least, they can be written in different programming languages and use different data storage technologies.
Micro Advantage Service
- Will be split into multiple small complex business operations, each split into a service business, will simplify complex issues. Beneficial division of labor, reduce the cost of learning new people.
- Micro-services system is a distributed system, complete decoupling between the service and business, with the increase in traffic can be subdivided according to the service, with a strong ability to scale. Concurrent face out of the scene can be clustered service deployment, enhance system load capacity.
- Room service using HTTP protocol for communication between a completely independent service and service. Each service can select the appropriate programming languages and databases based on business scenarios.
- Each service is independent micro-services deployment, modification and deployment of each service has no effect on other services.
Micro-service landing problems
Although micro services are now in full swing, but its practice is actually still in the exploratory stage. Many small and medium sized Internet companies, in view of experience, technical strength and other issues, micro-service landing more difficult. Such as the famous architect Chris Richardson said, the main existing difficulties following aspects:
- After the split single application for distributed systems, communication mechanisms and troubleshooting measures between processes become more complex.
- After the system of micro-services, a seemingly simple function, may need to call multiple internal services and operations to achieve multiple databases, distributed transaction service invocation issues become very prominent.
- The large number of micro-services, its testing, deployment, and monitoring, has become more difficult.
With the maturity of RPC framework, the first issue has gradually been resolved. For example dubbo can support multiple communication protocols, springcloud can be very good support restful calls. For the third issue, with the introduction of docker, development devops technology as well as public cloud paas platform operation and maintenance of automation tools, micro-service testing, deployment and operation and maintenance will become increasingly easy.
As for the second question, there is no good solution to the General Scheme micro-transaction service problems arising. Distributed Transaction service has become an obstacle to the micro-landing largest and most challenging of a technical problem. In this paper, we explore the depth and under the micro-service architecture, solutions distributed transactions.
Distributed Transaction typical scenario: Bank Transfer Business
Bank transfer business, for example, typically includes the following three conditions:
The branch A. Transfer: Transfer the same branch of the same bank
transfers the line B.: extraordinary branch transfer within the same bank
C. inter-bank transfer: transfer systems different banks
For conventional centralized architecture, A is generally a local transaction, B may also be possible for the local transaction is a distributed transaction, C is distributed transaction.
After the micro-business transformation services, transfer, usually turn out different micro service, the same service is also a micro usually run on different copies. A can become a distributed transaction may also be circumvented by several methods, completed in local affairs. B and C is difficult to avoid, it can only be a distributed transaction.
For distributed transactions, micro-service best practices are usually recommended to avoid, but in many business scenarios can not be circumvented, such as the above B, C transfers scene, there is no good way to complete the two accounts in the local affairs of a micro services Data Update.
Distributed Transaction common solution
In order to solve the problem of distributed consistency, typical of many former summarizes the protocols and algorithms in terms of performance and consistency of data back and forth weigh process. The most commonly used is the two-stage commit protocol (2 Phase Commitment Protocol).
Two-phase commit scheme
XA transaction middleware and database through the interface specification, using two-phase commit to complete a global transaction, XA specification is the basis of two-phase commit protocol.
The first stage is the voting phase, all participants will present information on the transaction to the success of feedback sent to the coordinator; second stage is the implementation phase, the coordinator of feedback from all participants, notify all participants in unison All branch committed or rolled back.
Two-phase commit scheme is widely used, typical commercial software includes Oracle Tuxedo and IBM CICS. It has the advantage of less invasive business code, but the disadvantage is also obvious:
Poor performance: Due to the characteristics of XA protocol itself, it will result in a transaction not released resources for a long time, locked cycle is long, and can not intervene in the application layer on top of very poor performance.
Single-point problem: coordinator submission process plays an important role, once the coordinator where the server is down, it will affect the normal operation of the entire database cluster in the entire two-stage, such as in the second phase, if the coordinator due to a fault can not send a normal transaction commit or rollback notification, the participants were to remain blocked, the entire database cluster will not be able to provide services.
Synchronous blocking: two-phase commit process of implementation, all participants need to obey the unified coordinator, during a state of congestion can not be engaged in other operations, so its efficiency is low.
Therefore, the two-phase commit scheme is seldom used in the Internet project, many businesses can not meet the high concurrency requirements.
To compensate for this program to bring this low performance issues, we came up with a variety of solutions to, but without exception, are required by the application layer tricks, namely the invasion of the way business, such as very famous TCC program , there are many mature TCC based frameworks, such as Huawei DTM, ByteTCC, tcc-transaction, etc., and based on the final consistency to achieve reliable message.
TCC program
TCC in electricity providers, finance floor more. TCC program is actually an improved two-phase commit. Each branch which explicitly entire business logic into a Try, Confirm, Cancel three operations. Try to complete the business part of the preparatory work, confirm the completion of part of the business to submit, cancel part of the complete roll back the transaction. The basic principle as shown in FIG.
When a transaction begins, business applications will start a transaction registered with the transaction coordinator. After business applications will call all the services interface to try to complete a stage of preparation. After the transaction coordinator will return to the interface According try, decided to call to confirm or cancel the interface interface. If the interface call fails, it will retry.
TCC program allows application-defined database operations granularity themselves, so as to reduce lock conflict, it becomes possible to improve throughput, such as Huawei DTM Distributed Transaction high performance middleware, common configuration server can support global transactions 10,000 + TPS, a branch calculated Affairs 30,000 + TPS (Ali distributed transaction middleware also uses the latter calculation). Of course, TCC program also has shortcomings, concentrated in the following two aspects:
Strong invasive application. Each branch are required to implement the business logic of the try, confirm, cancel operation three, strong invasive applications, the high cost of renovation.
More difficult to achieve. Need to implement different strategies according to different causes rollback failed network status, system failure. In order to meet the requirements of consistency, confirm and cancel interface must implement idempotent.
Most of the above reasons TCC program was developed stronger, there is an urgent demand for large companies adopted. Lightweight micro-services advocacy services, and processing logic TCC program in many transactions need to be applied to achieve their own coding, complex and large development.
Consistency scheme based on the final message
Consistency message through the messaging middleware program is guaranteed downstream manipulate application data [consistency. The basic idea is the local operation and send messages in a transaction, to ensure that local operations and messages sent to either succeed or both fail. Downstream applications subscribe messaging system to the message, performs corresponding operations after receiving the message.
News program is essentially a distributed transaction will be converted to two local affairs, and then rely on downstream business retry mechanism to achieve eventual consistency. The final consistency of message-based program on invasive applications is also high, the application requires a lot of business transformation, cost is very high.
入侵代码的方案是基于现有情形“迫不得已”才推出的解决方案，实际上它们实现起来非常不优雅，比如TCC，一个事务的调用通常伴随而来的是对该事务接口增加一系列的反向操作，提交逻辑必然伴随着回滚的逻辑，这样的代码会使得项目非常臃肿，维护成本高。
针对上面所说的分布式事务解决方案的痛点，那很显然，我们理想的分布式事务解决方案肯定是性能要好而且要对业务无入侵，业务层上无需关心分布式事务机制的约束，也就是本文所重点推荐的非侵入事务，真正做到事务与业务分离。
非侵入事务方案
非侵入事务模式中，一个分布式事务称为一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务。
非侵入事务中间件包含三个组件：
Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager ™：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
其中，TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行。如下图所示：
简要说说整个全局事务的执行步骤：
- TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播；
- RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；
- TM 向 TC 发起全局提交或回滚；
- TC 调度该全局事务的所有分支事务完成提交或者回滚。
每天都会有更新看过的朋友可以点波关注，Java学习路线和优质资源评论或后台回复“Java”获取。
