1 Basic concepts
What is a transaction? As an example of life: you go to the canteen to buy something, "cash on delivery" is an example of a transaction, pay and delivery must be successful in all affairs to be successful, any one activity fails, the transaction will remove all It has been successful event.
Understand the above example, look at the definition of transaction:
the transaction can be seen as a big event, it is composed by different small activities, these activities are either all succeed, or all fail.
In a computer system, more it is to control transactions through a relational database, where the use of transactional features of the database itself to achieve, so called database transactions, mainly due to the application by the relational database to control transactions, and applications and databases are typically in the same a server, transaction-based relational database is also known as a local transaction.
Look at the four major characteristics of database transactions the ACID:
A (Atomic): atomicity, all operations constitute matters, or are executed, or all not executed, partial failure partial success impossible.
C (Consistency): consistency, before and after transaction execution, consistency constraints of the database is not corrupted. For example: Joe Smith transferred to John Doe 100, data before and after the transfer of the transfer is correct state called coherence, if there turn out 100 yuan Joe Smith, John Doe account does not appear to increase 100 yuan this data errors, you It did not reach consistency.
I (Isolation): isolation, usually in the database transaction concurrency, isolation refers to two non-interfering execution of concurrent transactions, a transaction can not see the intermediate state other transactions running. Avoid stolen by configuring the transaction isolation level read, repeatable read other issues.
D (Durability): persistence, after the transaction is completed, the transaction changes the data will be persisted to the database, and will not be rolled back.
In operation, when the transaction database will be implemented according to a transaction into a integral whole execution unit, the execution of all operating units are either succeed or fail, as long as either operation fails, the transaction will cause the entire rollback.
With the rapid development of the Internet, the monomer system software from the original application for the change distributed applications, the following figure description single application to micro-services evolution: 
a distributed system will be split into an application system can be deployed independently of more than a service, remote collaboration is required to complete the transaction between the services and service operation, which is called a distributed system environment, distributed transactions over the network to complete the transaction by the remote collaboration between different services, such as user registration send integration affairs, Creating orders minus inventories are distributed transaction transactions, bank transfers and other transactions.
We know that the transaction characteristics depend on the database itself provides local transaction to achieve, the following logic to control local affairs:
begin transaction;
// 1. 本地数据库操作 ：张三减少金额
// 2. 本地数据库操作 ：李四增加金额
commit transation;
But in a distributed environment, this will become the following:
begin transaction；
// 1. 本地数据库操作 ：张三减少金额
// 2. 远程调用 ：让李四增加金额
commit transation;
It is envisaged that when John Doe make remote calls to increase the amount of success, due to network problems remotely call and did not return, this time local transaction rollback failed to submit Zhang reduce the amount of the operation, the data at this time Joe Smith and John Doe on inconsistent.
Therefore, on the basis of a distributed architecture, the traditional database transaction can not be used, Joe Smith and John Doe account is not in a database application is not even a system to achieve transfer transaction needs through long-distance calls, due to network problems can lead to distribution transaction problem.
1, a typical scenario is between micro-service architecture, micro remote service call to complete the transaction by the operation. For example: micro-service orders and inventory micro services, orders, while orders for micro-micro Inventory Service Request service inventory reduction. In short: Cross-JVM process to produce a distributed transaction. 
2, the monomer system accesses multiple database instances, when the monomer system needs to access multiple databases (Example) will produce a distributed transaction. For example: user information and order information respectively delete user information in two MySQL instance storage, user management system, you need to delete user information and the user's order information, respectively, because the data is distributed across different data instances, need to operate various database link data generated at this time distributed transaction. In short: Cross database instance to produce a distributed transaction. 
3, multi-service access the same database instance, such as: micro-service orders and inventory services even micro also have access to the same database distributed transaction, the reason is cross-JVM process, two micro-service holds a different database links database operation, this time to produce a distributed transaction.
我们了解到分布式事务的基础概念。与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同的机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此分布式事务需要更进一步的理论支持。
在了解分布式事务控制解决方案之前先了解一些基础理论，通过理论知识指导我们确定分布式事务控制的目标，从而帮助我们理解解决方案。
CAP是Consistency、Availability、Parition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。
下边我们分别来解释 ：
为了方便对CAP理论的理解，我们结合电商系统中的一些业务场景来理解CAP。
如下图，是商品信息管理的执行流程 ：
整体执行流程如下 ：
1、商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）。
2、主数据库向商品服务响应写入成功。
3、商品服务请求从数据库读取商品信息。
C-Consistency ：
一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态。
上图中，商品信息的读写要满足一致性就是要实现如下目标 ：
1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。
2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。
如何实现一致性？
1、写入主数据库后要将数据同步到从数据库。
2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据。
分布式系统一致性的特点 ：
1、由于存在数据同步的过程，写操作的响应会有一定的延迟。
2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。
3、如果请求数据同步失败的节点则会返回错误信息，一定不会返回旧数据。
A-Availability：
可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。
上图中，商品信息读取满足可用性就是要实现如下目标 ：
1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。
2、从数据库不允许出现响应超时或响应错误。
如何实现可用性？
1、写入主数据库后要将数据同步到从数据库。
2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
3、即使数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或者响应超时。
分布式系统可用性的特点 ：
1、所有请求都有响应，且不会出现响应超时或响应错误。
P-Partition tolerance ：
通常分布式系统的各个节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致节点之间通讯失败，此时仍可对外提供服务，这叫分区容忍性。
上图中，商品信息读写满足分区容忍性就是要实现如下目标 ：
1、主数据库向从数据库同步数据失败不影响读写操作。
2、其一个节点挂掉不影响另一个节点对外提供服务。
如何实现分区容忍性？
1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样节点之间能有效的实现松耦合。
2、添加从数据库节点，其中一个从节点挂掉其它从节点提供服务。
分布式分区容忍性的特点 ：
1、分区容忍性是分布式系统具备的基本能力。
1、上边商品管理的例子是否同时具备CAP呢？
在所有分布式事务场景中不会同时具备CAP三特性，因为在具备了P的前提下C和A是不能共存的。
比如 ：
下图满足了P即表示实现分区容忍 ：
本图分区容忍的含义是 ：
1）主数据库通过网络向从数据同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。
2）当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。
3）其一个节点挂掉不影响另一个节点对外提供服务。
如果要实现C则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据则需要将从数据库数据锁定，待同步完成后解锁，如果同步失败从数据库要返回错误信息或超时信息。
如果要实现A则必须保证数据可用性，不管任何时候都可以向从数据库查询数据，则不会响应超时或返回错误信息。
通过分析发现在满足P的前提下C和A存在矛盾性。
2、CAP有那些组合方式呢？
在生产中对分布式事务处理时要根据需求来确定满足CAP的那两个方面。
1）AP：
放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。
例如 ：
上边的商品管理，完全可以实现AP，前提是只要用户可以接收所查询的到数据在一定时间内不是最新的即可。
通常实现AP都会保证最终一致性，后面讲的BASE理论就是根据AP来扩展的，一些业务场景 比如 ：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。
2）CP：
放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致性，又比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
3）CA：
放弃分区容忍性，既不进行分区，不考虑由于网络不通或节点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA。
上边的商品管理，如果要实现CA则架构如下 ：
主数据库和从数据库中间不再进行数据同步，数据库可以响应每次的查询请求，通过事务隔离级别实现每个查询请求都可以返回最新的数据。
通过上面的学习，CAP是一个已经被证实的理论 ：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，节点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99.%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择 ：保证P和A，舍弃C强一致性，保证最终一致性。
1、理解强一致性和最终一致性
CAP理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP既舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子，AP即舍弃一致性，保证可用性和分区容忍性，但是在实际产生中很多场景都要实现一致性，比如前边我们觉得例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和CAP中的一致性不同，CAP中的一致性要求在任何时间查询每个节点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个节点的数据不一致，但是经过一段时间每个节点的数据必须一致，它强调的是最终数据的一致性。
2、Base理论介绍
BASE是Basically Availbale（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。
- 基本可用 ：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网址交易付款出现问题来，商品依然可以正常浏览。
- 软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单中的“支付中”、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
- Eventual consistency: after the final agreement means that over a period of time, all the nodes will all have the same data. If the order of "pay" status will eventually change to "pay for success" or "failure to pay", the order status and the actual trading results agree, but requires a certain time delay, wait.