解决分布式事务基本思想Base和CPA理论、最终一致性|刚性事务、柔性事务

时间 2019-11-12

标签解决分布式事务基本思想 base cpa 理论最终一致性刚性柔性栏目系统架构繁體版

原文原文链接

在学习解决分布式事务基本思路以前，你们要熟悉一些基本解决分布式事务概念名词
好比：CAP与Base理论、柔性事务与刚性事务、理解最终一致性思想，JTA+XA、两阶段与三阶段提交等。node

如何保证强一致性呢？计算机专业的童鞋在学习关系型数据库的时候都学习了ACID原理，这里对ACID作个简单的介绍。若是想全面的学习ACID原理，请参考ACIDweb

关系型数据库天生就是解决具备复琐事务场景的问题，关系型数据库彻底知足ACID的特性。算法

数据库管理系统中事务(transaction)的四个特性（分析时根据首字母缩写依次解释）：
原子性（Atomicity）原子性是指事务是一个不可再分割的工做单元，事务中的操做要么都发生，要么都不发生
一致性（Consistency）一致性是指在事务开始以前和事务结束之后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
隔离性（Isolation）多个事务并发访问时，事务之间是隔离的，一个事务不该该影响其它事务运行效果。
持久性（Durability）这是最好理解的一个特性：持久性，意味着在事务完成之后，该事务所对数据库所做的更改便持久的保存在数据库之中，并不会被回滚。（完成的事务是系统永久的部分，对系统的影响是永久性的，该修改即便出现致命的系统故障也将一直保持）数据库

所谓事务，它是一个操做序列，这些操做要么都执行，要么都不执行，它是一个不可分割的工做单位。（执行单个逻辑功能的一组指令或操做称为事务）浏览器

ACID是刚性事务服务器

柔性事务通常遵循BAS和CPA理论，能够暂时不一致网络

因为对系统或者数据进行了拆分，咱们的系统再也不是单机系统，而是分布式系统，针对分布式系统的CAP原理包含以下三个元素。
C:Consistency,一致性。在分布式系统中的全部数据备份，在同一时刻具备一样的值，全部节点在同一时刻读取的数据都是最新的数据副本。架构

双方进行通信的时候，或者服务器集群的时候，必定要保证数据一致性问题，不能发生脏读等问题。其实通常状况下能够作个取舍，能够暂时不遵循一致性，可是达到最终一致性，只要核心遵循下面的可用性和分区容忍性就能够。并发

A:Availability,可用性，好的响应性能。彻底的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。负载均衡

好比服务器宕机状况下还有备机
P: Partition tolerance,分区容错性。尽管网络上有部分消息丢失，但系统仍然可继续工做。

实际开发中大部分只遵循了p和a

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。所以在进行分布式架构设计时，必须作出取舍。而对于分布式数据系统，分区容忍性是基本要求，容错是确定的，不然就失去了价值。所以设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不须要强一致性，所以牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

补充：经过软状态，能够暂时不一致，可是最终实现一致。经过补偿、重试等。

固然，牺牲一致性，并非彻底无论数据的一致性，不然数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是再也不要求关系型数据库中的强一致性，而是只要系统能达到最终一致性便可，考虑到客户体验，这个最终一致的时间窗口，要尽量的对用户透明，也就是须要保障“用户感知到的一致性”。一般是经过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

CAP原理证实，任何分布式系统只可同时知足以上两点，没法三者兼顾。因为关系型数据库是单节点无复制的，所以不具备分区容忍性，可是具备一致性和可用性，而分布式的服务化系统都须要知足分区容忍性，那么咱们必须在一致性和可用性之间进行权衡。若是在网络上有消息丢失，也就是出现了网络分区，则复制操做可能会被延后，若是这时咱们的使用方等待复制完成再返回，则可能致使在有限时间内没法返回，就失去了可用性:而若是使用方不等待复制完成，而在主分片写完后直接返回，则具备了可用性，可是失去了一致性。

Base 理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，由 eBay 架构师 Dan Pritchett 于 2008 年在《BASE: An Acid Alternative》论文中首次提出。BASE 思想与 ACID 原理大相径庭，它知足 CAP 原理，经过牺牲强一致性得到可用性，通常应用于服务化系统的应用层或者大数据处理系统中，经过达到最终一致性来尽可能知足业务的绝大多数需求。
BASE 模型包含以下三个元素：

BA：（Basically Available ），基本可用。
S：（ Soft State），软状态，状态能够在一段时间内不一样步。
E：（Eventually Consistent ），最终一致，在必定的时间窗口内，最终数据达成一致便可。

关于最终一致的几种变种参见上面，在实际系统实践中，能够将若干变种结合起来，来实现各类业务需求。

BASE理论是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。核心思想：即便没法作到强一致性，但每一个业务根据自身的特色，采用适当的方式来使系统达到最终一致性。
一、基本可用：指分布式系统在出现故障的时候，容许损失部分可用性，保证核心可用。但不等价于不可用。好比：搜索引擎0.5秒返回查询结果，但因为故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务，等。
二、软状态：软状态是指容许系统存在中间状态，而且该中间状态不会影响系统总体可用性。即容许系统在不一样节点间副本同步的时候存在延时。
三、最终一致性：
系统中的全部数据副本通过必定时间后，最终可以达到一致的状态，不须要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊状况。BASE理论面向的是大型高可用可扩展的分布式系统，经过牺牲强一致性来得到可用性。ACID是传统数据库经常使用的概念设计，追求强一致性模型。

