Zookeeper学习笔记Day1

zookeeper笔记

0. Zookeeper

管理大量主机的协同服务。
分布式应用，实现分布式读写技术。
zk提供的服务
- Naming service //按名称区分集群中的节点.
- Configuration management //对加入节点的最新化处理。
- Cluster management //实时感知集群中节点的增减.
- Leader election //leader选举
- Locking and synchronization service //修改时锁定数据，实现容灾.
- Highly reliable data registry //节点宕机数据也是可用的。

常用命令

 zkServer.sh start
 zkServer.sh status
 
 zkCli.sh -server xxx:2181
 [zkCli]ls /
 [zkCli]create / ""
 [zkCli]get /
 [zkCli]set /
 [zkCli]rmr /

安装

下载

wget http://mirrors.shu.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz

解压

tar -zxvf zookeeper-3.4.14.tar.gz

环境变量
- 建立符号连接 ln -s xxx /soft/zookeeper
- 配置/etc/profile

1. zk架构

C/S

部分	描述
Client(客户端)	应用集群中的一个节点，从服务器访问信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活跃的。类似地，当客户端连接时，服务器发送确认码。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。
Server(服务端)	zk总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。
Ensemble	zk服务器组。形成ensemble所需的最小节点数为3。
Leader	任何连接的节点失败，则执行自动恢复。Leader在服务启动时被选举。
Follower	跟随leader指令的服务器节点。

2. znode

乐观锁

结构
类型

持久节点(persistent)，顺序节点(sequential)，临时节点(ephemeral)

类型	描述
持久节点	Client退出后，节点仍然存在
临时节点	Client活动时有效，断开后自动删除，不能有子节点，在leader选举时起到重要作用
顺序节点	可以是临时节点，也可以是持久节点，创建后在节点名后加10位数序列号，在锁和同步中起重要作用。

3. Session

FIFO

一旦client连接到Server，就建立Session，sessionid分配给client。
client以固定时间向服务器发送心跳，session有效。
zk集群在超时的时候，没有收到心跳，判定为断开连接，此时，临时节点会被删除。

4. Watches

对于Client类似观察者机制，以接口的形式表现出来

client在读取特定znode时设置Watches。
Watches会向注册的client发送任何znode（客户端注册表）更改的通知。
Znode更改是与znode相关的数据的修改或znode的子项中的更改。
只触发一次watches。
如果client想要再次通知，则必须通过另一个读取操作来完成。
当Session过期时，client与Server断开连接，相关的watches也将被删除。

5. 工作流程

zk集群启动后，等待client连接，client连接到zk的任何一个节点(node)，该node可以是Leader或是follower。一旦Client连接，node会给client分配一个sessionid，并向该client确认信息(ack)。如果client没有收到ack，client会去尝试请求另一个节点。一旦成功连接到节点，client会发送心跳，确保不会丢失连接。

client读取特定的znode

   将向含有znode路径的节点发送请求，节点通过查询自己的数据库，
   把读取到的znode数据返回给client。zk集群中读取数据的速度很快。

client存储znode到zk集群中

   将znode的路径&数据发送到server，server将请求转发给Leader，
   leader向所有的follwer发送写入请求，当大部分(半数以上)节点成功相应，则写入成功，返回给Client。

zk中的节点

zk中节点个数不同，效果不同，推荐奇数节点(半数节点故障容易处理)。

1个节点，那么该节点故障，zk集群就会失效，不建议生产环境使用。
2个节点，如果1个节点故障，没有占多数。
3个节点，如果1个节点故障，剩余2个节点，占据大多数，这是最低要求，生产环境必须至少3个以上节点。
4个节点，如果2个节点故障，再次故障类似3个节点情况，额外节点不用于任何目的。

故：节点数最好为奇数。如：3、5、7

zk的写入过程要比读取过程更耗资源，以为所有节点都需要在自身数据库写入相同的数据。因此，对于平衡环境来说更少节点(3/5/7)要比大量节点更好。

组件/操作	描述
写(write)	写入过程由leader节点处理。leader将写请求转发所有的Znode，然后等待来自znode的恢复。如果一半的Znodes回复，您可以确定写入过程已完成。
读(read)	读取由连接特定的znode在内部执行，因此不需要与集群交互。
数据库复制(Replicated Database)	在zk中存储数据，每个Znode都有自己的数据库，在一致性的帮助下每次都有相同的数据。
Leader	负责写入请求的znode
Follower	负责接收clien的请求，转发给leader
请求处理器(Request Processor)	只在leader中，用于管理follower的写入请求。
原子广播(atomic broadcasts)	负责广播从leader到follower的变化

workflow

6. zk的选举(最小号选举)

1.所有节点在同一目录下创建临时序列节点。
2.节点下会生成/xxx/xx000000001等节点。
3.序号最小的节点就是leader，其余就是follower.
4.每个节点观察小于自己节点的主机。(注册观察者)
5.如果leader挂了，对应znode删除了。
6.观察者收到通知。