Zookeeper基础

最新推荐文章于 2022-08-17 16:29:17 发布

今天风有点大

最新推荐文章于 2022-08-17 16:29:17 发布

阅读量143

点赞数 1

分类专栏： Zookeeper 文章标签： zookeeper

本文链接：https://blog.csdn.net/qq_42950979/article/details/120746679

版权

Zookeeper 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Zookeeper基础

CAP和BASE理论

CAP理论

CAP 理论指出对于一个分布式计算系统来说，不可能同时满足一致性（C:Consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）这三个基本需求，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择。

一致性

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

分区容错性

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

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

放弃CAP定理	说明
放弃P	如果希望能够避免出现分区容错性问题，一种简单做法是将所有的数据都放在一个分布式节点上。放弃P的同时意味着放弃了系统的可扩展性。
放弃A	一旦系统遇到网络分区或其他故障时，name收到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用。
放弃C	事实上，放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统无法保证数据保持实时的一致性，引入一个时间窗口的概念。

在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择。

BASE理论

BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。

基本可用

在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。

响应时间上的损失：
功能上的损失

软状态

允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。

最终一致性

data replications 经过一段时间达到一致性。

最终一致性是一种特殊的弱一致性：系统能保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。

在实际工程实践中，最终一致性存在以下五类主要变种：因果一致性；读己之所写；会话一致性：；单调读一致性：；单调写一致性：

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

一致性协议

设计一个分布式系统必定会遇到一个问题—— 因为分区容忍性（partition tolerance）的存在，就必定要求我们需要在系统可用性（availability）和数据一致性（consistency）中做出权衡 。这就是著名的 CAP 定理。

解决分布式一致性问题，有二阶段提交协议、三阶段提交协议和Paxos算法。

2PC（两阶段提交）

2PC，是Two-Phase-Commit的缩写，即二阶段提交，是计算机网络尤其是数据库领域内，为了是基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。

目前，绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。

协议说明

顾名思义，二阶段提交协议是将事务的提交过程分成了两个阶段来进行处理。

阶段一：提交事务请求

整个过程近似是协调者组织各参与者对一次事务操作的投票表态过程，因此也成为“投票阶段”。

1.事务询问。

协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作(vote)，并开始等待各参与者的响应。

2.执行事务。

各参与者执行事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）

3.各参与者向协调者反馈事务询问的相应。

如果参与者成功执行事务操作，那么就反馈给协调者YES响应，表示事务可以执行；如果参与者的事务操作实际执行失败，那么久反馈给协调者No响应，表示事务不可以执行。

阶段二：执行事务提交

在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作。正常情况下，包含以下两种可能。

执行事务提交

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q6EiWHIr-1634113606051)(F:\Typora images\success-163410911296916.png)]

假如协调者从所有的参与者获得的反馈都是Yes相应，那么就会执行事务提交。

1.发送提交请求

协调者向所有参与者节点发出Commit请求。

2.事务提交。

参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源，

3.反馈事务提交结果。

参与者在完成事务提交之后，向协调者发送Ack消息。

4.完成事务。

协调者接收到所有参与者反馈的Ack消息后，完成事务。

中断事务

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D9w1jZai-1634113606055)(F:\Typora images\fail-163410921299117.png)]

假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无接收到所有参与者的反馈响应，那么就会中断事务。

1.发送回滚请求。

协调者向所有参与者节点发出Rollback请求。

2.事务回滚。

参与者接收到Rollback请求后，会利用其在一阶段中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

3.反馈事务回滚结果。

参与者在完成事务回滚之后，向协调者发送Ack消息。

4.中断事务。

协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

简单地讲，二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务采用先尝试后提交的处理方式，因此可以将二阶段提交看作一个强一致性的算法。

优缺点

二阶段提交协议的优点是：原理简单，实现方便，

二阶段提交协议的缺点：同步堵塞、单点问题、脑裂、太过保守。

同步阻塞

在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于堵塞状态。

单点问题

一旦协调者出现问题，那么整个二阶段提交流程将无法运转，更严重的是，如果协调者是在阶段二出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。

数据不一致

在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求。于是，这部分收到了Commit请求的参与者就会进行事务的提交，而其他没有收到Commit请求的参与者则无法进行事务提交。

太过保守

二阶段提交协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

3PC（三阶段提交）

二阶段协议在实际运行过程中可能存在诸如同步阻塞、协调者的单点问题、脑裂和太过保守的容错机制等缺陷。

协议说明

3PC，是Three-Phase Commit的缩写，即三阶段提交，其将二阶段提交协议的“提交事务请求”过程一分为二，形成了由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。

阶段一：CanCommit

1 .事务询问。

协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2 .各参与者向协调者反馈事务询问的响应。

参与者在接收到来自协调者的canCommit请求后，正常情况下，如果其自身认为可以顺利执行事务，那么会反馈Yes响应，并进入预

备状态，否则反馈No响应。

阶段二：PreCommit

在阶段二中,协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能。

执行事务预提交

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务预提交。

1 .发送预提交请求。

协调者向所有参与者节点发出preCommit的请求，并进入Prepared阶段。

2 .事务预提交。

参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。

