Brief
Distributed transaction refers to an operation of a transaction are on different nodes, it is necessary to ensure that the transaction AICD characteristics.
For example, the next one scene, inventory and order, if not on the same node, involving distributed transactions.
solution
In distributed systems, to achieve a distributed transaction, nothing less than that several solutions.
First, the two-phase commit (2PC)
Two-phase commit (Two-phase Commit, 2PC), to coordinate the participants' behavior by introducing Coordinator (Coordinator), the participants and the final decision whether to actually execute the transaction.
1. Run process
1.1 Preparation stage
Coordinator asked whether participants in a transaction executed successfully, the participants sent back the results of the transaction.
1.2 commit phase
If the transaction is executed successfully, a transaction coordinator sends a notification so that participants commit the transaction on each participant; otherwise, the coordinator sends a notification to let participants roll back the transaction.
It should be noted that, in the preparation stage, the participants performed the transaction but not yet committed. Only after receiving the notification sent by the coordinator during the commit phase, only be committed or rolled back.
2. Problems
2.1 synchronous blocking all transaction participants while waiting for the response of the other participants are in synchronous blocking state can not perform other operations.
2.2 single-point problem coordinator plays a very large role in the 2PC, the failure will cause a great impact. Especially in Phase II fails, all participants will wait state and can not perform other operations.
2.3 two stage data inconsistency, if the coordinator to send only part Commit message, then network abnormality occurs, only some of the participants receiving the Commit message, meaning that only a partial participant submitted the transaction, such that the system data inconsistencies.
2.4 too conservative any node failure will cause the entire transaction fails, there is no complete fault tolerance.
Second, the compensation transaction (TCC)
TCC compensation mechanism is actually used, the core idea is: for each operation, should a registration confirmation and the compensation corresponding (undo) action. It is divided into three stages:
- Try to do the main stage testing and resource reservation system for business
- When Confirm stage is mainly to make sure to submit business systems, Try successful execution stage and begin to implement Confirm phase, phase default Confirm will not go wrong. That is: as long as Try successful, Confirm with some success.
- The main stage is the implementation of mistake Cancel in the business, performed under the need to roll back the status of the service canceled, releasing reserved resources.
For example, the fake Bob Smith would like to transfer, probably thinking: We have a local method, which in turn calls
- Try the first stage, the first call to a remote interface and Bob Smith of money to freeze up.
- In the Confirm phase, the transfer of operations to perform remote calls, transfer successful thaw.
- If step 2 is successful, then the transfer is successful, if the second step fails, then call the remote interface corresponds to the freeze thaw method (Cancel).
Advantages: compared with 2PC, and the process is relatively simple to achieve some, but the consistency of the data should be worse than some of 2PC
Disadvantages: quite obvious shortcomings, are likely to fail in step 3. TCC is a form of compensation application layer, so programmers need to write a lot of code in the realization of compensation, in some scenarios, a number of business processes may not be well defined and treated with TCC.
Third, local message table (asynchronous ensure)
Local service data message table and a table in the same database, so that we can use the local transaction to ensure that the transaction satisfies the operating characteristics of the two tables, and uses the message queue to ensure that the final consistency.
- After the completion of the write operation of business data in one of a distributed transaction operations of the message to send a message to the local table, the local transaction to ensure that this message will be written to the local message table.
- After the local message table message to Kafka and other message queue, if the message is successfully forwarded the message is deleted from the local list, or continue forward again.
- In the operation of the other distributed transaction reads a message from the message queue, and performs an operation message.
Pros: a very classic implementation, avoiding the distributed transaction to achieve eventual consistency.
Disadvantages: message table would be coupled to a business system, if there is no good solution package, there will be many chores need to be addressed.
Four, MQ transactional messages
有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。
以阿里的 RocketMQ 中间件为例，其思路大致为：
第一阶段Prepared消息，会拿到消息的地址。第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
优点： 实现了最终一致性，不需要依赖本地数据库事务。
缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。
总结
通过本文我们总结并对比了几种分布式分解方案的优缺点，分布式事务本身是一个技术难题，是没有一种完美的方案应对所有场景的，具体还是要根据业务场景去抉择吧。笔者上家公司是试用阿里RocketMQ去实现的分布式事务，现在也有除了很多分布式事务的协调器，比如LCN等，大家可以多去尝试。