Outline
Due to the popularity of micro-services architecture, distributed communication exponentially increase, will inevitably bring about consistency, that is, before you encounter inconsistent probability may be 100 once a year, now may be once a year, or even a day times. Pre-service micro-architecture, most developers focus only on the split, selective ignoring consistency, performance, availability, tools, chain problems, leading struggling architecture, in which these issues, consistency is the most easily overlooked. Of course, the vast majority of the scene does not need such a high consistency, you can retry the failed strategy of using a simple process. From the current situation of the industry point of view, there are several ways to achieve the following:
- XA (2PC)
- Failure retry
- Reliable event
- Saga
- TCC
In fact, many programs have combined to do business, but to ensure that the transaction itself is a generic technology, engineers hope abstracted through a simple configuration, annotations can get, and will not significantly reduce performance.
Here we give the stars of tomorrow framework for the introduction of two open source distributed transaction.
Compared
Graduate
Fescar is distributed transaction middleware Alibaba open source technology and the accumulation of its internal TXC-based GTS. Although this framework is very active, but just 19 years of open source, the current 0.3 version, if used for larger production environment risks.
servicecomb-pack from Huawei micro-services framework servicecomb, servicecomb in Apache has graduated, but has been relatively "low key." Among well-known database Sharding-Sphere is the saga adopt programs servicecomb-pack offer.
The principle
fescar essence is actually a distributed transaction into multiple single database transaction.
Yes, this is thought of Saga, all of the forward operation, retains reverse operation. Once you want to roll back, you only need to perform the reverse operation on it.
, Based on the principle of business implementation more like, is added to the database in additional business in the event a table, this table is the key event in the normal course of business while updating the database, as shown within this program and in a single database transaction (with a database connection) synchronous update event table, so to ensure that data is not lost. We can look at the consistency of the requirements, "either at the same time succeed or fail at the same time." Single database transaction can be guaranteed.
As shown, business'm going to call Storage and order services, how to ensure that the transaction does? bussiness is the initiator of the transaction, also known as TM, Order, Storage is the executor of the transaction, is called service, also known as RM, TC is responsible for overall coordination, can generate global transaction ID, all invoked service is through this global the ability of the transaction ID in series. in addition, TC bear distributed lock, the lock is to solve the distributed write isolation, have to write to get the right lock, of course, TC must be highly available. Storage and Order when conducting business operations in addition to the normal data storage business, but also to achieve the updated event table in the same transaction, once the rollback of claims, which needs to generate SQL reverse operation according to the event table, and rollback.
servicecomb-pack and fescar, same thought saga, all the forward operation, retains reverse operation. Once you want to roll back, you only need to perform the reverse operation on it. But beyond that, servicecomb-pack also supports the TCC.
As shown, Omega as a client, intercept all transaction operations, business began to start recording record Alpha, Alpha end of the transaction records to the end of recording the transaction, if there are problems, generate reverse operation directly in the Alpha event table, you should He has been seen, and the difference is fescar, global coordinator in the event data storage table (alpha) on this side.
Two approaches have advantages and disadvantages of it, there is a business side there are actually invasive, non-invasive is not in an absolute sense, although a single database transaction performance is good, but all operations will affect the normal business event table, can not do better of isolation. There is relatively coordinator side isolation better, but there will be inconsistent probability, for example, in fact, business operations have been completed, the database update was successful, but may fail to write the event log, this time coordinator will I think business operations also failed.
stability
servicecomb-pack slightly better. Earlier project.
Isolation
fescar slightly better. Although not perfect, but has the solution. Distributed Lock Write fescar isolation provided by TC implemented, the read select for update implemented by isolation, of course, servicecomb-pack can also be achieved by isolation read select for update.
the complexity
servicecomb-pack slightly better. A small role, the idea is simple. The service side, the two frameworks can be realized by a simple annotation.
File
fescar slightly better.
performance
There is no actual test, In principle, almost the same.
Supported databases
fescar currently only supports mysql, servicecomb-pack program does not distinguish between databases.
More details can refer to the official documentation.
to sum up
Although the goal of the two frames are easier to make business developers, distributed transactions do not care about the issue, but in my opinion, if you want to use, or to find out principle, unless very sensitive issue, otherwise, should be cautious use, can do the best. Both frameworks are in rapid development, ideologically speaking from the implementation is very similar, is a very good solution, the future situation mainly depends on the degree of investment.
end: If you think this article helpful to you, remember to praise point forward, your support is my updated power.
Reproduced in: https: //www.jianshu.com/p/48bd39da2a93