Zookeeper

Zookeeper

概览

一个开源的分布式协调服务

特点

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

原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。

可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

应用场景

命名服务 ：可以通过 ZooKeeper 的顺序节点生成全局唯一 ID。

数据发布/订阅 ：通过 Watcher 机制 可以很方便地实现数据发布/订阅。

分布式锁 ： 通过创建唯一节点获得分布式锁。

Data model（数据模型）

每个节点都是一个 znode

每个 znode 可以有n个子节点

每个 znode 都有唯一路径表示

每个 Zonode 上存放的数据不要超过 1m(不适合存放业务数据)

znode（数据节点）

持久（PERSISTENT）节点 ：一旦创建就一直存在即使 ZooKeeper 集群宕机，直到将其删除。

临时（EPHEMERAL）节点 ：临时节点的生命周期是与 客户端会话（session） 绑定的，会话消失则节点消失 。并且，临时节点只能做叶子节点 ，不能创建子节点。

持久顺序（PERSISTENT_SEQUENTIAL）节点 ：除了具有持久（PERSISTENT）节点的特性之外， 子节点的名称还具有顺序性。比如 /node1/app0000000001 、/node1/app0000000002 。

临时顺序（EPHEMERAL_SEQUENTIAL）节点 ：除了具备临时（EPHEMERAL）节点的特性之外，子节点的名称还具有顺序性

Watcher(事件监听器)

ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去

• Watcher非永久，而是一次性，必须重复注册。

• Watcher并不会通知每一次变化（性能消耗大、有延迟），只通知最新的。

• Watcher对象只会保存在客户端，不会传递到服务端。

Session(会话)

sessionTimeout

即使有客户端断开连接，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效

sessionID

无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一

ZooKeeper 集群

Leader：为客户端提供读和写的服务，负责投票的发起和决议，更新系统状态。

Follower：为客户端提供读服务，如果是写服务则转发给 Leader。参与选举过程中的投票。

Observer：为客户端提供读服务，如果是写服务则转发给 Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能。

最少三台

Leader 选举

过半机制：2n+1

可以防止脑裂

ZAB (原子广播)协议

崩溃恢复 ：当Leader挂了，就进入恢复模式重新选取Leader。当集群中有过半的机器与该Leader完成数据状态同步后就退出恢复模式。

消息广播 ：当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。

当有一台新服务器加入集群，若此时有Leader在消息广播，那么新的服务器就先进入恢复模式然后再消息广播。

ZAB协议与Paxo算法的异同？

Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播）

同

比如都有一个Leader，用来协调N个Follower的运行；
Leader要等待超半数的Follower做出正确反馈之后才进行提案；
二者都有一个值来代表Leader的周期。

异

ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。

端口

2888：Follower与Leader交换信息的端口。
3888：执行选举时服务器相互通信的端口。

日志清理

zk自己不会进行日志清理，需要运维人员进行日志清理。

事务性

zoo_create_op_init、zoo_delete_op_init、 zoo_set_op_init、zoo_check_op_init