TeslaCN commented on code in PR #19064: URL: https://github.com/apache/shardingsphere/pull/19064#discussion_r918745821
########## docs/document/content/features/transaction/_index.en.md: ########## @@ -7,77 +7,71 @@ chapter = true ## Background -Database transactions should satisfy the features of ACID (atomicity, consistency, isolation and durability). +Four properties of transactions: ACID （Atomicity、Consistency、Isolation、Durability). -- Atomicity guarantees that each transaction is treated as a single unit, which either succeeds completely, or fails completely; -- Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants; -- Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially; -- Durability guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or crash). +- Atomicity: transactions are executed as a whole, and either all or none is executed. +- Consistency: transactions should ensure that the state of data remains consistent after the transition. +- Isolation: when multiple transactions execute concurrently, the execution of one transaction should not affect the execution of others. +- Durability: when a transaction committed modifies data, the operation will be saved persistently. -In single data node, transactions are only restricted to the access and control of single database resources, called local transactions. -Almost all the mature relational databases have provided native support for local transactions. -But in distributed application situations based on micro-services, more and more of them require to include multiple accesses to services and the corresponding database resources in the same transaction. -As a result, distributed transactions appear. +Distributed transactions guarantee the ACID properties in distributed scenarios, where a single transaction involves operations on multiple data nodes. -Though the relational database has provided perfect native ACID support, it can become an obstacle to the system performance under distributed situations. -How to make databases satisfy ACID features under distributed situations or find a corresponding substitute solution, is the priority work of distributed transactions. +## Related Concepts -### Local Transaction +### XA Protocol -It means let each data node to manage their own transactions on the premise that any distributed transaction manager is not on. -They do not have any coordination and communication ability, or know other data nodes have succeeded or not. -Though without any consumption in performance, local transactions are not capable enough in high consistency and eventual consistency. +The original distributed transaction model of XA protocol is the "X/Open Distributed Transaction Processing (DTP)" model, XA protocol for short, which was proposed by the X/Open international consortium. -### 2PC Transaction +## How it works -The earliest distributed transaction model of XA standard is `X/Open Distributed Transaction Processing (DTP)` model brought up by `X/Open`, XA for short. +ShardingSphere provides begin/ commit/rollback traditional transaction interfaces externally, and provides distributed transaction capabilities through LOCAL, XA and BASE modes. -Distributed transaction based on XA standard has little intrusion to businesses. -Its biggest advantage is the transparency to users, who can use distributed transactions based on XA standard just as local transactions. -XA standard can strictly guarantee ACID features of transactions. +### LOCAL Transaction -That guarantee can be a double-edged sword. -It is more proper in the implementation of short transactions with fixed time, because it will lock all the resources needed during the implementation process. -For long transactions, data monopolization during its implementation will lead to an obvious concurrency performance recession for business systems depend on hot spot data. -Therefore, in high concurrency situations that take performance as the highest, distributed transaction based on XA standard is not the best choice. +LOCAL mode is implemented based on ShardingSphere's proxy database interfaces, that is begin/commit/rolllback. +For a logical SQL, ShardingSphere starts transactions on each proxied database with the begin directive, executes the actual SQL, and performs commit/rollback. +Since each data node manages its own transactions, there is no coordination and communication between them, and they do not know whether other data node transactions succeed or not. +There is no loss in performance, but strong consistency and final consistency cannot be guaranteed. -### BASE Transaction - -If we call transactions that satisfy ACID features as hard transactions, then transactions based on BASE features are called soft transactions. -BASE is the abbreviation of basically available, soft state and eventually consistent those there factors. +### XA Transanction -- Basically available feature means not all the participants of distributed transactions have to be online at the same time. -- Soft state feature permits some time delay in system renewal, which may not be noticed by users. -- Eventually consistent feature of systems is usually guaranteed by message availability. +XA transaction adopts the concepts including AP(application program), YM(transaction manager) and RM(resource manager) to ensure the strong consistency of distributed transactions. Those concepts are abstracted from [DTP mode](http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf) which is defined by X/OPEN group. +Among them, TM and RM use XA protocol to carry out both-way communication, which is realized through two-phase commit. +Compared to traditional local transactions, XA transaction adds a preparation stage where the database can also inform the caller whether the transaction can be committed, in addition to passively accepting commit instructions. +TM can collect the results of all branch transactions and make atomic commit at the end to ensure the strong consistency of transactions. -There is a high requirement for isolation in ACID transactions: all the resources must be locked during the transaction implementation process. -The concept of BASE transactions is uplifting mutex operation from resource level to business level through business logic. -Broaden the requirement for high consistency to exchange the rise in system throughput. + -Highly consistent transactions based on ACID and eventually consistent transactions based on BASE are not silver bullets, and they can only take the most effect in the most appropriate situations. -The detailed distinctions between them are illustrated in the following table to help developers to choose technically: +XA transaction is implemented based on the interface of ShardingSphere's proxy database xa start/end/prepare/commit/rollback/recover. -| | *Local transaction* | *2PC (3PC) transaction* | *BASE transaction* | -| ----------------------- | --------------------------------------- | :---------------------------------- | ----------------------------------- | -| Business transformation | None | None | Relevant interface | -| Consistency | Not support | Support | Eventual consistency | -| Isolation | Not support | Support | Business-side guarantee | -| Concurrency performance | No influence | Serious recession | Minor recession | -| Situation | Inconsistent operation at business side | Short transaction & low concurrency | Long transaction & high concurrency | +For a logical SQL, ShardingSphere starts transactions in each proxied database with the xa begin directive, integrates TM internally for coordinating branch transactions, and performs xa commit /rollback. +Distributed transactions based on XA protocol are more suitable for short transactions with fixed execution time because the required resources need to be locked during execution. +For long transactions, data exclusivity during the entire transaction will have an impact on performance in concurrent scenarios. -## Challenge +### BASE Transaction -For different application situations, developers need to reasonably weight the performance and the function between all kinds of distributed transactions. +If a transaction that implements ACID is called a rigid transaction, then a transaction based on a BASE transaction element is called a flexible transaction. +BASE stands for basic availability, soft state, and eventual consistency. -Highly consistent transactions do not have totally the same API and functions as soft transactions, and they cannot switch between each other freely and invisibly. -The choice between highly consistent transactions and soft transactions as early as development decision-making phase has sharply increased the design and development cost. +- Basically Available: ensure that distributed transaction parties are not necessarily online at the same time. +- Soft state: system status updates are allowed to have a certain delay, and the delay may not be recognized by customers. +- Eventually consistent: guarantee the eventual consistency of the system by means of messaging. -Highly consistent transactions based on XA is relatively easy to use, but is not good at dealing with long transaction and high concurrency situation of the Internet. -With a high access cost, soft transactions require developers to transform the application and realize resources lock and backward compensation. +ACID transaction puts a high demand for isolation, where all resources must be locked during the execution of transactions. +Flexible transaction is to move mutex operations from the resource level to the business level through business logic. +Reduce the requirement for strong consistency in exchange for higher system throughput. -## Goal +ACID-based strong consistency transactions and BASE-based final consistency transactions are not a jack of all trades and can fully leverage their advantages in the most appropriate scenarios. +Apache ShardingSphere integrates the operational scheme taking SEATA as the flexible transaction. +The following table can be used for comparison to help developers choose the suitable technology. -**The main design goal of the distributed transaction modular of Apache ShardingSphere is to integrate existing mature transaction cases to provide an unified distributed transaction interface for local transactions, 2PC transactions and soft transactions; - compensate for the deficiencies of current solutions to provide a one-stop distributed transaction solution.** +| | *LOCAL* | *XA* | *BASE* | +| -------- | ------------- | ---------------- | ------------ | +| Business transformation | None | None | Seata server needed| +| Consistency | Not supported | Not supported | Final consistency | +| Isolation | Not supported | Supported | Business side guaranteed | +| Concurrent performance | no loss | severe loss | slight loss | +| Applied scenarios | Inconsistent processing by the business side | short transaction & low-level concurrency | long transaction & high concurrency | -**Source Codes: https://github.com/apache/shardingsphere/tree/master/shardingsphere-kernel/shardingsphere-transaction** +## Related reference +- [YAML distributed transaction configuration](/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/transaction/) Review Comment: Link is incorrect. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
