大数据干货系列(四)--ZooKeeper总结

ZooKeeper总结

 

本质

ZooKeeper 一个为分布式应用提供一致性服务的软件

 

、ZooKeeper解决了什么问题

1. 分布式系统的一致性问题

2. 分布式系统的容灾容错

3. 分布式系统的执行顺序问题

4. 分布式系统的事务性问题

 

、ZooKeeper的系统架构

大数据干货系列(四)--ZooKeeper总结_第1张图片

1. 领导者(Leader):负责进行投票的发起和决议更新系统状态

2. 学习者(Learner):包括跟随者(Follower)和观察者(Observer)

3. Follower:用于接受客户端请求并向客户端返回结果在选主过程中参与投票

4. Observer:可接受客户端请求将写请求转发给Leader,Observer不参加投票过程只同步Leader的状态,Observer的目的是为了扩展系统提高读取速度

5. 客户端(Client):请求的发起方


、ZooKeeper的目录结构

大数据干货系列(四)--ZooKeeper总结_第2张图片

1. 在机器的zookeeper/bin目录下输入./ zkCli.sh start就可以启动zookeeper集群可以只启动一部分Server节点

2. 输入./zkCli.sh -server 127.0.0.1:2181 ,即可进入查看zookeeper的目录

3. 数据模型

- ZooKeeper拥有一个层次的命名空间图中每个方块是一个Znode

- Znode既可以像文件一样维护着数据元信息、ACL、时间戳等数据结构

- Znode又可以像目录一样可以作为路径标识必须为绝对路径的一部分

用户对Znode具有增查等操作权限允许的情况下

4. Znode类型

ZooKeeper中的节点有两类四种节点的类型在创建时即被确定并且不能改变

PERSISTENT:永久节点

EPHEMERAL:临时节点

PERSISTENT_SEQUENTIAL:永久节点序列化

EPHEMERAL_SEQUENTIAL:临时节点序列化


临时节点该节点的生命周期依赖于创建它们的会话一旦会话结束临时节点将被自动删除也可以手动删除:ZooKeeper的临时节点不允许拥有子节点

永久节点该节点的生命周期不依赖于会话并且只有在客户端显示执行删除操作的时候他们才能被删除

序列化当创建Znode的时候用户可以请求在ZooKeeper的路径结尾添加一个递增的计数

 

、ZooKeeper的五个特征

1. Watches机制☆☆☆

    - 客户端可以在Znode上设置watch(监控器

    - 当节点状态发生改变时(数据的增)将会触发watch,向客户端发送且仅发送一条通知

    - 存在有可能看不到所有数据变化的风险因为多个事件的监控只会触发一次

2. 一致性保证

    - 序列一致性客户端发送的更新将按序在Zookeeper进行更新

    - 原子一致性更新只能成功或者失败没有中间状态

    - 单系统镜像无论连接哪台Zookeeper服务器客户端看到的服务器数据一致

3. 数据访问

    - 每个节点上的访问控制链”(ACL, Access Control List)保存了各客户端的访问权限

    - 表示为scheme:id:permissions

4. 容错性☆☆☆

    - ZooKeeper集群中只要半数以上的机器处于可用状态它就能够提供服务

    - 若少于半数的机器出现故障则最少有一台机器会保存最新的状态那么这台机器就是新的Leader,其余的副本最终也会更新到这个状态

    - Leader挂了由于其他机器保存了Leader的副本可以从中选出一台机器作为Leader继续提供服务

5. 实时性☆☆

在任何客户端的系统视图上的的时间间隔是有限的因此他在超过几十秒的时间内部会过期这就意味着服务器不会让客户端看一些过时的数据而是关闭强制客户端转到一个更新的服务器上

 

、Zookeeper应用场景

1. 配置管理(Configuration Management)

    – 基于watch机制的全局系统配置

    – 容错并且统一

2. 集群管理(Group Membership)

集群状态

    – 采用EPHEMERAL临时节点

    – 所有的server getChildren(String path, boolean watch) 方法

    – 某台服务器下线对应的节点自动删除

选主节点

    – 采用EPHEMERAL_SEQUENTIAL临时序列节点

    – 选择当前是最小编号的 Server  Master

    – 最小编号的 Server 死去由于是 EPHEMERAL节点死去的Server 对应的节点也被删除所以当前的节点列表中又出现一个最小编号的节点 

3. 共享锁(Locks)

    – 采用EPHEMERAL_SEQUENTIAL临时序列节点

4. 队列管理

同步队列

    – 采用EPHEMERAL_SEQUENTIAL临时序列节点

②FIFO队列

    – 采用EPHEMERAL临时节点

    – 保证所有成员加入队列时都有编号

    – 出队列时通过getChildren( ) 方法返回所有元素然后消费其中最小的一个

 


以上.


如果觉得本文对你有帮助,可以帮忙点个赞表示支持吗,谢谢!

如果有任何意见和建议,也欢迎再下方留言~





 

关注这个公众号,每天22:00会有三道大数据面试题准时推送给你哦~


点击这里查看往期精彩内容:

每日三问

大数据干货系列(一)--MapReduce总结

大数据干货系列(二)--HDFS1.0

大数据干货系列(三)-- Hadoop2.0总结

你可能感兴趣的:(Hadoop系统架构)