3.各参与者向协调者反馈事务执行的响应。

如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交(commit)或中止(abort)。

中断事务

假如任何一个参与者向协调者反馈了 No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事

务。
1 .发送中断请求。

协调者向所有参与者节点发出abort请求。

2 .中断事务。

无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。

阶段三：doCommit

该阶段将进行真正的事务提交,会存在以下两种可能的情况。

执行提交

1.发送提交请求。

进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状

态，并向所有的参与者发送doCommit请求。

2 .事务提交。

参与者接收到doCommil请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

3 .反馈事务提交结果。

参与者在完成事务提交之后，向协调者发送Ack消息。

4 .完成事务。

协调者接收到所有参与者反馈的Ack消息后,完成事务。

中断事务

进入这一阶段，假设协调者处f正常工作状态,并且有任意一个参与者向协调者反馈了 No响应,或者在等待超时之后，协调者尚无法接

收到所有参与者的反馈响应，那么就会中断事务。

1 .发送中断请求。

协调者向所有的参与者节点发送abort请求。

2 .事务回滚。

参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成同潦之后释放在整个事务执行期间

占用的资源。

3 .反馈事务回滚结果。

参与者在完成事务回滚之后，向协调者发送Ack消息。

4 .中断事务。

协调者接收到所有参与者反馈的Ack消息后，中断事务。

需要注意的是，一旦进入阶段三，可能会存在以下两种故障。

协调者出现问题。
协调者和参与者之间的网络出现故障。

无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者的doCommit或是 abort请求，针对这样的异常情况，参与者都

会在等待超时之后，继续进行事务提交。

优缺点

三阶段提交协议的优点：相较于二阶段提交协议，三阶段提交协议最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故

障后继续达成一致。

三阶段提交协议的缺点：三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到PreCommit消息后，如果网

络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数

据的不一致性。

Paxos算法

Paxos算法需要解决的是在可能发生机器宕机或网络异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

Paxos 算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一，其解决的问题就是在分布式系统中如何就某个值（决议）达成一致 。

在 Paxos 中主要有三个角色，分别为 Proposer提案者、Acceptor表决者、Learner学习者。Paxos 算法和 2PC 一样，也有两个阶段，分别为 Prepare 和 accept 阶段。

prepare 阶段

Proposer提案者：负责提出 proposal，每个提案者在提出提案时都会首先获取到一个 具有全局唯一性的、递增的提案编号N，即在整个集群中是唯一的编号 N，然后将该编号赋予其要提出的提案，在第一阶段是只将提案编号发送给所有的表决者。

Acceptor表决者：每个表决者在 accept 某提案后，会将该提案编号N记录在本地，这样每个表决者中保存的已经被 accept 的提案中会存在一个编号最大的提案，其编号假设为 maxN。每个表决者仅会 accept 编号大于自己本地 maxN 的提案，在批准提案时表决者会将以前接受过的最大编号的提案作为响应反馈给 Proposer 。

paxos第一阶段

accept 阶段

当一个提案被 Proposer 提出后，如果 Proposer 收到了超过半数的 Acceptor 的批准（Proposer 本身同意），那么此时 Proposer 会给所有的 Acceptor 发送真正的提案（你可以理解为第一阶段为试探），这个时候 Proposer 就会发送提案的内容和提案编号。

表决者收到提案请求后会再次比较本身已经批准过的最大提案编号和该提案编号，如果该提案编号 大于等于 已经批准过的最大提案编号，那么就 accept 该提案（此时执行提案内容但不提交），随后将情况返回给 Proposer 。如果不满足则不回应或者返回 NO 。

paxos第二阶段1

当 Proposer 收到超过半数的 accept ，那么它这个时候会向所有的 acceptor 发送提案的提交请求。需要注意的是，因为上述仅仅是超过半数的 acceptor 批准执行了该提案内容，其他没有批准的并没有执行该提案内容，所以这个时候需要向未批准的 acceptor 发送提案内容和提案编号并让它无条件执行和提交，而对于前面已经批准过该提案的 acceptor 来说 仅仅需要发送该提案的编号 ，让 acceptor 执行提交就行了。

paxos第二阶段2

而如果 Proposer 如果没有收到超过半数的 accept 那么它将会将递增该 Proposal 的编号，然后 重新进入 Prepare 阶段 。

ZAB协议

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

ZooKeeper 在解决分布式数据一致性问题时并没有直接使用 Paxos ，而是专门定制了一致性协议叫做 ZAB(ZooKeeper Atomic Broadcast) 原子广播协议，该协议能够很好地支持 崩溃恢复 。

ZAB 中三个主要的角色，Leader 领导者、Follower跟随者、Observer观察者 。

Leader ：集群中 唯一的写请求处理者 ，能够发起投票（投票也是为了进行写请求）。
Follower：能够接收客户端的请求，如果是读请求则可以自己处理，如果是写请求则要转发给 Leader 。在选举过程中会参与投票，有选举权和被选举权 。
Observer ：就是没有选举权和被选举权的 Follower 。

ZAB 协议包括两种基本模式，分别是 消息广播 和 崩溃恢复 。

消息广播

当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。

崩溃恢复

当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。