关于springboot:常见分布式理论CAPBASE和一致性协议

一、CAP 实践与 BASE 实践：

1、什么是 CAP 实践：

• C：Consistency 一致性：指强一致性，分布式系统中的所有节点在同一时刻具备同样的值、都是最新的数据正本，一致性保障了不论向哪台服务器写入数据，其余的服务器能实时同步数据
• A：Availability 可用性：局部结点宕机不影响整个集群对外提供服务，每次向未故障的节点发送申请，服务节点总能保障在无限的工夫内解决实现并进行响应，从用户角度来看就是不会呈现零碎操作失败或者拜访超时等问题，然而零碎外部可能会呈现网络提早等问题
• P：Partition Tolerance 分区容错性：因为网络的问题盘根错节，如果某个节点因为网络等问题造成数据不统一，或者数据提早很久才同步过去，尽管会影响局部节点数据的时效性，然而服务节点仍然是可用的，分布式系统要能容忍这种状况的，也就是说，只管网络上有局部音讯失落，但零碎依然可持续工作。

分布式系统中，CAP 是无奈同时满足的，只能满足 CAP 中的两种，因而在设计分布式架构时，必须做出取舍，而对于分布式系统，分区容忍性是根本要求，必须要满足，否则就失去了价值。因为是节点宕机和网络故障大概率事件，很难防止，而当呈现这种状况时，不可能同时放弃一致性和可用性，所以设计分布式系统，就是在一致性和可用性之间取一个均衡。

那为什么说在 P 满足的状况下，为什么说 CA 不能同时满足呢？咱们来通过假如看一看，如果 CA 同时满足会怎么样：

（1）假如当初要求满足 C（一致性），那么就是说所有的节点在某一刻提供的数据都必须统一，咱们晓得在 P 的状况，是不可能保障的，要保障的话，就只能把其余节点全副干掉，比方禁止读写，那这其实就是和 A 是相悖的（某些节点尽管提早，然而节点自身可用）

（2）假如当初要求满足 A（可用性），那么就是说只有节点自身没什么问题，就能够对外提供服务，哪怕有点数据提早，很显著这必定是和 C 相悖的。

2、一致性的类别：

CAP 是分布式事务处理的实践根底，在分布式事务的最终解决方案中个别抉择就义一致性来换取可用性和分区容错性，但这里的“就义一致性”并不是齐全放弃数据的一致性，而是放弃 强一致性 而换取 弱一致性。一致性个别能够分为以下三种：

（1）强一致性：在任意时刻，所有节点中的数据是一样的，零碎中的某个数据被胜利更新后，后续任何对该数据的读取操作都将失去更新后的值。比方传统数据库的事务个性 ACID，就是谋求强一致性模型。

一个集群须要对外部提供强一致性，就务必会损耗可用性，只有集群外部某一台服务器的数据产生了扭转，那么就须要期待集群内其余服务器的数据同步实现后，能力失常的对外提供服务。

（2）弱一致性：零碎中的某个数据被更新后，后续对该数据的读取操作可能失去更新后的值，也可能是更改前的值，但即便过了不统一工夫窗口后，后续对该数据的读取也不肯定是最新值。

（3）最终一致性：是弱一致性的非凡模式，尽管不保障在任意时刻任意节点上的同一份数据都是雷同的，但通过一段时间后，所有服务节点间的数据最终会达到统一的状态

弱一致性即便过了不统一工夫窗口，后续的读取也不肯定能保障统一，而最终一致性过了不统一窗口后，后续的读取肯定保障统一。

3、什么是 BASE 实践：

BASE 实践是指，Basically Available（根本可用）、Soft-state（软状态）、Eventual Consistency（最终一致性），是基于 CAP 定理演变而来，是对 CAP 中一致性和可用性衡量的后果。核心思想是即便无奈做到强一致性，但每个业务依据本身的特点，采纳适当的形式来使零碎达到最终一致性。

• BA 根本可用：指分布式系统在呈现故障的时候，容许损失局部可用性，保障外围可用。但不等价于不可用。比方：搜索引擎 0.5 秒返回查问后果，但因为故障，2 秒响应查问后果；网页拜访过大时，局部用户提供降级服务等。
• 软状态：软状态是指容许零碎存在中间状态，并且该中间状态不会影响零碎整体可用性，即容许零碎在不同节点间正本同步的时候存在延时。
• 最终一致性：零碎中的所有数据正本通过肯定工夫后，最终可能达到统一的状态，不须要实时保证系统数据的强一致性。

