本文源码：GitHub·点这里 || GitEE·点这里

一、分布式事务简介

1、转账经典案例

跨地区和机构的转账的业务在理论生存中十分常见，根底流程如下：

账户 01 通过一系列服务和领取的流程，把钱转入账户 02，在这一过程中，如果账户 01 呈现出账胜利，然而账户 02 没有入账，这就导致数据不统一，违反了根本的事务准则。基于数据归属在不同服务和不同的数据库中，这种状况下的事务出错被称为分布式事务问题。

2、基本概念

分布式事务是指事务的参与者、反对事务的服务器、资源服务器以及事务管理器别离位于不同的分布式系统的不同节点之上。

如上的转账案例，看似只有一次的转账操，实际上由不同的服务不同数据库的多个细节操作组成，这些无感知的细节操作散布在不同服务上，甚至属于不同的地区和利用，如何保障这些操作全副胜利或者全副失败，即保障不同数据库间的数据一致性，这就是分布式事务须要解决的外围问题。

3、分布式事务特点

基于如下电商业务场景，根本分布式的架构思路：

• 数据库基于业务特点，进行分库分表；
• 数据库拆分，随之就是业务的服务化(SOA)；

基于电商业务进行拆分，会呈现常见的：订单，用户，库存，物流等一系列的服务，治理不同的业务数据库，在理论的下单领取利用场景下，须要同时操作用户，订单，库存等多个服务，就必须保证数据一致性，下单领取胜利，库存必须就须要用到分布式事务。

二、CAP 基础理论

1、根底简介

说到分布式事务问题，必然会说下 CAP 实践，分布式系统的三大指标：

Consistency：一致性

单个事务执行更新写操作，操作完结胜利返回，在同一时间的其余事务读取的数据完全一致，不存在中间状态。在分布式的零碎中形容：用户下单领取，扣款，减库存，生成物流，必须统一。例如限量打折促销中，用户下单后库存没缩小，这就导致不统一问题。

Availability：可用性

服务必须始终处于可用的状态，收到用户的申请，服务器必须在无限的工夫给出回应，不论后果是解决胜利或者解决失败。

Partition tolerance：分区容错

艰深说，在分布式系统中，一个流程里可能呈现某个服务出错状况，这是无奈相对防止的，在程序设计上要能容忍这种谬误产生。

2、CP 和 AP 模式

分布式系统很难同时满足一致性、可用性、分区容错性三个特点，在大部分的零碎架构中，都会抉择 CP 或者 AP 模式，即须要摈弃一个特点，阐明一点，为何 P 没有摈弃，对于分布式系统而言，分区容错是该架构模式下的根本准则，不同的 SOA 服务和数据库是比方会被部署到不同的节点下。所以如何解决 C（一致性）和 A（可用性）就成分布式系统的最大痛点。

为何不能同时满足 C 和 A，这也是基于分布式架构特点看，不同服务间接不能保障通信是 100% 胜利，一旦呈现失败状况，一致性和可用性就无奈满足。

既然强一致性无奈保障，那退一步，给解决工夫，最初后果保障一致性，也能够，这就波及到 BASE 实践。

三、BASE 基础理论

1、根底简介

BASE 实践是由 eBay 公司的架构师提出的，次要是对上述的 CAP 实践中一致性和可用性做的衡量后果，基于 CAP 定律逐渐演变而来，核心思想；即便无奈做到强一致性，但每个利用都能够依据本身业务特点，采纳适当策略实现数据的最终一致性。

Basically Available：根本可用

分布式系统在产生故障的时，容许损失局部可用性。例如常见电商清仓甩卖时，为保障主业务能够，一些不重要的服务间接降级提醒。

Soft State：软状态

容许零碎中的数据存在中间状态，并认为该中间状态的存在不会影响零碎的整体可用性。绝对于原子性而言，要求多个节点的数据正本都是统一的，这是一种硬状态。

Eventual Consistency：最终统一

强调的数据更新操作，即软状态必须有个工夫期限，在通过一段时间的同步之后，最终都可能达到一个统一的状态。因而，最终一致性的实质是须要零碎保障最终数据可能达到统一，而不须要实时保证系统数据的强一致性。工夫期限长短取决于延时、负载、数据同步等各种因素。

BASE 实践提出是基于大规模高可用可扩大的分布式系统架构，不同于关系型数据库事务特点 (ACID) 的强一致性模型，通过就义强一致性来获取更高的可用性，并容许数据在一段时间内是不统一的，但最终达到统一状态。理论的业务场景下事物 (ACID) 根本个性和 BASE 实践也是要衡量思考。

2、柔性事务

遵循 BASE 实践，利用业务特点，在指定期限内让事务放弃最终一致性，柔性事务是一种思维，从根本上看，就是业务模式对于事务过程中不一致性有肯定的容忍度，能够留出足够的工夫执行事务最终统一的办法。

3、PAXOS 算法

Paxos 算法一种保障分布式系统最终一致性的共识算法，利用的是选举策略，多数遵从少数的思维。PAXOS 不要求对所有节点做实时同步，本质上是思考到了分区状况下的可用性，通过缩小实现一次事务须要的参与者个数，来保障系统的可用性。

例如：N 个服务节点，有(N/2)+ 1 个节点达成共识，则认为零碎达到了统一，并且依照 Paxos 准则，最终实践上也达到了统一，不会再扭转，如此一来，只有保障有半数以上的服务存活，容许小局部服务挂掉，客户能够与大部分服务节点通信，那么就不会影响整体操作流程，也不需确保服务器全副处于工作状态，容错性十分好。操作影响的数据和后果随后会被异步的同步到其余节点上，从而保障最终一致性。

分布式事务的各种具体实现案例，后续再说。

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

举荐浏览：架构设计系列