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、反射，是否可以使用私有方法