首页 > 永辉java开发面经
头像
云洛枫眠丶
编辑于 2021-04-15 20:42
+ 关注

永辉java开发面经

1、自我介绍

2、zookper

ZooKeeper是一个分布式服务协调框架,主要用来解决分布式应用中的一些数据管理问题,如:统一命名服务、状态同步服务、应用配置项的管理等等。

==Znode兼具文件和目录两种特点。既可以像目录一样可以保存子节点,又可以像文件一样可以保存信息。==

一个znode大体上分为3部分:

  1. data:节点的数据
  2. children:节点的子节点
  3. stat:节点的状态,用来描述当前节点的创建、修改记录等

节点类型

对于Zookeeper中的节点,有两种分类方式,一种是按照节点是否持久化,一种是按照节点是否有顺序进行分类。

按照节点是否持久化分类,可以分别为临时节点和永久节点

  • 临时节点:该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束,临时节点将被自动删除

    虽然每个临时的Znode都会绑定到一个客户端会话,但他们对所有的客户端还是可见的。另外,ZooKeeper的临时节点不允许拥有子节点

  • 持久化节点(默认):该节点的生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除

按照节点是否有顺序进行分类,可以分别为有序节点和无序节点

  • 有序节点:每个节点都会为它的一级子节点维护一个顺序
  • 无序节点(默认):节点不会为子节点维护顺序
* 节点类型
    持久化无序节点 :节点创建后会一直存在zookeeper服务器上,直到主动删除
    持久化有序节点 :在持久化无序节点的基础上,为每个节点都会为它的一级子节点维护一个顺序
    临时无序节点 :  临时节点的生命周期和客户端的会话保持一致,当客户端会话失效,该节点自动清理
    临时有序节点 :  在临时节点上多了一个顺序性特性

Zookeeper使用场景(面试)

ID生成器==顺序节点==

配置中心==watch机制==

在这里Zookeeper采用了推拉模式相结合的做法:
push可以保证能够第一时间拿到更新配置,基本可以做到准实时的更新,但push存在问题,即如果有网络抖动,某一次push没有推送成功,将丢失这次配置的更新
pull可以保证一定可以拉取得到数据,pull一般采用定时拉取的方式,即使某一次出现网络问题,没有拉取得到数据,那在下一次定时器也将可以拉取得到数据

分布式协调==watch机制==

集群选主==临时节点==

使用Zookeeper的==临时节点==可以轻松实现这一需求
我们把上面描述的这个过程称为集群选主的过程,首先所有的节点都认为是从节点,都有机会称为主节点,然后开始选主,步骤比较简单:

  1. 所有参与选主的主机都去Zookeeper上创建同一个临时节点,那么最终一定只有一个客户端请求能够创建成功。
  2. 成功创建节点的客户端所在的机器就成为了主节点,其他没有成功创建该节点的客户端,成为从节点
  3. 所有的从节点都会在主节点上注册一个子节点变更的Watcher,用于监控当前主节点是否存活,一旦发现当前的主节点挂了,那么其他客户端将会重新进行选主。

分布式锁==临时有序节点==

使用Zookeeper的 临时有序 节点可以轻松实现这一需求

  1. 所有需要执行操作的主机都去Zookeeper上创建一个临时有序节点
  2. 然后获取到Zookeeper上创建出来的这些节点进行一个从小到大的排序
  3. ==判断自己创建的节点是不是最小的,如果是,自己就获取到了锁;如果不是,则对最小的节点注册一个监听==
  4. 如果自己获取到了锁,就去执行相应的操作,当执行完毕之后,连接断开,节点消失,锁就被释放了
  5. 如果自己没有获取到锁,就等待,一直监听节点消失,锁释放后,再重新执行抢夺锁的操作

集群(高级)

集群角色

* ZooKeeper集群中的三个角色:
    Leader(领导者):负责投票的发起和决议,更新系统状态,是事务请求的唯一处理者,一个ZooKeeper同一时刻只会有一个Leader
    Follower(跟随者):处理客户端请求,参与选主投票
    Observer(观察者):处理客户端请求,不参与选主投票
* Leader可以提供读写服务,Follower或Observer只提供读服务,但是Observer机器不参与Leader选举,也不参与写操作的『过半写成功』策略

