分布式基础理论与知识

分布式系统

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。

优点

1.可拓展性

又叫可伸缩性，主要强调“伸”；偶尔也强调“缩”。
在资源和用户数较大增长的情况下，系统性能仍能维持甚至提高。
通常表现为：
利用硬件环境可以为更多的用户服务、而且响应更快
通常通过增加更多/更快的处理器，能实现更可靠、更完善的服务

2.高性能

分布系统中的各个组成部分可以在并发的过程中被执行。这样一个复杂的问题可以拆解成多个简单的小问题，从而提升系统的吞吐量。
通常表现在：
多个用户同时访问（和更新）资源
多个服务进程同时运行，相互协作

3.高可用

一台服务器的系统崩溃不会影响到其他的服务器。从而可以保障系统的高可用。
通常表现在：
服务模块化，订单系统、商品系统互不影响

缺点

1.复杂度高

由于分布在多台服务器上，出现故障的时候排除和诊断问题难度较高。

2.成本高

在运维和硬件成本上成本增高，服务器之间需要通过网络通信，网络基础设置问题，包括传输、高负载、信息丢失问题。

3.服务的可用性要求高

由于是分布式，不在同一台机器上，我们需要实现分布式数据一致性和服务的可用性。而这个过程是通过网络传输的，而网络存在很复杂的状态，尤其是弱网或断网的情况。这样就导致了这个难度非常大，往往需要在数据一致性和可用性上做一个平衡。
这就是下面我们要讨论的如何保证服务的高可用。首先我们先从一些理论基础开始。

CAP

CAP理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

一致性（Consistency）

Consistency means that all clients see the same data at the same time, no matter which node they connect to. For this to happen, whenever data is written to one node, it must be instantly forwarded or replicated to all the other nodes in the system before the write is deemed ‘successful.’
上面英文取自IBM,大意为：客户端看到在同一时间看到的的同一个数据总是一样的，而不管链接了哪个节点。为了实现他：通常，向某个节点写数据时，要保证其他的节点也写或者时复制完成，再告诉客户端成功。

可用性（Availability）

Availability means that that any client making a request for data gets a response, even if one or more nodes are down. Another way to state this—all working nodes in the distributed system return a valid response for any request, without exception.
上面英文取自IBM,大意为：无论挂掉了一个节点还是多个，客户端总是能得到一个响应，不是一个异常。

分区容错性（Partition tolerance）

A partition is a communications break within a distributed system—a lost or temporarily delayed connection between two nodes. Partition tolerance means that the cluster must continue to work despite any number of communication breakdowns between nodes in the system.
上面英文取自IBM,大意为：节点之间不能通信或者延迟通信，依然能对外提供服务。

CP 与 AP的选择

一般来说基础数据、涉及到钱财这样不能有一丝让步的场景，C必须保证。对于其他场景，比较普遍的做法是选择可用性和分区容错性，舍弃强一致性，退而求其次使用最终一致性来保证数据的安全。

BASE

BASE定理的核心内容是：即使无法做到强一致性（Strong Consistency），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。CAP中提到的一致性是强一致性，所谓“牺牲一致性”指牺牲强一致性保证弱一致性。
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

基本可用（Basically Available）

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即：保证核心可用。

软状态（ Soft State）

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

最终一致性（ Eventual Consistency）

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
通过上面软状态的终极目标是最终一致性。如，分布式存储的副本数最终会达到稳定状态。 DNS是一个典型的最终一致性系统。

分布式事务

分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。

上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。

分布式一致性问题的解决思路有两种，一种是分布式事务，一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决问题，而业务规避其实通过解决出问题的地方(解决提问题的人)。其实在真实业务场景中，如果业务规避不是很麻烦的前提，最优雅的解决方案就是业务规避。

分布式事务分类

分布式事务实现方案从类型上去分刚性事务、柔型事务：
刚性事务满足CAP的CP理论
柔性事务满足BASE理论（基本可用，最终一致）

刚性事务

刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务。
原则：刚性事务满足足CAP的CP理论
刚性事务指的是，要使分布式事务，达到像本地式事务一样，具备数据强一致性，从CAP来看，就是说，要达到CP状态。
刚性事务：XA 协议（2PC、JTA、JTS）、3PC，但由于同步阻塞，处理效率低，不适合大型网站分布式场景。

柔性事务

