zookeeper

创建节点的会话断开，节点不会自动删除

G

议员总数 = 4集群服务器总数

议员总数 = 1K集群服务器总数

监听上一个节点

跟随者从

Paxos算法-活锁问题（程序一直执行没有结果）

PID = 0数据更改事务ID

node02

ZooKeeper

同步数据的时间

及时响应Availability

PID = 1

是否是第一个节点

居民

ZooKeeper 存储模型

抢优惠券

JVM

议员2

1009998

node01

Znode

PID = 0

ZooKeeper是如何实现自己集群内部数据一致性（二阶段处理）ZooKeeper集群的主节点如何选举（选主流程）

临时节点-e

数据一致Consistency

议员3

CAP协议和BASE理论

我接受你的提议

持久顺序节点-s

yes

当系统发生故障或流量激增，牺牲部分服务保证基本服务可用必须大于集群二分之一服务器写入

是否创建成功

F

Paxos算法-拜占庭将军问题（1.消息不能被篡改 2.节点要相互信任）

添加监听器

分区容错Partition tolerance

/lock00000000001

我接受

写请求

K: Znode名称V: Znode的值（可选）

BASE理论

Paxos算法-最终模式（奇数+有主模式）

最终模型：奇数台 + 有主模型 + 角色：1.默认投票给议员编号最大的节点——快速选主2.选主需要过滤PID与公共PID不相同的节点——确保数据完整3.选主投票机制，票数过半为主——解决出现多主问题吧（脑裂问题）4.选主结束后主要将自身数据进行广播——解决数据丢失问题角色：领导者：所有提议发起（客户端的写请求，数据更改的操作），广播跟随者：参与到提议的响应和选主的投票过程中，转发客户端写请求到领导者，响应客户端读请求观察者：只响应客户端读请求，转发客户端请求到领导者，不参与提议的响应和选主的投票过程

小岛（集群）

总统（领导者）主

ZooKeeper在大数据中扮演的角色是如何帮助大数据其他组件完成选主

PID = 1数据更改事务ID

服务限流、服务降级、服务熔断......

CAP协议

1.发起提议2.发起广播3.参与选主4.对外提供读服务

Paxos算法-工作流程

议员2（服务器）

Paxos 描述了这样一个场景：- 有一个叫做 Paxos 的小岛(Island)上面住了一批居民(Islander)；- 岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)；- 议员的总数(Senator Count)是确定的，不能更改；- 岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退；- 每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效(少数服从多数)；- 每个议员只会同意大于当前编号的提议，包括已生效的和未生效的；- 如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上记录的编号，他会不断更新这个编号；- 整个议会不能保证所有议员记事本上的编号总是相同的；- 现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。

议员...（服务器）

议员4

Paxos算法-总结

创建成功

Paxos算法

no

Redis是AP架构访问即响应

第三种：确保公平，通过临时顺序节点实现分布式锁

软状态（少数服从多数）Soft

议员998（服务器）

1号提议：电费2元一度

议员1（服务器）

事务编号

消息传递

内部KV文件系统

ZooKeeper 模仿了 Linux 文件系统， 内部是一个 KV 的文件系统，K 是目录但在ZooKeeper中叫Znode，V 是 Znode 的值Znode 的名称同一级目录下是唯一的

两种模式

监听机制：节点1监听节点2，在节点2发生任何操作时，都会给节点已发送信息，提醒节点1可以进行操作

创建锁

A

议员1000（服务器）

1.转发提议给总统，不响应提议2.接收广播3.对外提供读服务

/lock

第一种：使用 ZK 的持久节点实现分布式锁问题：可能因为业务访问的逻辑bug导致无法调用释放锁的代码，其他的所有线程都无法访问项目解决：节点支持超时功能（先要在配置文件中打开 extendedTypesEnabled=true），或者使用临时节点

释放锁

D

如何选主

临时顺序节点-es

1号提议，设定电费为1元/度

最终一致性Eventual consistency

Paxos算法-有主模式

Paxos算法(ZAB协议)-添加观察者角色

没有最好的架构只有最合适的架构

分布式锁的基本要求：1.多进程可见2.高可用3.互斥性4.可超时5.公平

锁被释放

易守难攻

二阶段：1.询问阶段，发起提议询问大家是否接受（投票）2.广播阶段，询问阶段票数超过服务器总数的二分之一时进行广播

No

基本服务可用Base

选主流程（第一次选主，集群初始化启动时）：1.无脑选议员编号最大的为主——为了快速选主2.加入投票机制，票数过半才可成为主3.投票默认投票给议员编号最大的节点4.每次选主成功都会有一个朝代的标记5.每次选主成功都要将数据同步

/lock00000000002

ZAB协议

ZooKeeper存储机制监听机制

站在客户端的角度，可以重复调用创建命令ZK 底层需要对创建命令作出处理，按照顺序创建Znode创建节点的会话断开，节点就会自动删除

二阶段数据一致性处理

议员总数 = 3集群服务器总数

ZooKeeper 监听机制

崩溃恢复

C

ZXID

观察者看听

系统不可能一直处于软状态，必须最终一致

ZooKeeper 是CP架构C 一致性二阶段超过半数的概念

创建节点的会话断开，节点就会自动删除

Paxos算法-基础模型

Paxos算法-冲突解决

原子广播

站在客户端的角度，可以重复调用创建命令ZK 底层需要对创建命令作出处理，按照顺序创建Znode

课程重点划分

因为没有分区，所以数据写入即一致所以可以立即返回，满足CA，无P特性

议员编号

三种角色

myid

因为有分区，为了及时响应，所以无法做到数据一致性所以没有C特性

什么是最好的架构

参考维度：集群初始化选主，集群运行时主宕机重新选主如何选主：1.不能太慢（投票选，无脑投票给最大的）2.主的数据一定要是集群中最全的，主不能处于宕机状态（过滤条件：主的PID与公共PID相同且处于运行状态）

Paxos算法-活锁问题（奇数——质数——有主模式）

第二种：使用临时节点实现分布式锁

1.服务器节点要相互信任2.信道不能被篡改

node03

持久节点默认

议员999（服务器）

B

议员3（服务器）

通知：1号提议生效

现在议会开始运作，所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议：将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有议员发消息：1号提议，设定电费1元/度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的议员会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。

统一的概念

选主流程（第一次选主，集群初始化启动时）：1.要选择与整个PID相同的议员2.无脑选议员编号最大的为主——为了快速选主3.加入投票机制，票数过半才可成为主4.投票默认投票给议员编号最大的节点5.每次选主成功都会有一个朝代的标记6.每次选主成功都要将数据同步

1.转发提议给总统，响应提议2.接收广播3.参与选主4.对外提供读服务

三者只能拥有其二

写请求 扣库存

因为有分区，所以个分区需要保持数据一致数据未一致无法对外提供服务，所以没有A特性

E

读请求：电费多少

当系统发生故障或流量激增，牺牲部分服务保证基本服务可用

议员4总统

/lock00000000003

获取到脏数据时，触发后续逻辑时，再进一步同步定时触发同步，系统闲时进行数据同步