案例：支付的过程：

toov5 调用支付宝时候会传递两个参数同步回调地址和异步回调地址

同步回调地址：支付完成后，支付宝采用浏览器方式重定向回调方

异步回调地址：支付完成后，采用后台也就是HttpClient进行调用toov5接口通知支付接口

上面场景是两个事务（两个项目）采用的软状态，暂时不一致，可是最终一致

当通知接口出现延迟或者异常状况下，支付宝会发生自动重试。短暂的不一致状况

重试过程。toov5注意幂等性

这个案例能够用做和外部接口交互的状况

柔性事务知足BASE理论（基本可用，最终一致）

刚性事务知足ACID理论

本文主要围绕分布式事务当中的柔性事务的处理方式进行讨论。

柔性事务分为

1. 两阶段型

2. 补偿型 支付宝的案例，有短暂的不一致

3. 异步确保型

4. 最大努力通知型几种。因为支付宝整个架构是SOA架构，所以传统单机环境下数据库的ACID事务知足了分布式环境下的业务须要，以上几种事务相似就是针对分布式环境下业务须要设定的

具备针对性的总结，小伙伴们能够继续往下看：

关系型数据库严格遵循ACID理论。但当数据库要开始知足横向扩展、高可用、模式自由等需求时，须要对ACID理论进行取舍，不能严格遵循ACID。以CAP理论和BASE理论为基础的NoSQL数据库开始出现。

分布式存储的问题 – CAP理论

若是咱们期待实现一套严格知足ACID的分布式事务，极可能出现的状况就是系统的可用性和严格一致性发生冲突。在可用性和一致性之间永远没法存在一个一箭双鵰的方案。因为NoSQL的基本需求就是支持分布式存储，严格一致性与可用性须要互相取舍，由此延伸出了CAP理论来定义分布式存储遇到的问题。

CAP理论告诉咱们：一个分布式系统不可能同时知足一致性(C:Consistency)、可用性(A:Availability)、分区容错性(P:Partitiontolerance)这三个基本需求，而且最多只能知足其中的两项。

对于一个分布式系统来讲，分区容错是基本需求，不然不能称之为分布式系统。所以架构师须要在C和A之间寻求平衡。

C – Consistency – 一致性（与ACID的C彻底不一样）

一致性是指“all nodes see the same data at the same time”，即更新操做成功并返回客户端完成后，全部节点在同一时间的数据彻底一致。

对于一致性，能够分为从客户端和服务端两个不一样的视角。

从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。

从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是由于有并发读写才有的问题，所以在理解一致性的问题时，必定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不一样进程如何获取的不一样策略，决定了不一样的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。若是能容忍后续的部分或者所有访问不到，则是弱一致性。若是通过一段时间后要求能访问到更新后的数据，则是最终一致性。

A – Availability – 可用性

可用性是指“Reads and writes always succeed”，即服务一直可用，并且是正常响应时间。

对于一个可用性的分布式系统，每个非故障的节点必须对每个请求做出响应。也就是说，该系统使用的任何算法必须最终终止。当同时要求分区容忍性时，这是一个很强的定义：即便是严重的网络错误，每一个请求必须完成。

好的可用性主要是指系统可以很好的为用户服务，不出现用户操做失败或者访问超时等用户体验很差的状况。在一般状况下，可用性与分布式数据冗余、负载均衡等有着很大的关联。

P – Partition tolerance – 分区容错性

分区容错性是指“the system continues to operate despite arbitrary message loss or failureof part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然可以对外提供知足一致性和可用性的服务。

分区容错性和扩展性紧密相关。在分布式应用中，可能由于一些分布式的缘由致使系统没法正常运转。好的分区容错性要求可以使应用虽然是一个分布式系统，但看上去却好像是一个能够运转正常的总体。好比如今的分布式系统中有某一个或者几个机器宕掉了，其它剩下的机器还可以正常运转知足系统需求，或者是机器之间有网络异常，将分布式系统分隔成未独立的几个部分，各个部分还能维持分布式系统的运做，这样就具备好的分区容错性。

CA without P

若是不要求P（不容许分区），则C（强一致性）和A（可用性）是能够保证的。但其实分区不是你想不想的问题，而是始终会存在，所以CA的系统更多的是容许分区后各子系统依然保持CA。

CP without A

若是不要求A（可用），至关于每一个请求都须要在Server之间强一致，而P（分区）会致使同步时间无限延长，如此CP也是能够保证的。不少传统的数据库分布式事务都属于这种模式。

AP without C

要高可用并容许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每一个节点只能用本地数据提供服务，而这样会致使全局数据的不一致性。如今众多的NoSQL都属于此类。

CAP理论定义了分布式存储的根本问题，但并无指出一致性和可用性之间到底应该如何权衡。因而出现了BASE理论，给出了权衡A与C的一种可行方案。

权衡一致性与可用性 - BASE理论

Base = Basically Available + Soft state + Eventuallyconsistent 基本可用性+软状态+最终一致性，由eBay架构师DanPritchett提出。Base是对CAP中一致性A和可用性C权衡的结果，源于提出者本身在大规模分布式系统上实践的总结。核心思想是没法作到强一致性，但每一个应用均可以根据自身的特色，采用适当方式达到最终一致性。

与NoSQL的联系：

NoSQL数据库种类繁多，可是有一个共同的特色，都是去掉了关系型数据库的关系型特性。数据之间无关系，这样就很是容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。