事务处理流程

1. 所有的事务请求都交由集群的Leader服务器来处理,Leader服务器会将一个事务请求转换成一个Proposal(提议),并为其生成一个全局递增的唯一ID,
    这个ID就是事务ID,即ZXID,Leader服务器对Proposal是按其ZXID的先后顺序来进行排序和处理的。
2. Leader服务器会将Proposal放入每个Follower对应的队列中(Leader会为每个Follower分配一个单独的队列),并以FIFO的方式发送给Follower服务器。
3. Follower服务器接收到事务Proposal后,首先以事务日志的方式写入本地磁盘,并且在成功后返回Leader服务器一个ACK响应。
4. Leader服务器只要收到过半Follower的ACK响应,就会广播一个Commit消息给Follower以通知其进行Proposal的提交,同时Leader自身也会完成Proposal的提交。
5. Follower收到commit请求时,从历史队列中将事务请求commit

集群选举

服务器状态

* Zookeeper服务器有四个状态
    looking:  寻找leader状态。当服务器处于该状态时,它会认为当前集群中没有leader,因此需要进入leader选举状态。


    leading:  领导者状态。表明当前服务器角色是leader。
    following:跟随者状态。表明当前服务器角色是follower。
    observing:观察者状态。表明当前服务器角色是observer。

leader选举

* 在集群初始化阶段,当有一台服务器server1启动时,其单独无法进行和完成leader选举,
* 当第二台服务器server2启动时,此时两台机器可以相互通信,每台机器都试图找到leader,于是进入leader选举过程。 
* 选举过程如下:
    1. 每个server发出一个投票。
       由于是初始情况,server1和server2都会将自己作为leader服务器来进行投票,每次投票会包含所推举的服务器的myid和zxid,
       使用(myid, zxid)来表示,此时server1的投票为(1, 0),server2的投票为(2, 0),然后各自将这个投票发给集群中其他机器。
    2. 集群中的每台服务器接收来自集群中各个服务器的投票。
    3. 处理投票。针对每一个投票,服务器都需要将别人的投票和自己的投票进行pk,pk规则如下:
        优先检查zxid。zxid比较大的服务器优先作为leader。
        如果zxid相同,那么就比较myid。myid较大的服务器作为leader服务器。
         对于Server1而言,它的投票是(1, 0),接收Server2的投票为(2, 0),首先会比较两者的zxid,均为0,再比较myid,此时server2的myid最大,
         于是更新自己的投票为(2, 0),然后重新投票,对于server2而言,其无须更新自己的投票,只是再次向集群中所有机器发出上一次投票信息即可。
    4. 统计投票。每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息,
        对于server1、server2而言,都统计出集群中已经有两台机器接受了(2, 0)的投票信息,此时便认为已经选出了leader
    5. 改变服务器状态。一旦确定了leader,每个服务器就会更新自己的状态,如果是follower,那么就变更为following,如果是leader,就变更为leading。

3、线程池核心参数,线程池的原理

4、拒绝策略

ThreadPoolExecutor.AbortPolicy(系统默认):丢弃任务并抛出RejectedExecutionException异常,让你感知到任务被拒绝了,我们可以根据业务逻辑选择重试或者放弃提交等策略

ThreadPoolExecutor.DiscardPolicy:也是丢弃任务,但是不抛出异常,相对而言存在一定的风险,因为我们提交的时候根本不知道这个任务会被丢弃,可能造成数据丢失。ThreadPoolExecutor.DiscardOldestPolicy:丢弃队列最前面的任务,然后重新尝试执行任务(重复此过程),通常是存活时间最长的任务,它也存在一定的数据丢失风险ThreadPoolExecutor.CallerRunsPolicy:既不抛弃任务也不抛出异常,而是将某些任务回退到调用者,让调用者去执行它。

5、线程有哪几种状态以及各种状态之间的转换?

6、乐观锁,读锁和写锁,共享还是互斥

7、https

8、反射,是否可以使用私有方法

更多模拟面试

全部评论

(2) 回帖
加载中...
话题 回帖

推荐话题

相关热帖

历年真题 真题热练榜 24小时
技术(软件)/信息技术类
查看全部

近期精华帖

热门推荐