柔性事务指的是，不要求强一致性，而是要求最终一致性，允许有中间状态，也就是Base理论，换句话说，就是AP状态。
与刚性事务相比，柔性事务的特点为：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。
柔性事务分为：
补偿型:通过定时扫描有问题的数据，进行补偿，直到对方给与终结状态响应。
异步确保型：主要通过MQ，来通知。
最大努力通知型：通过定时扫描有问题的数据，进行通知，直到对方给与终结状态响应。
柔型事务：TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息）

2PC（标准XA模型）

2PC即Two-Phase Commit，二阶段提交。
顾名思义，2PC分为两个阶段处理，阶段一：提交事务请求、阶段二：执行事务提交;
如果阶段一超时或者出现异常，2PC的阶段二：中断事务

阶段一：提交事务请求
事务询问。协调者向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者进行响应；
执行事务。各参与者节点，执行事务操作，并将Undo和Redo操作计入本机事务日志；
各参与者向协调者反馈事务问询的响应。成功执行返回Yes，否则返回No。
阶段二：执行事务提交

执行事务提交
所有参与者reply Yes，那么执行事务提交。
发送提交请求。协调者向所有参与者发送Commit请求；
事务提交。参与者收到Commit请求后，会正式执行事务提交操作，并在完成提交操作之后，释放在整个事务执行期间占用的资源；
反馈事务提交结果。参与者在完成事务提交后，写协调者发送Ack消息确认；
完成事务。协调者在收到所有参与者的Ack后，完成事务。

阶段二：中断事务
事情总会出现意外，当存在某一参与者向协调者发送No响应，或者等待超时。协调者只要无法收到所有参与者的Yes响应，就会中断事务。

发送回滚请求。协调者向所有参与者发送Rollback请求；
回滚。参与者收到请求后，利用本机Undo信息，执行Rollback操作。并在回滚结束后释放该事务所占用的系统资源；
反馈回滚结果。参与者在完成回滚操作后，向协调者发送Ack消息；
中断事务。协调者收到所有参与者的回滚Ack消息后，完成事务中断。

3PC

针对2PC的缺点，研究者提出了3PC，即Three-Phase Commit。
作为2PC的改进版，3PC将原有的两阶段过程，重新划分为CanCommit、PreCommit和do Commit三个阶段。

阶段一：CanCommit
事务询问。协调者向所有参与者发送包含事务内容的canCommit的请求，询问是否可以执行事务提交，并等待应答；
各参与者反馈事务询问。正常情况下，如果参与者认为可以顺利执行事务，则返回Yes，否则返回No。

阶段二：PreCommit
在本阶段，协调者会根据上一阶段的反馈情况来决定是否可以执行事务的PreCommit操作。有以下两种可能：
执行事务预提交
发送预提交请求。协调者向所有节点发出PreCommit请求，并进入prepared阶段；
事务预提交。参与者收到PreCommit请求后，会执行事务操作，并将Undo和Redo日志写入本机事务日志；
各参与者成功执行事务操作，同时将反馈以Ack响应形式发送给协调者，同事等待最终的Commit或Abort指令。

中断事务
加入任意一个参与者向协调者发送No响应，或者等待超时，协调者在没有得到所有参与者响应时，即可以中断事务：
发送中断请求。 协调者向所有参与者发送Abort请求；
中断事务。无论是收到协调者的Abort请求，还是等待协调者请求过程中出现超时，参与者都会中断事务；

阶段三：doCommit
在这个阶段，会真正的进行事务提交，同样存在两种可能。
执行提交
发送提交请求。假如协调者收到了所有参与者的Ack响应，那么将从预提交转换到提交状态，并向所有参与者，发送doCommit请求；
事务提交。参与者收到doCommit请求后，会正式执行事务提交操作，并在完成提交操作后释放占用资源；
反馈事务提交结果。参与者将在完成事务提交后，向协调者发送Ack消息；
完成事务。协调者接收到所有参与者的Ack消息后，完成事务。

中断事务
在该阶段，假设正常状态的协调者接收到任一个参与者发送的No响应，或在超时时间内，仍旧没收到反馈消息，就会中断事务：
发送中断请求。协调者向所有的参与者发送abort请求；
事务回滚。参与者收到abort请求后，会利用阶段二中的Undo消息执行事务回滚，并在完成回滚后释放占用资源；
反馈事务回滚结果。参与者在完成回滚后向协调者发送Ack消息；
中端事务。协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

3PC主要解决的单点故障问题：
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞， 因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。

参考

https://zhuanlan.zhihu.com/p/364931269
https://www.ibm.com/cloud/learn/cap-theorem
https://article.itxueyuan.com/amrJvv