架构设计 | 分布式事务①概念简介和基础理论

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

1、分布式事务简介

一、转帐经典案例

跨地区和机构的转帐的业务在实际生活中很是常见，基础流程以下：

帐户01经过一系列服务和支付的流程，把钱转入帐户02，在这一过程当中，若是帐户01出现出帐成功，可是帐户02没有入帐，这就致使数据不一致，违反了基本的事务原则。基于数据归属在不一样服务和不一样的数据库中，这种状况下的事务出错被称为分布式事务问题。

二、基本概念

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不一样的分布式系统的不一样节点之上。

如上的转帐案例，看似只有一次的转帐操，实际上由不一样的服务不一样数据库的多个细节操做组成，这些无感知的细节操做分布在不一样服务上，甚至属于不一样的地区和应用，如何保证这些操做所有成功或者所有失败，即保证不一样数据库间的数据一致性，这就是分布式事务须要解决的核心问题。

三、分布式事务特色

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

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

基于电商业务进行拆分，会出现常见的：订单，用户，库存，物流等一系列的服务，管理不一样的业务数据库，在实际的下单支付应用场景下，须要同时操做用户，订单，库存等多个服务，就必须保证数据一致性，下单支付成功，库存必须就须要用到分布式事务。

2、CAP基础理论

一、基础简介

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

Consistency：一致性

单个事务执行更新写操做，操做结束成功返回，在同一时间的其余事务读取的数据彻底一致，不存在中间状态。在分布式的系统中描述：用户下单支付，扣款，减库存，生成物流，必须一致。例如限量打折促销中，用户下单后库存没减小，这就致使不一致问题。

Availability：可用性

服务必须一直处于可用的状态，收到用户的请求，服务器必须在有限的时间给出回应，无论结果是处理成功或者处理失败。

Partition tolerance：分区容错

通俗说，在分布式系统中，一个流程里可能出现某个服务出错状况，这是没法绝对避免的，在程序设计上要能容忍这种错误发生。

二、CP和AP模式

分布式系统很难同时知足一致性、可用性、分区容错性三个特色，在大部分的系统架构中，都会选择CP或者AP模式，即须要抛弃一个特色，说明一点，为什么P没有抛弃，对于分布式系统而言，分区容错是该架构模式下的基本原则，不一样的SOA服务和数据库是好比会被部署到不一样的节点下。因此如何解决C（一致性）和A（可用性）就成分布式系统的最大痛点。

为什么不能同时知足C和A，这也是基于分布式架构特色看，不一样服务直接不能保证通讯是100%成功，一旦出现失败状况，一致性和可用性就没法知足。

既然强一致性没法保证，那退一步，给处理时间，最后结果保证一致性，也能够，这就涉及到BASE理论。

3、BASE基础理论

一、基础简介

BASE理论是由eBay公司的架构师提出的，主要是对上述的CAP理论中一致性和可用性作的权衡结果，基于CAP定律逐步演化而来，核心思想；即便没法作到强一致性，但每一个应用均可以根据自身业务特色，采用适当策略实现数据的最终一致性。

Basically Available：基本可用

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

Soft State：软状态

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

Eventual Consistency：最终一致

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

BASE理论提出是基于大规模高可用可扩展的分布式系统架构，不一样于关系型数据库事务特色(ACID)的强一致性模型，经过牺牲强一致性来获取更高的可用性，并容许数据在一段时间内是不一致的，但最终达到一致状态。实际的业务场景下事物(ACID)基本特性和BASE理论也是要权衡考虑。

二、柔性事务

遵循BASE理论，利用业务特色，在指按期限内让事务保持最终一致性，柔性事务是一种思想，从根本上看，就是业务模式对于事务过程当中不一致性有必定的容忍度，能够留出足够的时间执行事务最终一致的方法。

三、PAXOS算法

Paxos算法一种保障分布式系统最终一致性的共识算法，利用的是选举策略，少数服从多数的思想。PAXOS不要求对全部节点作实时同步，实质上是考虑到了分区状况下的可用性，经过减小完成一次事务须要的参与者个数，来保障系统的可用性。

例如：N个服务节点，有(N/2)+1个节点达成共识，则认为系统达到了一致，而且按照Paxos原则，最终理论上也达到了一致，不会再改变，如此一来，只要保证有半数以上的服务存活，容许小部分服务挂掉，客户能够与大部分服务节点通讯，那么就不会影响总体操做流程，也不需确保服务器所有处于工做状态，容错性很是好。操做影响的数据和结果随后会被异步的同步到其余节点上，从而保证最终一致性。

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

4、源代码地址

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

推荐阅读：架构设计系列

序号	标题
00	架构设计：单服务.集群.分布式，基本区别和联系
01	架构设计：分布式业务系统中，全局ID生成策略
02	架构设计：分布式系统调度，Zookeeper集群化管理
03	架构设计：接口幂等性原则，防重复提交Token管理
04	架构设计：缓存管理模式，监控和内存回收策略
05	架构设计：异步处理流程，多种实现模式详解
06	架构设计：高并发流量削峰，共享资源加锁机制
07	架构设计：分布式服务，库表拆分模式详解