You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2020/07/01 06:59:19 UTC
[GitHub] [shardingsphere] mlw12345678 opened a new pull request #6229: translate the solution from solution.cn.md to solution.en.md
mlw12345678 opened a new pull request #6229:
URL: https://github.com/apache/shardingsphere/pull/6229
Fixes #6070 No4.
Changes proposed in this pull request:
-
-
-
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] kimmking commented on a change in pull request #6229: translate the solution from solution.cn.md to solution.en.md
Posted by GitBox <gi...@apache.org>.
kimmking commented on a change in pull request #6229:
URL: https://github.com/apache/shardingsphere/pull/6229#discussion_r448780341
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
Review comment:
Liang Zhang，Leader of Data R&D of JD.com, initiator & PPMC of Apache ShardingSphere
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
Review comment:
Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software.
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
+
+Blog address：https://willemjiang.github.io/
+
+---
+
+Zheng Feng is a software engineer at Red Hat. Joined Red Hat Software in 2009, mainly engaged in the work of the transaction manager. As a core developer, he participated in the Narayan and Blacktie projects. He had contributed to the integration of transaction processing of multiple application servers (Wildfly, Karaf, Tomcat) and frameworks (Common DBCP, Spring Boot ). Since 2017, he has participated in the Apache ServiceComb project and is currently a member of PMC. He has in-depth research on distributed transaction processing and transaction processing in a microservice environment.
+
+### Guide
+
+Compared with the gradual maturity of data sharding solutions, distributed transaction solutions that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios in one are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) stages and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
+
+At the beginning of 2019, Apache ShardingSphere (Incubating) provided a rigid and flexible integrated distributed transaction solution. If your application system is being troubled by this aspect, why not pour a cup of coffee and spend ten minutes reading this article, maybe you will gain something?
+
+### Background
+
+Database transactions need to meet the four characteristics of ACID (Atomicity, Consistency, Isolation, Durability).
+
+- Atomicity Refers to the execution of the transaction as a whole, either all or no execution.
+
+- Consistency Refers to the transaction should ensure that the data changes from one consistent state to another consistent state.
+
+- Isolation When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions.
+
+- Durability Refers to the committed transaction modification data will be persisted.
+
+In a single data node, the transaction is limited to the access control of a single database resource, called local transaction. Almost all mature relational databases provide native support for local transactions. However, in a distributed application environment based on microservices, more and more application scenarios require that access to multiple services and corresponding multiple database resources can be incorporated into the same transaction, then the distributed transactions emerge as the times require.
+
+Although the relational database provides perfect ACID native support for local transactions. But in a distributed scenario, it has become a shackle in system performance. How to make the database meet the characteristics of ACID or find corresponding alternatives in a distributed scenario is the focus of distributed transactions.
+
+#### Local transaction
+
+Without opening any distributed transaction manager, let each data node manage its own transaction. There is no coordination and communication between them, and they do not know each other's success of other data node transactions. There is no loss in performance for local transactions, but it is inadequate in terms of strong consistency and eventual consistency.
+
+#### Two-phase commit
+
+The earliest distributed transaction model of the XA protocol is the X/Open Distributed Transaction Processing (DTP) model proposed by the X/Open International Alliance, referred to as the XA protocol.
+
+The distributed transaction based on the XA protocol has little intrusion on the business. Its biggest advantage is that it is transparent to the user. Users can use distributed transactions based on the XA protocol like local transactions. The XA protocol can strictly guarantee the ACID characteristics of transactions.
+
+Strictly guaranteeing ACID characteristics of transactions is a double-edged sword. In the process of transaction execution, all required resources need to be locked, so the XA protocol is more suitable for short transactions whose execution time is determined. For long transactions, the exclusive use of data during the entire transaction will cause the concurrency performance of business systems that rely on hot data to decline significantly. Therefore, in high-concurrency performance-oriented scenarios, distributed transactions based on the XA protocol two-phase commit type are not the best choice.
+
+#### Flexible transaction
+
+If the transaction that implements the ACID transaction element is called a rigid transaction, the transaction based on the BASE transaction element is called a flexible transaction. BASE is an abbreviation of the three elements of basic availability, flexible state and final consistency.
+
+- Basically Available Ensure that participants in distributed transactions are not necessarily online at the same time.
+
+- Soft state It allows a certain delay in the system status update, and this delay may not be noticeable to customers.
+
+- Eventually consistent Usually, the final consistency of the system is ensured by means of message passing.
+
+In ACID transactions, the requirements for consistency and isolation are very high. During the execution of the transaction, all resources must be occupied. The idea of flexible transactions is to move the mutex operation from the resource level to the business level through business logic. By relaxing the requirements for strong consistency and isolation, only when the entire transaction ends, the data is consistent. During the execution of the transaction, any data obtained by the read operation may be changed. This weak consistency design can be used in exchange for system throughput improvement.
+
+Saga is a typical flexible transaction manager. The concept of Sagas comes from a database paper more than thirty years ago [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf], a Saga transaction is A long-term transaction which is composed of multiple short-term transactions. In the distributed transaction scenario, we regard a Saga distributed transaction as a transaction composed of multiple local transactions, and each local transaction has a corresponding compensation transaction. During the execution of the Saga transaction, if an abnormality occurs in a certain step, the Saga transaction will be terminated, and the corresponding compensation transaction will be called to complete the related recovery operation, so as to ensure that the local transactions related to Saga are all executed successfully, or through compensation restore to the state before the transaction was executed.
Review comment:
a Saga transaction is a long-term
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
+
+Blog address：https://willemjiang.github.io/
+
+---
+
+Zheng Feng is a software engineer at Red Hat. Joined Red Hat Software in 2009, mainly engaged in the work of the transaction manager. As a core developer, he participated in the Narayan and Blacktie projects. He had contributed to the integration of transaction processing of multiple application servers (Wildfly, Karaf, Tomcat) and frameworks (Common DBCP, Spring Boot ). Since 2017, he has participated in the Apache ServiceComb project and is currently a member of PMC. He has in-depth research on distributed transaction processing and transaction processing in a microservice environment.
+
+### Guide
+
+Compared with the gradual maturity of data sharding solutions, distributed transaction solutions that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios in one are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) stages and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
+
+At the beginning of 2019, Apache ShardingSphere (Incubating) provided a rigid and flexible integrated distributed transaction solution. If your application system is being troubled by this aspect, why not pour a cup of coffee and spend ten minutes reading this article, maybe you will gain something?
+
+### Background
+
+Database transactions need to meet the four characteristics of ACID (Atomicity, Consistency, Isolation, Durability).
+
+- Atomicity Refers to the execution of the transaction as a whole, either all or no execution.
+
+- Consistency Refers to the transaction should ensure that the data changes from one consistent state to another consistent state.
+
+- Isolation When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions.
+
+- Durability Refers to the committed transaction modification data will be persisted.
+
+In a single data node, the transaction is limited to the access control of a single database resource, called local transaction. Almost all mature relational databases provide native support for local transactions. However, in a distributed application environment based on microservices, more and more application scenarios require that access to multiple services and corresponding multiple database resources can be incorporated into the same transaction, then the distributed transactions emerge as the times require.
+
+Although the relational database provides perfect ACID native support for local transactions. But in a distributed scenario, it has become a shackle in system performance. How to make the database meet the characteristics of ACID or find corresponding alternatives in a distributed scenario is the focus of distributed transactions.
+
+#### Local transaction
+
+Without opening any distributed transaction manager, let each data node manage its own transaction. There is no coordination and communication between them, and they do not know each other's success of other data node transactions. There is no loss in performance for local transactions, but it is inadequate in terms of strong consistency and eventual consistency.
+
+#### Two-phase commit
+
+The earliest distributed transaction model of the XA protocol is the X/Open Distributed Transaction Processing (DTP) model proposed by the X/Open International Alliance, referred to as the XA protocol.
+
+The distributed transaction based on the XA protocol has little intrusion on the business. Its biggest advantage is that it is transparent to the user. Users can use distributed transactions based on the XA protocol like local transactions. The XA protocol can strictly guarantee the ACID characteristics of transactions.
+
+Strictly guaranteeing ACID characteristics of transactions is a double-edged sword. In the process of transaction execution, all required resources need to be locked, so the XA protocol is more suitable for short transactions whose execution time is determined. For long transactions, the exclusive use of data during the entire transaction will cause the concurrency performance of business systems that rely on hot data to decline significantly. Therefore, in high-concurrency performance-oriented scenarios, distributed transactions based on the XA protocol two-phase commit type are not the best choice.
+
+#### Flexible transaction
+
+If the transaction that implements the ACID transaction element is called a rigid transaction, the transaction based on the BASE transaction element is called a flexible transaction. BASE is an abbreviation of the three elements of basic availability, flexible state and final consistency.
Review comment:
BASE is an abbreviation of the three elements of Basic Availability, Soft state and Eventually consistent.
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
Review comment:
the main energy is invested in -> focus on
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
+
+Blog address：https://willemjiang.github.io/
+
+---
+
+Zheng Feng is a software engineer at Red Hat. Joined Red Hat Software in 2009, mainly engaged in the work of the transaction manager. As a core developer, he participated in the Narayan and Blacktie projects. He had contributed to the integration of transaction processing of multiple application servers (Wildfly, Karaf, Tomcat) and frameworks (Common DBCP, Spring Boot ). Since 2017, he has participated in the Apache ServiceComb project and is currently a member of PMC. He has in-depth research on distributed transaction processing and transaction processing in a microservice environment.
+
+### Guide
+
+Compared with the gradual maturity of data sharding solutions, distributed transaction solutions that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios in one are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) stages and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
Review comment:
Compared with the gradual maturity of data sharding, distributed transaction that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios, the solutions are applicable to all of them are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) phases and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
+
+Blog address：https://willemjiang.github.io/
+
+---
+
+Zheng Feng is a software engineer at Red Hat. Joined Red Hat Software in 2009, mainly engaged in the work of the transaction manager. As a core developer, he participated in the Narayan and Blacktie projects. He had contributed to the integration of transaction processing of multiple application servers (Wildfly, Karaf, Tomcat) and frameworks (Common DBCP, Spring Boot ). Since 2017, he has participated in the Apache ServiceComb project and is currently a member of PMC. He has in-depth research on distributed transaction processing and transaction processing in a microservice environment.
+
+### Guide
+
+Compared with the gradual maturity of data sharding solutions, distributed transaction solutions that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios in one are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) stages and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
+
+At the beginning of 2019, Apache ShardingSphere (Incubating) provided a rigid and flexible integrated distributed transaction solution. If your application system is being troubled by this aspect, why not pour a cup of coffee and spend ten minutes reading this article, maybe you will gain something?
+
+### Background
+
+Database transactions need to meet the four characteristics of ACID (Atomicity, Consistency, Isolation, Durability).
+
+- Atomicity Refers to the execution of the transaction as a whole, either all or no execution.
+
+- Consistency Refers to the transaction should ensure that the data changes from one consistent state to another consistent state.
+
+- Isolation When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions.
+
+- Durability Refers to the committed transaction modification data will be persisted.
+
+In a single data node, the transaction is limited to the access control of a single database resource, called local transaction. Almost all mature relational databases provide native support for local transactions. However, in a distributed application environment based on microservices, more and more application scenarios require that access to multiple services and corresponding multiple database resources can be incorporated into the same transaction, then the distributed transactions emerge as the times require.
+
+Although the relational database provides perfect ACID native support for local transactions. But in a distributed scenario, it has become a shackle in system performance. How to make the database meet the characteristics of ACID or find corresponding alternatives in a distributed scenario is the focus of distributed transactions.
+
+#### Local transaction
+
+Without opening any distributed transaction manager, let each data node manage its own transaction. There is no coordination and communication between them, and they do not know each other's success of other data node transactions. There is no loss in performance for local transactions, but it is inadequate in terms of strong consistency and eventual consistency.
+
+#### Two-phase commit
+
+The earliest distributed transaction model of the XA protocol is the X/Open Distributed Transaction Processing (DTP) model proposed by the X/Open International Alliance, referred to as the XA protocol.
+
+The distributed transaction based on the XA protocol has little intrusion on the business. Its biggest advantage is that it is transparent to the user. Users can use distributed transactions based on the XA protocol like local transactions. The XA protocol can strictly guarantee the ACID characteristics of transactions.
+
+Strictly guaranteeing ACID characteristics of transactions is a double-edged sword. In the process of transaction execution, all required resources need to be locked, so the XA protocol is more suitable for short transactions whose execution time is determined. For long transactions, the exclusive use of data during the entire transaction will cause the concurrency performance of business systems that rely on hot data to decline significantly. Therefore, in high-concurrency performance-oriented scenarios, distributed transactions based on the XA protocol two-phase commit type are not the best choice.
+
+#### Flexible transaction
+
+If the transaction that implements the ACID transaction element is called a rigid transaction, the transaction based on the BASE transaction element is called a flexible transaction. BASE is an abbreviation of the three elements of basic availability, flexible state and final consistency.
+
+- Basically Available Ensure that participants in distributed transactions are not necessarily online at the same time.
+
+- Soft state It allows a certain delay in the system status update, and this delay may not be noticeable to customers.
+
+- Eventually consistent Usually, the final consistency of the system is ensured by means of message passing.
Review comment:
Eventually consistent Usually, the eventually consistency of the system is ensured by means of message passing.
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
Review comment:
leading open source projects -> leading open source project
main -> popular
platform -> platforms
code -> codes
##########
File path: docs/blog/content/material/solution.en.md
##########
@@ -4,4 +4,252 @@ weight = 9
chapter = true
+++
-## TODO
+## The mixed open-source distributed transaction solution
+
+### Author
+
+Liang Zhang，Head of Data R&D of JD.com, initiator of Apache ShardingSphere & PPMC
+
+Love open source, currently leading open source projects ShardingSphere (formerly known as Sharding-JDBC) and Elastic-Job. Good at using Java as the main distributed architecture and Kubernetes and Mesos as the main cloud platform, admiring elegant code, and having more research on how to write expressive code.
+
+At present, the main energy is invested in building ShardingSphere into the industry's first-class financial data solution. ShardingSphere has entered the Apache incubator, is the first open source project of the Jingdong Group to enter the Apache Foundation, and is also the first distributed database middleware of the Apache Foundation.
+
+---
+Ning Jiang，Technical expert of Huawei Open Source Competency Center, project leader of Apache ServiceComb. Former chief software engineer of Red Hat Software, he has more than ten years of experience in enterprise-level open source middleware development, rich experience in Java development and use, and he also is the enthusiast of functional programming. Since 2006, he has been engaged in the development of the Apache open source middleware project, and has participated in the development of Apache CXF, Apache Camel, and Apache ServiceMix. He has in-depth research in the microservice architecture, such as WebServices, Enterprise Integration Pattern, SOA and OSGi.
+
+Blog address：https://willemjiang.github.io/
+
+---
+
+Zheng Feng is a software engineer at Red Hat. Joined Red Hat Software in 2009, mainly engaged in the work of the transaction manager. As a core developer, he participated in the Narayan and Blacktie projects. He had contributed to the integration of transaction processing of multiple application servers (Wildfly, Karaf, Tomcat) and frameworks (Common DBCP, Spring Boot ). Since 2017, he has participated in the Apache ServiceComb project and is currently a member of PMC. He has in-depth research on distributed transaction processing and transaction processing in a microservice environment.
+
+### Guide
+
+Compared with the gradual maturity of data sharding solutions, distributed transaction solutions that combine performance, transparency, automation, strong consistency, and can be applied to various application scenarios in one are very rare. Based on the performance bottlenecks of distributed transactions submitted in two (three) stages and the business transformation of flexible transactions, distributed transactions are still a headache for architects.
+
+At the beginning of 2019, Apache ShardingSphere (Incubating) provided a rigid and flexible integrated distributed transaction solution. If your application system is being troubled by this aspect, why not pour a cup of coffee and spend ten minutes reading this article, maybe you will gain something?
+
+### Background
+
+Database transactions need to meet the four characteristics of ACID (Atomicity, Consistency, Isolation, Durability).
+
+- Atomicity Refers to the execution of the transaction as a whole, either all or no execution.
+
+- Consistency Refers to the transaction should ensure that the data changes from one consistent state to another consistent state.
+
+- Isolation When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions.
+
+- Durability Refers to the committed transaction modification data will be persisted.
+
+In a single data node, the transaction is limited to the access control of a single database resource, called local transaction. Almost all mature relational databases provide native support for local transactions. However, in a distributed application environment based on microservices, more and more application scenarios require that access to multiple services and corresponding multiple database resources can be incorporated into the same transaction, then the distributed transactions emerge as the times require.
+
+Although the relational database provides perfect ACID native support for local transactions. But in a distributed scenario, it has become a shackle in system performance. How to make the database meet the characteristics of ACID or find corresponding alternatives in a distributed scenario is the focus of distributed transactions.
+
+#### Local transaction
+
+Without opening any distributed transaction manager, let each data node manage its own transaction. There is no coordination and communication between them, and they do not know each other's success of other data node transactions. There is no loss in performance for local transactions, but it is inadequate in terms of strong consistency and eventual consistency.
+
+#### Two-phase commit
+
+The earliest distributed transaction model of the XA protocol is the X/Open Distributed Transaction Processing (DTP) model proposed by the X/Open International Alliance, referred to as the XA protocol.
+
+The distributed transaction based on the XA protocol has little intrusion on the business. Its biggest advantage is that it is transparent to the user. Users can use distributed transactions based on the XA protocol like local transactions. The XA protocol can strictly guarantee the ACID characteristics of transactions.
+
+Strictly guaranteeing ACID characteristics of transactions is a double-edged sword. In the process of transaction execution, all required resources need to be locked, so the XA protocol is more suitable for short transactions whose execution time is determined. For long transactions, the exclusive use of data during the entire transaction will cause the concurrency performance of business systems that rely on hot data to decline significantly. Therefore, in high-concurrency performance-oriented scenarios, distributed transactions based on the XA protocol two-phase commit type are not the best choice.
+
+#### Flexible transaction
+
+If the transaction that implements the ACID transaction element is called a rigid transaction, the transaction based on the BASE transaction element is called a flexible transaction. BASE is an abbreviation of the three elements of basic availability, flexible state and final consistency.
+
+- Basically Available Ensure that participants in distributed transactions are not necessarily online at the same time.
+
+- Soft state It allows a certain delay in the system status update, and this delay may not be noticeable to customers.
+
+- Eventually consistent Usually, the final consistency of the system is ensured by means of message passing.
+
+In ACID transactions, the requirements for consistency and isolation are very high. During the execution of the transaction, all resources must be occupied. The idea of flexible transactions is to move the mutex operation from the resource level to the business level through business logic. By relaxing the requirements for strong consistency and isolation, only when the entire transaction ends, the data is consistent. During the execution of the transaction, any data obtained by the read operation may be changed. This weak consistency design can be used in exchange for system throughput improvement.
+
+Saga is a typical flexible transaction manager. The concept of Sagas comes from a database paper more than thirty years ago [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf], a Saga transaction is A long-term transaction which is composed of multiple short-term transactions. In the distributed transaction scenario, we regard a Saga distributed transaction as a transaction composed of multiple local transactions, and each local transaction has a corresponding compensation transaction. During the execution of the Saga transaction, if an abnormality occurs in a certain step, the Saga transaction will be terminated, and the corresponding compensation transaction will be called to complete the related recovery operation, so as to ensure that the local transactions related to Saga are all executed successfully, or through compensation restore to the state before the transaction was executed.
+
+TCC (Try-Cancel/Confirm implementation) is another kind of flexible transaction coordination implementation. TCC provides a more perfect recovery method with the help of a two-phase submission agreement. In TCC mode, cancel compensation obviously needs to execute business logic in the second stage to cancel the consequences of the first stage. Try is to perform related business operations in the first stage to complete the occupation of related business resources, such as pre-allocating ticket resources, or checking and refreshing the user account credit limit. During the cancellation phase, relevant business resources are released, such as releasing pre-allocated ticketing resources or restoring previously occupied user credits. Why do we need to add confirmation operations? This needs to start with the use life cycle of business resources. In the try process, we are only occupying business resources, and the related execution operations are only in a pending state. Only after the confirmation operation is completed, the business resources can be truly confirmed.
+
+The strong consistency transaction based on ACID and the final consistency transaction based on BASE are not silver bullets, and their greatest strengths can only be used in the most suitable scenarios. The following table can be used to compare the differences between them in detail to help developers choose technologies.
+
+<center>
+
+
+| Contrast | Local Transaction | Two-phase Submission | Flexible Transaction |
Review comment:
Two-Phase Commit
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] tristaZero commented on pull request #6229: translate the solution from solution.cn.md to solution.en.md
Posted by GitBox <gi...@apache.org>.
tristaZero commented on pull request #6229:
URL: https://github.com/apache/shardingsphere/pull/6229#issuecomment-652751223
Hi @mlw12345678 Glad to see you twice. :-)
It looks adequate at my quick look, but @kimmking will give a detailed review. Please give us some time.
Cheers,
Trista
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] kimmking merged pull request #6229: translate the solution from solution.cn.md to solution.en.md
Posted by GitBox <gi...@apache.org>.
kimmking merged pull request #6229:
URL: https://github.com/apache/shardingsphere/pull/6229
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org