分布式事务实战——常用解决方案的实现

本地事务

我们先从本地事务（数据库事务）说起吧，因为这个是大家在日常工作都接触到，开发过程中都会用到的。

事务: 由一组操作构成的可靠的，独立的操作单元；具有ACID四大特性，分别为原子性,一致性，隔离性和持久性。

优点：本地事务由资源管理系本地自行管理；支持严格的ACID四大特性；高效，可靠；

缺点：多个数据源搞不定，不具备分布式事务处理能力。

全局事务：

说明：

X/Open DTP 定义了三个组件：RM和两个协议：XA、TX

AP(Application Program)：也就是应用程序，可以理解为使用DTP的程序

RM(Resource Manager)：资源管理器，这里可以理解为一个DBMS系统，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制。两个要求：一是RM自身必须是支持事务的，二是RM能够根据将全局（分布式）事务标识定位到自己内部的对应事务。

TM(Transaction Manager)：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器。能与AP和RM直接通信，协调AP和RM来实现分布式事务的完整性。主要的工作是提供AP注册全局事务的接口，颁发全局事务标识（GTID之类 的），存储/管理全局事务的内容和决策并指挥RM做commit/rollback。

XA协议：应用或应用服务器与事务管理之前通信的接口

TX协议：全局事务管理器与资源管理器之间通信的接口

两阶段提交：

1.准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交。

2.提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。

从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。这就是使用XA事务。

J2EE平台中的分布式事务实现： JTA&JTS; 感兴趣的朋友可以自行去了解下。

Bsse理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性—-注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。换句话说，原子性和持久性必须要根本保障，为了可用性，性能与降级服务的需求，只有降低了一致性与隔离性的需求。

CAP理论

对于共享数据系统，最多只能同时拥有CAP理论中的两者，没法全部兼顾。

任意两者的组合都有使用的业务场景

真是业务场景中应该死ACID和BASE的混合体

1、一致性

在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一直的状态。

对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进 行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数 据），这就是典型的分布式数据不一致的情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么 这样的系统就被认为具有强一致性。

2、可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是”有限时间内”和”返回结果”。

“有限时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对 应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，”有限的时间内”是指系统设计之初就设计好的运行指标，通常不同系统之间有很 大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。

“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

3、分区容错性

分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络） 中，由于一些特殊的原因导致这些子网络出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。 需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

选择说明：

CA： 放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择

AP： 放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此

CP： 放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

柔性事务

服务模式：

• 可查询操作：
• 为了保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号），或者是使用操作资源的组合标识（比如商户号+商户订单号）。除此之外，操作的时间信息也要有完整的记录。
• 可以使用全局的服务操作标识，来查询操作的执行结果，特别对处理中的状态的逻辑要谨慎对待。
• 幂等操作：
• 幂等性： ff((x))=f(x); 重复调用多次产生的业务结果与调用一次的业务结果一致；
• 可以通过业务操作本身实现幂等性；或者系统缓存所有的请求与处理结果，检测到重复请求之后，返回之前的处理结果。
• TCC操作：
• Try:尝试执行业务（1.完成所有业务检查 2.预留必须的业务资源）
• confirm：确认执行业务（1.真正执行业务检查 2.不做任何业务检查 3.只只用try阶段预留的业务资源 4.满足幂等性）
• cancel:取消执行业务（1.释放try阶段预留的业务资源 2.cancel操作要满足幂等性）
• 可补偿操作：
• 可以抵消冲正正向业务操作的业务结果，补偿需要满足幂等性。

解决方案：

• 可靠消息的最终一致性（异步确保）

核心逻辑：

业务处理服务在业务事务提交前，向实时消息服务器发送消息，实时消息服务只记录消息数据，而不是真正去发送；业务处理服务事务提交后，向实时消息服务发送确认发送的指令； 实时消息服务只有得到确认发送指令后才真正发送消息。

业务处理服务在业务事务回滚后，向实时消息发送取消发送指令。 消息确认系统定期找到未确认或者回滚发送的消息，向业务处理服务器询问消息状态，业务服务器根据消息ID或者内容确认消息是否有效。

被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是支持幂等操作。

优点：消息数据独立存储，伸缩性好，降低与业务系统的耦合性；对最终一致性的时间敏感度比较高，降低业务被动方的实现成本。

缺点：消息系统建设成本比较高，一次消息发送需要两次请求，业务处理服务需要给消息系统提供状态回查的接口。

• TCC（两阶型，补偿型）
• 一个完整的业务活动由一个主业务服务以及其他从业务服务器注册，主业务服务发起并完成整个业务活动；从业务服务提供TCC型业务操作；业务活动管理器控制业务活动的一致性，他记录业务活动中的操作，并在业务活动提交的时确认所有的tcc操作的confirm操作；取消的时候调用所有tcc操作中的cancel操作。
• 适用强隔离性，一致性要求高的业务活动的场景
• 最大努力通知型
• 业务活动 主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失； 业务活动的被动方根据定时策略，向业务活动主动方查询，回复丢失的业务消息。
• 适用于对业务最终一致性的时间敏感度低的场景。

想要学习Dubbo框架、zookeper基本原理、redis分布式缓存、JVM性能优化，Nginx+apache+Tomcat集群部署、大数据hadoop,Hbase实时计算spark、storm、数据分析分词和权重等核心技术；需要的可以关注之后私信哈，记得要点赞转发噢！！！