Zookeeper 思维导图模板_ProcessOn思维导图、流程图

定义

A Distributed Coordination Service for Distributed Applications.

特性

顺序一致性

从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到ZooKeeper中去。

原子性

数据要么成功，要么失败，不会局部化。

单一视图

无论客户端连接的是哪个ZooKeeper服务器，其看到的数据都是一致的。

可靠性

一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。

实时性

通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

设计目标

简单的数据模型

基本数据模型

可以构建集群

顺序访问

高性能

ZooKeeper的基本概念

集群角色

Leader

为客户端提供读写服务

Follower

Follower和Observer都能提供读服务，Observer不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提高集群的读性能。

Observer

Session会话

数据节点ZNode

树形结构

每个节点称为ZNode，可以有子节点

每个节点分为临时节点和永久节点，临时节点在客户端断开后（会话失效）消失

每个节点还有一个属性：SEQUENTIAL，一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

每个节点都有各自的版本号，可以通过命令行显示节点信息

每个节点数据发生变化，那么该节点的版本号会累加（乐观锁）

删除/修改过时节点，版本号不匹配会报错

每个节点存储的数据不宜过大，几K即可

节点可以设置权限

版本

每个节点都有一个Stat的数据结构。Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。

Watcher

针对每个节点的操作，都会有一个监督者watcher

当监控的某个节点发生变化，触发watcher事件

watcher是一次性的，触发后立即销毁

父节点和子节点的增删改都能触发其watcher事件

Watcher事件类型

创建父节点

NodeCreated

修改父节点数据

NodeDataChanged

删除父节点

NodeDeleted

ls为父节点设置watcher，创建子节点

NodeChildrenChanged

ls为父节点设置watcher，删除子节点

NodeChildrenChanged

ls为父节点设置watcher，修改子节点

不触发事件

修改子节点时，如果想要触发事件，需要把子节点当做父节点来修改，即使用相同命令，不用ls

使用场景

统一资源配置

ACL

CREATE：创建子节点的权限。

READ：获取节点数据和子节点列表的权限。

WRITE：更新节点数据的权限。

DELETE：删除子节点的权限。

ADMIN：设置节点ACL的权限。

zk的作用

master节点选举，主节点挂了以后，从节点就会接手工作，并且保证这个节点是唯一的，从而保证集群是高可用的，这就是首脑模式。

统一配置文件管理，即只需要部署一台服务器，则可以把相同的配置文件同步更新到其他所有服务器。

发布与订阅。发布者把数据存在znode上，订阅者读取这个数据。

提供分布式锁。

集群管理，集群中保证数据的强一致性。

ZooKeeper和Eureka的区别

ZooKeeper保证CAP中CP

Eureka保证CAP中AP

领导者选举机制

分布式架构

分布式系统

分布性

对等性

并发性

缺乏全局时钟

故障总是会发生

分布式环境的各种问题

通信异常

网络分区（脑裂）

三态

成功

失败

超时

由于网络原因，该请求（消息）并没有被成功地发送到接收方，而是在发送过程就发生了消息丢失现象。

该请求（消息）成功的被接收方接收后，并进行了处理，但是在将响应反馈给发送方的过程中，发生了消息丢失现象。

节点故障

ACID

原子性（Atomicity）

一致性（Consistency）

隔离性（Isolation）

未提交读（Read Uncommitted）

提交读（Read Committed）

可重复读（Repeatable Read）

串行化（Serializable）

持久性（Durability）

分布式事务

CAP理论

C-Consistency

P-Partition tolerance

A-Availability

CP

AP

BASE理论

Basically Available（基本可用）

Soft state（软状态）

Eventually consistent（最终一致性）

因果一致性

读己之所写

会话一致性

单调读一致性

单调写一致性

一致性协议

3PC

阶段一：CanCommit

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

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

阶段二：PreCommit

执行事务预提交（Yes）

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

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

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

中断事务（No）

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

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

阶段三：doCommit

执行提交

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

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

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

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

中断事务

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

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

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

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

注意

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。）

优点

降低了阻塞的范围。协调者在询问的时候并不锁定资源（阶段一），除非所有人都同意了，才开始锁资源（阶段二）。

解决单点问题。即使协调者挂了，参与者也会在超时之后进行提交。

缺点

一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

Paxos

角色

Proposer

Acceptor

Learner

选定提案

阶段一

Proposer选择一个提案编号Mn，然后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。

如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的所有Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于Mn的提案。

阶段二

如果Proposer收到来自半数以上的Acceptor对于其发出的编号为Mn的Prepare请求的响应，那么它就会发送一个针对[Mn，Vn]提案的Accept请求给Acceptor。<b>注意，Vn的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么它就是任意值。</b>

如果Acceptor收到这个针对[Mn，Vn]提案的Accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求做出响应，它就可以通过这个提案。