爱了爱了！头条三面技术四面HR

### 1\. 面试官：工作中使用过Zookeeper嘛？你知道它是什么，有什么用途呢？ **小菜鸡的我：** * 有使用过的，使用ZooKeeper作为**dubbo的注册中心**，使用ZooKeeper实现**分布式锁**。 * ZooKeeper，它是一个开放源码的**分布式协调服务**，它是一个集群的管理者，它将简单易用的接口提供给用户。 * 可以基于Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列**等功能**。 * Zookeeper的**用途**：命名服务、配置管理、集群管理、分布式锁、队列管理 用途跟功能不是一个意思咩？ ### 2\. 面试官：说下什么是命名服务，什么是配置管理，又什么是集群管理吧 **小菜鸡的我(幸好我刷过面试题)，无所畏惧** * **命名服务就是**： > 命名服务是指通过**指定的名字**来获取资源或者服务地址。Zookeeper可以创建一个**全局唯一的路径**，这个路径就可以作为一个名字。被命名的实体可以是**集群中的机器，服务的地址，或者是远程的对象**等。一些分布式服务框架（RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等。 * **配置管理：** ： > 实际项目开发中，我们经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。因为你的程序一般是分布式部署在不同的机器上（如果你是单机应用当我没说），如果把程序的这些配置信息**保存在zk的znode节点**下，当你要修改配置，即znode会发生变化时，可以通过改变zk中某个目录节点的内容，利用**watcher通知给各个客户端**，从而更改配置。 * **集群管理** > 集群管理包括集群监控和集群控制，其实就是监控集群机器状态，剔除机器和加入机器。zookeeper可以方便集群机器的管理，它可以实时监控znode节点的变化，一旦发现有机器挂了，该机器就会与zk断开连接，对用的临时目录节点会被删除，其他所有机器都收到通知。新机器加入也是类似酱紫，所有机器收到通知：有新兄弟目录加入啦。 ### 3\. 面试官：你提到了znode节点，那你知道znode有几种类型呢？zookeeper的数据模型是怎样的呢？ **小菜鸡的我（我先想想）：** #### zookeeper的数据模型 ZooKeeper的视图数据结构，很像Unix文件系统，也是树状的，这样可以确定每个路径都是唯一的。zookeeper的节点统一叫做**znode**，它是可以通过**路径来标识**，结构图如下：  #### znode的4种类型 根据节点的生命周期，znode可以分为4种类型，分别是持久节点（PERSISTENT）、持久顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）、临时顺序节点（EPHEMERAL_SEQUENTIAL） * 持久节点（PERSISTENT） > 这类节点被创建后，就会一直存在于Zk服务器上。直到手动删除。 * 持久顺序节点（PERSISTENT_SEQUENTIAL） > 它的基本特性同持久节点，不同在于增加了顺序性。父节点会维护一个自增整性数字，用于子节点的创建的先后顺序。 * 临时节点（EPHEMERAL） > 临时节点的生命周期与客户端的会话绑定，一旦客户端会话失效（非TCP连接断开），那么这个节点就会被自动清理掉。zk规定临时节点只能作为叶子节点。 * 临时顺序节点（EPHEMERAL_SEQUENTIAL） > 基本特性同临时节点，添加了顺序的特性。 ### 4、面试官：你知道znode节点里面存储的是什么吗？每个节点的数据最大不能超过多少呢？ **小菜鸡的我：**  #### znode节点里面存储的是什么？ Znode数据节点的代码如下 ``` public class DataNode implements Record { byte data[]; Long acl; public StatPersisted stat; private Set children = null; } ``` 哈哈，Znode包含了**存储数据、访问权限、子节点引用、节点状态信息**，如图：  * **data:** znode存储的业务数据信息 * **ACL:** 记录客户端对znode节点的访问权限，如IP等。 * **child:** 当前节点的子节点引用 * **stat:** 包含Znode节点的状态信息，比如**事务id、版本号、时间戳**等等。 #### 每个节点的数据最大不能超过多少呢 为了保证高吞吐和低延迟，以及数据的一致性，znode只适合存储非常小的数据，不能超过1M，最好都小于1K。 ### 5、面试官：你知道znode节点上的监听机制嘛？讲下Zookeeper watch机制吧。 **小菜鸡的我：**  * Watcher机制 * 监听机制的工作原理 * Watcher特性总结 #### Watcher监听机制 Zookeeper 允许客户端向服务端的某个Znode注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher通知状态和事件类型做出业务上的改变。 > 可以把Watcher理解成客户端注册在某个Znode上的触发器，当这个Znode节点发生变化时（增删改查），就会触发Znode对应的注册事件，注册的客户端就会收到异步通知，然后做出业务的改变。 #### Watcher监听机制的工作原理  * ZooKeeper的Watcher机制主要包括客户端线程、客户端 WatcherManager、Zookeeper服务器三部分。 * 客户端向ZooKeeper服务器注册Watcher的同时，会将Watcher对象存储在客户端的WatchManager中。 * 当zookeeper服务器触发watcher事件后，会向客户端发送通知， 客户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑。 #### Watcher特性总结 * **一次性：**一个Watch事件是一个一次性的触发器。一次性触发，客户端只会收到一次这样的信息。 * **异步的:** Zookeeper服务器发送watcher的通知事件到客户端是异步的，不能期望能够监控到节点每次的变化，Zookeeper只能保证最终的一致性，而无法保证强一致性。 * **轻量级：** Watcher 通知非常简单，它只是通知发生了事件，而不会传递事件对象内容。 * **客户端串行：** 执行客户端 Watcher 回调的过程是一个串行同步的过程。 * 注册 watcher用getData、exists、getChildren方法 * 触发 watcher用create、delete、setData方法 ### 6、面试官：你对Zookeeper的数据结构都有一定了解，那你讲下Zookeeper的特性吧 **小菜鸡的我：（我背过书，啊哈哈）** Zookeeper 保证了如下分布式一致性特性： * **顺序一致性**：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。 * **原子性**：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。 * **单一视图**：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。 * **可靠性：** 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来。 * **实时性（最终一致性）：** Zookeeper 仅仅能保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。 ### 7、面试官：你刚提到顺序一致性，那zookeeper是如何保证事务的顺序一致性的呢？ **小菜鸡的我：（完蛋了这题不会）** > 需要了解事务ID，即zxid。ZooKeeper的在选举时通过比较各结点的zxid和机器ID选出新的主结点的。zxid由Leader节点生成，有新写入事件时，Leader生成新zxid并随提案一起广播，每个结点本地都保存了当前最近一次事务的zxid，zxid是递增的，所以谁的zxid越大，就表示谁的数据是最新的。 ZXID的生成规则如下：  ZXID有两部分组成： * 任期：完成本次选举后，直到下次选举前，由同一Leader负责协调写入； * 事务计数器：单调递增，每生效一次写入，计数器加一。 > ZXID的低32位是计数器，所以同一任期内，ZXID是连续的，每个结点又都保存着自身最新生效的ZXID，通过对比新提案的ZXID与自身最新ZXID是否相差“1”，来保证事务严格按照顺序生效的。 ### 8、面试官：你提到了Leader，你知道Zookeeper的服务器有几种角色嘛？Zookeeper下Server工作状态又有几种呢？ **小菜鸡的我：**  #### Zookeeper 服务器角色 Zookeeper集群中，有Leader、Follower和Observer三种角色 **Leader** > Leader服务器是整个ZooKeeper集群工作机制中的核心，其主要工作： > > * 事务请求的唯一调度和处理者，保证集群事务处理的顺序性 > * 集群内部各服务的调度者 **Follower** > Follower服务器是ZooKeeper集群状态的跟随者，其主要工作： > > * 处理客户端非事务请求，转发事务请求给Leader服务器 > * 参与事务请求Proposal的投票 > * 参与Leader选举投票 **Observer** > Observer是3.3.0 版本开始引入的一个服务器角色，它充当一个观察者角色——观察ZooKeeper集群的最新状态变化并将这些状态变更同步过来。其工作： > > * 处理客户端的非事务请求，转发事务请求给 Leader 服务器 > * 不参与任何形式的投票 #### Zookeeper下Server工作状态 > 服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 > > * 1.LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。 > * 2.FOLLOWING：跟随者状态。表明当前服务器角色是Follower。 > * 3.LEADING：领导者状态。表明当前服务器角色是Leader。 > * 4.OBSERVING：观察者状态。表明当前服务器角色是Observer。 ### 9、面试官：你说到服务器角色是基于ZooKeeper集群的，那你画一下ZooKeeper集群部署图吧？ZooKeeper是如何保证主从节点数据一致性的呢？ **小菜鸡的我：**  #### ZooKeeper集群部署图  ZooKeeper集群是一主多从的结构： * 如果是写入数据，先写入主服务器（主节点），再通知从服务器。 * 如果是读取数据，既读主服务器的，也可以读从服务器的。 #### ZooKeeper如何保证主从节点数据一致性 我们知道集群是主从部署结构，要保证主从节点一致性问题，无非就是两个主要问题： * **主服务器挂了，或者重启了** * **主从服务器之间同步数据**~ Zookeeper是采用ZAB协议（Zookeeper Atomic Broadcast，Zookeeper原子广播协议）来保证主从节点数据一致性的，ZAB协议支持**崩溃恢复和消息广播**两种模式，很好解决了这两个问题： * 崩溃恢复：Leader挂了，进入该模式，选一个新的leader出来 * 消息广播： 把更新的数据，从Leader同步到所有Follower > Leader服务器挂了，所有集群中的服务器进入LOOKING状态，首先，它们会选举产生新的Leader服务器；接着，新的Leader服务器与集群中Follower服务进行数据同步，当集群中超过半数机器与该 Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式。Leader 服务器开始接收客户端的事务请求生成事务Proposal进行事务请求处理。 ### 总目录展示 该笔记共八个节点（由浅入深），分为三大模块。 **高性能**。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。 **一致性**。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。 **高可用**。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。 ----- 篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），觉得有需要的码友们，麻烦各位转发一下（可以帮助更多的人看到哟！）[点这里，即可获得免费下载的方式！！](https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB)   由于内容太多，这里只截取部分的内容。需要这份《高并发秒杀顶级教程》的小伙伴，麻烦各位帮忙点赞分享支持一下（可以帮助更多的人看到哟！）

标签：HR,Zookeeper,Leader,集群,头条,服务器,三面,节点,客户端
来源： https://blog.51cto.com/u_15289173/2965979