分布式事务(二)—分布式基本理论CAP定理、Raft算法、Base理论

一、分布式事务再次解析

上文说了，组成事务的sql语句是由不同的数据库连接执行的，称之为分布式事务。

下面举一个微服务间调用的例子说明

一个业务系统，远程调用了三个服务，每个服务都有独立的数据库。业务背景是电商，用户下单买东西，服务调用顺序，用户下单Order、扣减金额Account、减库存Storage完成需求。伪代码如下

public void bussiness(){
	//扣减库存
	httpclient.storage();
	//生成订单
	httpclient.order();
	//减去金额
	httpclient.account();
}
1
2
3
4
5
6
7
8

但是由于分布式系统经常出现的异常，如机器宕机、网络异常、超时异常、数据错误、不可靠TCP连接等等，上面的代码在执行到扣减完用户钱后Account服务宕机，但是bussiness无法知道Account服务的状态，即不知道Account服务是在扣减钱前宕掉还是扣减后宕掉。

此时bussiness这个大事务中三个小事务就无法做到同时成功同时失败，本地事务ACID的特性自然不能满足了。这个就是分布式事务的问题。

为了解决分布式的问题，业界也提出了其他理论。

二、分布式理论基础

1.CAP定理

该定理表明，在一个分布式系统中

• 一致性(Consistency)：

  • (1).集群状态：所有数据备份，在同一时刻是否是同样的值
  • (2).分布式状态：数据分布到不同节点上(如多个微服务)，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致

• 可用性(Availability)

  • 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

• 分区容错性(Partition tolerance)

  • 大多数分布式系统都分布在不同的子网络。每个子网络就叫做一个区。分区容错是区间通信失败。

CAP定理指出，上面三个要素最多只能实现两点，不可能三者兼顾。因为分布式系统中由于各种问题，延迟丢包，超时异常，机器宕掉等等，分区容错性P是无法避免的。

当发生节点通信失败后，如果保证可用A，继续接受用户请求，那么正常工作的节点和宕掉的节点数据就会一致，不满足一致性C。如果保证数据一致C，整个系统就不能接受用户请求，不满足可用性A。

所以在一个分布式系统中，要么AP、CP。如果是CA就不是分布式系统了，就是单节点对应单数据库。

2.Raft算法—保证CP

1.Raft算法概要

满足AP好说，一个节点挂掉，其他节点仍可以工作，有可能读到的数据不一致，因为我们不要C，所以数据不一致就不一致呗。

但是如果我们要满足CP，即每个时刻读到集群的数据都是一致的该如何做？

下面说下Raft算法

该算法要求分布式的各个节点有三个状态

• Follower：随从状态，如果在自己自旋时间内，没有收到领导的信息，则变为Condidate候选人状态。如果收到信息后，重置自己自旋时间，时间在120ms~150ms之间随机选一个。

• Condidate：候选人状态，发起投票，收到集群中超过一半节点(加上自己)的票数变为领导。

• Leader：领导状态，集群中只有领导能接收客户端的请求，通过心跳方式将数据发送给将数据给各个Follower节点，Follower节点收到数据提交到自己本地后回复给Leader，Leader收到一半以上Follower节点确认后回复请求给客户端。

可以看动画对应下上面的三种状态

raft动画：http://thesecretlivesofdata.com/raft/，https://raft.github.io/raftscope/index.html

2.Raft如何保证CP？

1.投票选举中集群不对外提供服务
2.当一个候选人的票数必须超过一半时才会升为Leader
如下图当5个节点，三次Leader选举的节点(S1、S2、S3)都挂掉后，集群中选不出Leader

3.Leader收到用户请求，同步数据时必须得到一半以上follower确认，才能提交数据

从Raft实现的数据一致性来看，不是一种强一致性，因为只要满足一半节点数据一致就算一致了，不是全部节点数据一致。

和Raft类似的还有Zookeeper提出的zab协议也可以实现CP，大家可以比较下两者的异同。

3.Base理论—A和P能否取中间

1.为什么提出？

对于互联网场景下，主机众多、部署分散，集群规模越来越大，节点故障、网络故障是常态，并且还要保证可用性达到99.9999%。所以我们大多都采取AP模式，舍弃C。

但是在不同业务场景下，又要要求一致性，比如金融、银行、电商等，于是就提出了Base理论。

2.理论概述

Base理论是对CAP中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性（CAP中C就是强一致），但根据业务特点采用适当的方式来使系统达到最终一致性。

强一致性、弱一致性、最终一致性

• 强一致性：对于关系型数据库，要求更新过的数据能被后续访问都能看到，为强一致性
• 弱一致性：能容忍后续访问时部分或全部访问不到，为弱一致性
• 最终一致性：如果经过一端时间后要求能访问到更新后的数据，为最终一致性

弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

3.Base理论三要素

1.基本可用（Basically Available）
基本可用是指分布式系统在出现故障时，允许损失部分可用性，保证核心可用
如电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也只能提供降级服务。这就是损失部分功能的可用性

2.软状态（Soft state）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少会有三个副本（如mysql和redis），允许不同节点副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现

3.最终一致性（Eventually consistent）
指系统中所有数据副本经过一定时间后，最终能够达到一致的状态。

一般来说，互联网处理高并发的理论是基于Base理论的，如缓存、消息中的数据都是保证和mysql数据的最终一致性。

三、分布式理论和分布式事务的关系（重点）

那么能否依据上面的分布式理论解决分布式事务呢？接着拿上面下单的业务举例，我们必须保证一个大事务中的三个小事务同时成功，同时失败

public void bussiness(){
	//扣减库存
	httpclient.storage();
	//生成订单
	httpclient.order();
	//减去金额
	httpclient.account();
}
1
2
3
4
5
6
7
8

在减去用户金额时失败，那么如何库存和订单数据立即回滚则满足CAP，如果是在一段时间内回滚，达到数据最终一致性则满足Base。现在主流的分布式解决方案也是依据这两个协议走的。

下一篇分享分布式事务解决方案