开发者社区> java架构> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

zookeeper任务与面试 重点(含答案)

简介: 任务 安装zookeeper 练习zookeeper命令 面试重点 zookeeper是干什么的? Zookeeper 是 分布式协调服务,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等 说说zookeeper半数机制 举例说明:3台和4台的区别。
+关注继续查看

任务

安装zookeeper

练习zookeeper命令

面试重点

zookeeper是干什么的?

Zookeeper 是 分布式协调服务,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等

  1. 说说zookeeper半数机制

举例说明:3台和4台的区别。

  1. zookeeper节点类型

Znode有两种类型:

短暂(ephemeral)(断开连接自己删除)

持久(persistent)(断开连接不删除)

Znode有四种形式的目录节点(默认是persistent )

PERSISTENT

PERSISTENT_SEQUENTIAL(持久序列/test0000000019 )

EPHEMERAL

EPHEMERAL_SEQUENTIAL

创建znode时设置顺序标识,znode名称后会附加一个值

顺序号是一个单调递增的计数器,由父节点维护

在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序

zookeeper选举机制

zookeeper的选举机制(全新集群)

以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.
1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.

非全新集群的选举机制(数据恢复)

那么,初始化的时候,是按照上述的说明进行选举的,但是当zookeeper运行了一段时间之后,有机器down掉,重新选举时,选举过程就相对复杂了。

需要加入数据id、leader id和逻辑时钟。

数据id:数据新的id就大,数据每次更新都会更新id。

Leader id:就是我们配置的myid中的值,每个机器一个。

逻辑时钟:这个值从0开始递增,每次选举对应一个值,也就是说:  如果在同一次选举中,那么这个值应该是一致的 ;  逻辑时钟值越大,说明这一次选举leader的进程更新.

选举的标准就变成:

1、逻辑时钟小的选举结果被忽略,重新投票

2、统一逻辑时钟后,数据id大的胜出

3、数据id相同的情况下,leader id大的胜出

根据这个规则选出leader。

​​​​​​​说说共享锁

共享锁在同一个进程中很容易实现,但是在跨进程或者在不同 Server 之间就不好实现了。

Zookeeper 却很容易实现这个功能,实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点,然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点,如果正是自己创建的,那么它就获得了这个锁,如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化,一直到自己创建的节点是列表中最小编号的目录节点,从而获得锁,释放锁很简单,只要删除前面它自己所创建的目录节点就行了。

我收集了一些关于Java高并发、分布式、ZK、dubbo、JVM、spring源码分析以及性能优化,设计模式等相关的技术资料(电子书)一并分享在Java架构师之路大家庭里(766529531),欢迎大家来里下载学习以及交流讨论。

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里面试官:分布式锁到底用Redis好?还是Zookeeper好?
在一个进程中,也就是一个jvm 或者说应用中,我们很容易去处理控制,在jdk java.util 并发包中已经为我们提供了这些方法去加锁, 比如synchronized 关键字 或者Lock 锁,都可以处理。 但是我们现在的应用程序如果只部署一台服务器,那并发量是很差的,如果同时有上万的请求那么很有可能造成服务器压力过大,而瘫痪。 想想双十一 和 三十晚上十点分支付宝红包等业务场景,自然需要用到多台服务器去同时处理这些业务,那么这些服务可能会有上百台同时处理, 但是请我们大家想一想,如果有100台服务器 要处理分红包的业务,现在假设有1亿的红包,1千万个人分,金额随机,那么这
41 0
面试官:Zookeeper集群怎么搭建?
本文介绍如何搭建Zookeeper集群。
35 0
面试官:Zookeeper集群怎么搭建?
本文介绍如何搭建Zookeeper集群,希望对大家有所帮助。
31 0
Zookeeper的客户脚本及命令(五)
Zookeeper的客户脚本及命令(五)
84 0
开源/免费/强大的移动端触摸滑动插件 — Swiper
Swiper是一款免费及轻量级的移动设备触控滑块的框架,使用硬件加速过渡(如果该设备支持的话),主要使用与移动端的网站/网页应用程序(web apps)/原生应用程序(native apps),主要是为IOS而设计的,同时在Android/WP8系统及现代桌面浏览器也有着良好的用户体验 swipe.
8823 0
Secondary节点为何阻塞请求近一个小时?
看到Secondary节点上的日志,我的内心的崩溃的,鉴权请求居然耗时2977790ms(约50分钟),经详细统计,这个Secondary节点上,所有16:54之后发起的用户请求,都阻塞到17:54左右才返回,处理时间最长的请求约1个小时。 2016-06-17T17:54:57.575+0800
4630 0
+关注
java架构
想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取 架构群:809340374
文章
问答
文章排行榜
最热
最新
相关电子书
更多
云栖社区特邀专家徐雷Java Spring Boot开发实战系列课程(第20讲):经典面试题与阿里等名企内部招聘求职面试技巧
立即下载
Java开发者面试百宝书
立即下载
阿里云技术面试红宝书
立即下载