很多时候咱们并不要求数据的强一致性，而 BASE 通过就义强一致性来取得更好的可用性，所以 BASE 实践的适用性更宽泛，比方更适宜面向的是大型高可用可扩大的分布式系统

柔性事务和刚性事务：柔性事务满足 BASE 实践（根本可用，最终统一），刚性事务满足 ACID 实践。

二、一致性协定：

1、Gossip 协定：

参考文章：https://juejin.cn/post/7023918632216297479

集群往往是由多个节点独特组成的，当一个节点退出集群或者一个节点从集群中下线的时候，都须要让集群中其余的节点晓得，这样能力将数据信息分享给新节点而疏忽下线节点。

如上图，A、B、C 节点之间能够相互传递音讯，然而 D 节点在下线之后会被播送通知其余存活节点。这样的播送协定就是明天要说 Gossip 协定，Gossip 协定也叫 Epidemic 协定（流行病协定），当一个音讯到来时，通过 Gossip 协定就能够像病毒一样感化全副集群节点。Gossip 的过程是由一个种子节点发动的，当一个种子节点有信息须要同步到网络中的其余节点时，它会随机的抉择四周几个节点散播音讯，收到音讯的节点也会反复该过程，直至最终网络中所有的节点都收到了音讯。这个过程可能须要肯定的工夫，所以不能保障某个工夫点所有的节点都有该条音讯，然而实践上最终所有节点都会收到音讯，因而它是一个最终一致性协定。

Gossip 协定的特点：

• （1）Gossip 协定是周期性散播音讯，每隔一段时间流传一次
• （2）被感化的节点，每次能够持续散播 N 个节点
• （3）每次散播音讯时，都会抉择尚未发送过的节点进行散播，不会向发送的节点散播
• （4）同一个节点可能会收到反复的音讯，因为可能同时多个节点正好向它散播
• （5）集群是去中心化的，节点之间都是平等的
• （6）音讯的散播不必等接管节点的 ack，即音讯可能会失落，然而最终应该会被感化

上面咱们来看个例子：

• ① 种子节点是 A
• ② A 节点抉择 B、C 节点进行散播
• ③ C 散播到 D，B 散播 D 和 E，能够发现 D 收到两次
• ④ D 散播到 F，最终整个网络都同步到了音讯

Gossip 有点相似图的广度优先遍历算法，个别用于网络拓扑构造信息的分享和保护，比方 Redis 集群中节点的运行状态就是应用 Gossip 协定进行传递的。

2、Raft 一致性协定：

参考文章：https://baijiahao.baidu.com/s?id=1693824822611080380&wfr=spid…

分布式协定的难点之一就是数据的一致性，当由多个节点组成的集群中只有一个节点收到数据，咱们就算胜利的话，危险太大，当要求所有节点都收到数据才响应胜利，性能又太差，所以个别会在数据的平安和性能之间做个折中，只有保障绝大部分节点同步数据胜利，咱们就算胜利。比拟出名的一致性算法有 Raft 算法，被广泛应用于许多中间件中，接下来咱们就看看 Raft 算法是实现分布式系统的不同节点间的数据一致性的，也就是说客户端发送申请到任何一个节点都能收到统一的返回，当一个节点出故障后，其余节点依然能以已有的数据失常进行。

首先介绍下在 Raft 算法中，几种状况下每个节点对应的角色：

（1）Leader 节点：同大多数分布式中的 Leader 节点一样，所有数据的变更都须要先通过 Leader

（2）Follower 节点：Leader 节点的追随者，负责复制数据并且在选举时候投票的节点

（3）Candidate 候选节点：参加选举的节点，就是 Follower 节点参加选举时会切换的角色

Raft 算法将一致性问题合成为两个的子问题，Leader 选举 + 数据日志的复制：

2.1、Leader 选举：

零碎在刚开始的时候，所有节点都是 Follower 节点，这时都有机会参加选举，将本人变成 Candidate，变成 Candidate 的节点会先投本人 1 票，同时通知其它节点，让它们来投票，当拿到超过半数以上的投票时，以后 Candidate 就会变成 Leader 节点。然而如果每个 Follower 节点都变成 Candidate 那么就会陷入有限的死循环，于是每个 Follower 都一个定时器，并且定时器的工夫是随机的，当某个 Follower 的定时器工夫走完之后，会确认以后是否存在 Leader 节点，如果不存在再把本人变成 Candidate。

