概述

在我们设计分布式系统的时候，我们必须要理解掌握的 cap ,base ,2pc ,3pc ,一致性算法 paxos ,一致性协议 raft ，他们起到参考和指引的作用。

CAP理论

CAP定理是加州大学计算机科学家埃里克·布鲁尔提出来的猜想，后来被证明成为分布式计算领域公认的定理。在分布式系统中，指的是相互通过互联网连接并相互共享数据的节点的集合。只能在 一致性（Consistenc） ，可用性（Availability），分区容错性（Partition Tolerance）当中选择其中是2个特性牺牲另外一个。

一致性(Consistenc)：

写操作之后的读操作，必须返回该值。指的是数据的强一致性。

可用性(Availability):

意思是只要收到用户的请求，服务器就必须给出回应。不可出现等待超时404等错误

分区容错性(Partition Tolerance):

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。当出现网络的分区时候，系统还是可用的。
一般来说，分布式系统的网络分区无法避免，只能在 一致性和可用性这二者一个选择。要么AP,要么CP.
参考：http://www.ruanyifeng.com/blog/2018/07/cap.html

8fc88f10f245aba53372532b3cd8eb70.jpeg
0154cc252a8c8f297289140feb9bc3d5.png

BASE理论

BASE是CAP理论在实践中的延伸和补充和妥协。在满足AP的情况下尽可能的满足C。BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。

基本可用(Basically Available)

假设当系统出现不可预知的故障，但还能用但对外提供的是有损服务。可能响应时间上用损失，之前可能0.5s现在可能2s.还有就是可能功能上出现损失，返回用户一个降级的页面或数据。不至于扩散到整个系统的全部瘫痪。

软状态(Soft State)

数据在多个副本之间的数据的强一致性是硬状态。允许出现数据的中间态，而不影响整个系统的使用，也就是允许出现数据的延时。

最终一致性(Eventually Consistent)

可用出现数据在系统间的延时，但不能一直是软状态，要最终数据要一致。这个时间取决与，网络的延时，系统的负载，和数据同步的方案设计等因素。

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

2PC协议

两阶段提交协议是指将事务的提交分为2个阶段，准备阶段（Prepare phase ）和提交阶段（Commit phase）,
它有2个角色，事务的管理者和事务的参与者，事务的管理者负责整个事务的提交和回滚，事务的参与者指负责自己本地事务的提交和回滚。
在计算机关系型数据库中，Mysql 和Oracle 支持2PC 协议。

5371316906b9b6bf47e53ce7bd0147bb.jpg

备注：确认消息也称为ACK消息，是在计算机网上中通信协议的一部分，是设备或是进程发出的消息，回复已收到数据。

优点：简单，方便
缺点：同步阻塞，单点问题 等

同步阻塞：
在第一阶段中，本地事务的排他锁已经起效，如果下边阶段阻塞，会一直持有。在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题：
协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转。更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致
假设当协调者向所有的参与者发送commit请求之后，发生了局部网络异常，或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了commit请求。这将导致严重的数据不一致问题。
容错性不好
如果Ack阶段，协调者没有受到信息，协调者只能通过自身超时机制来判断是否中断事务等。

业界方案：

• XA方案是由 X/Open组织（即现在的 Open Group ）定义的分布式事务处理模型。
• seata方案是阿里中间件团队开发，在XA方案基础上做了创新和优化。

3PC协议

三阶段提交协议是二阶段提交协议的改进版，也叫TCC协议是 Try ,Confrim,Cancel 的缩写。。
相比两阶段提交，TCC解决了几个问题：
同步阻塞，引入了超时机制，超时后进行补偿，并不会像两阶段提交锁定了整个资源，将资源转换为业务逻辑形式，粒度变小。 因为有了补偿机制，可以由业务活动管理器进行控制，保证数据一致性。

try阶段：

是做业务检查（一致性）和资源预留（隔离），此阶段是个初步操作它要和后续的 confrim 阶段一起才可以组成个完整的业务逻辑。

confrim 阶段：

此阶段是确认提交，try 阶段中所有的分支事务都成功之后才进行confrim阶段。通常情况下，采用的TCC，confrim 阶段默认是一定是成功的。如果发生错误，则要引入重试机制和人工处理也就写在业务逻辑里面，

concel阶段：

业务执行错误，需要回滚的时候所要执行的业务逻辑。

seata官网中部分说明：
AT 模式(2PC模式)（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

5371316906b9b6bf47e53ce7bd0147bb.jpg

一致性算法 Paxos

世界上只有一种一致性算法，就是 Paxos。出自一位 Google 大神之口。Paxos 也是出名的 晦涩难懂，推理过程极其复杂。

Paxos 有点类似之前说的 2PC，3PC，但是解决了这两种算法各种硬伤。该算法在很多大厂都得到了工程实践，比如阿里的 OceanBase 的 分布式数据库，底层就是使用的 Paxos 算法。再比如 Google 的 chubby 分布式锁 也是用的这个算法。可见该算法在分布式系统中的地位，甚至于，Paxos 就是 分布式一致性 的代名词。

Paxos 算法是 基于消息传递 且具有 高效容错特性 的一致性算法，目前公认的解决 分布式一致性问题 最有效的算法之一.

一致性协议 Raft

Raft 也是一个 一致性算法，和 Paxos 目标相同。但它还有另一个名字 - 易于理解的一致性算法。Paxos 和 Raft 都是为了实现 一致性 产生的。这个过程如同选举一样，参选者 需要说服 大多数选民 (服务器) 投票给他，一旦选定后就跟随其操作。Paxos 和 Raft 的区别在于选举的 具体过程 不同。