• ① 因为 A 节点的定时器工夫最短（10ms），所以 A 会成为 Candidate。
• ② A 投本人一票，并通知 B、C 来投票，B、C 也投出本人的批准票后，A 就会变成 Leader 节点，同时会记录是第 M 任。这个 M 是做版本校验的，比方一个编号是 10 的节点，收到了一个编号是 9 的节点的投票申请，那么就会回绝这个申请。

在 Leader 节点选举进去当前，Leader 节点会一直的发送心跳给其它 Follower 节点证实本人是活着的，其余 Follower 节点在收到心跳后会清空本人的定时器，并回复给 Leader，因为此时没必要触发选举了。

如果 Leader 节点在某一刻挂了，那么 Follower 节点就不会收到心跳，因而在定时器到来时就会触发新一轮的选举，流程还是一样。然而如果凑巧两个 Follower 都变成了 Candidate，并且都失去了同样的票数，那么此时就会陷入僵局，为了突破僵局，这时每个 Candidate 都会随机推延一段时间再次申请投票，当然个别状况下，就是先来先得，优先跑完定时器的 Candidate 实践成为 Leader 的概率更大。

选举流程大抵如上，接下来咱们来看看数据日志的复制。

2.2、数据日志的复制：

当 Leader 节点收到客户端 Client 的申请变更时，会把变更记录到 log 中，而后 Leader 会将这个变更随着下一次的心跳告诉给 Follower 节点，收到音讯的 Follower 节点把变更同样写入日志中，而后回复 Leader 节点，当 Leader 收到大多数的回复后，就把变更写入本人的存储空间，同时回复 client，并通知 Follower 利用此 log。至此，集群就变更达成了共识。

（1）失常状况下的日志复制：

• ① 一开始，Leader 和两个 Follower 都没有任何数据。
• ② 客户端发送申请给 Leader，贮存数据“sally”，Leader 先将数据写在本地日志，这时候数据状态还是 Uncommitted (还没最终确认，应用红色示意)
• ③ Leader 给两个 Follower 节点发送 AppendEntries 申请，数据在 Follower 上没有抵触，则将数据临时写在本地日志，Follower 的数据也还是 Uncommitted
• ④ Follower 将数据写到本地后，返回 OK。Leader 收到后胜利返回，只有收到的胜利的返回数量超过半数 (蕴含 Leader)，Leader 将数据“sally”的状态改成 Committed。(这个时候 Leader 就能够返回给客户端了)
• ⑤ Leader 再次给 Follower 发送 AppendEntries 申请，收到申请后，Follower 将本地日志里 Uncommitted 数据改成 Committed。这样就实现了整个复制日志的过程，三个节点的数据是统一的，

（2）Network Partition 网络分区状况下日志复制：

在 Network Partition 的状况下，局部节点之间没方法相互通信，Raft 也能保障这种状况下数据的一致性

① 一开始有 5 个节点处于同一网络状态下，如下图：

② Network Partition 将节点分成两边，一边有两个节点，一边三个节点：

③ 两个节点这边曾经有 Leader 了，来自客户端的数据“bob”通过 Leader 同步到 Follower。

④ 只有两个节点，少于 3 个节点，所以“bob”的状态仍是 Uncommitted。所以在这里，服务器会返回谬误给客户端

⑤ 另外一个 Partition 有三个节点，进行从新选主。

⑥ 客户端数据“tom”发到新的 Leader2，并通过和上节网络状态下类似的过程，同步到另外两个 Follower；但因为这个 Partition 有 3 个节点，超过半数，所以数据“tom”都 Commit 了。

⑦ 网络状态复原，5 个节点再次处于同一个网络状态下。然而这里呈现了数据抵触“bob” 和“tom”

⑧ 三个节点的 Leader2 播送 AppendEntries

⑨ 两个节点 Partition 的 Leader 主动降级为 Follower，因为这个 Partition 的数据“bob”没有 Commit，返回给客户端的是谬误，客户端晓得申请没有胜利，所以 Follower 在收到 AppendEntries 申请时，能够把“bob“删除，而后同步”tom”，通过这么一个过程，就实现了在 Network Partition 状况下的复制日志，保障了数据的一致性。