Obtener: hoja de trucos de entrevista de 100,000 palabras
Durante la entrevista, siempre que el entrevistador vea que Zookeeper (familiar y maestro) está escrito en su currículum, debe estar preparado para las siguientes 11 preguntas consecutivas.
NO1: ¿Qué es el cuidador del zoológico?
ZooKeeper es un servicio de coordinación de aplicaciones distribuidas de código abierto distribuido. Es una implementación de código abierto de Chubby de Google (Chubby no es de código abierto). Es el administrador del clúster y supervisa el estado de cada nodo del clúster. Envíe los comentarios para la próxima operación razonable. Al final, se proporcionará a los usuarios una interfaz simple y fácil de usar y un sistema con alto rendimiento y funciones estables.
Uno de los escenarios de uso más comunes de Zookeeper es servir como centro de registro para productores de servicios y consumidores de servicios. Los productores de servicios registran sus servicios en el centro de Zookeeper y los consumidores de servicios primero miran en Zookeeper cuando realizan llamadas de servicio. Servicio, luego de obtener la información detallada del productor del servicio, llame al contenido y datos del productor del servicio. Un ejemplo simple es el siguiente:
NO2: ¿Conoce la arquitectura del sistema de Zookeeper?
Las principales cosas que debemos comprender y dominar en el diagrama de arquitectura de Zoo Keeper son:
(1) ZooKeeper se divide en servidor (servidor) y cliente (cliente). El cliente puede conectarse a cualquier servidor de todo el servicio de ZooKeeper (a menos que el parámetro leaderServes esté establecido explícitamente y el líder no pueda aceptar conexiones de cliente).
(2) El cliente usa y mantiene una conexión TCP a través de la cual envía solicitudes, recibe respuestas, obtiene eventos observados y envía latidos. Si esta conexión TCP se interrumpe, el cliente intentará conectarse automáticamente a otro servidor de ZooKeeper. Cuando un cliente se conecta al servicio de ZooKeeper por primera vez, el servidor de ZooKeeper que acepta la conexión establecerá una sesión para el cliente. Cuando este cliente se conecta a otro servidor, el nuevo servidor restablecerá la sesión.
(3) Cada servidor en la figura anterior representa una máquina donde está instalado el servicio Zookeeper, es decir, el clúster completo que proporciona el servicio Zookeeper (o está compuesto por pseudo clústeres);
(4) Los servidores que componen el servicio ZooKeeper deben conocerse entre sí. Mantienen una imagen de estado en la memoria, así como registros de transacciones e instantáneas en el almacenamiento persistente Siempre que la mayoría de los servidores estén disponibles, el servicio ZooKeeper está disponible;
(5) Cuando se inicia ZooKeeper, se elegirá un líder de la instancia y el líder es responsable de procesar las actualizaciones de datos y otras operaciones. Una señal de una operación de actualización exitosa es si y solo si la mayoría de los servidores modifican con éxito los datos en la memoria. Cada servidor almacena una copia de los datos en la memoria.
(6) Zookeeper se puede replicar en grupos y la coherencia de los datos se mantiene entre los grupos a través del protocolo Zab (Zookeeper Atomic Broadcast);
(7) El protocolo Zab incluye dos fases: la fase de elección del líder y la fase Atomic Brodcast.
- a) Se elige un líder en el clúster y otras máquinas se denominan seguidores Todas las operaciones de escritura se envían al líder y todas las actualizaciones se notifican al seguidor a través de brodcast.
- b) Cuando el líder falla o pierde a la mayoría de sus seguidores, es necesario reelegir un nuevo líder para restaurar todos los servidores a un estado correcto.
- c) Cuando se elige al líder, y la mayoría de los servidores han completado la sincronización con el estado del líder, el proceso de elección del líder termina y se ingresa al proceso de transmisión de Atomic.
- d) Atomic Brodcast sincroniza la información entre el líder y el seguidor para garantizar que el líder y el seguidor tengan el mismo estado del sistema.
NO3: ¿Puedes hablar sobre el principio de funcionamiento de Zookeeper?
El núcleo de Zookeeper es la difusión atómica, mecanismo que garantiza la sincronización entre servidores. El protocolo que implementa este mecanismo se llama protocolo Zab.
El protocolo Zab tiene dos modos, que son el modo de recuperación (selección primaria) y el modo de transmisión (sincronización).
El nombre completo del protocolo Zab es Zookeeper Atomic Broadcast ** (Zookeeper Atomic Broadcast). Zookeeper utiliza el protocolo Zab para garantizar la consistencia final de las transacciones distribuidas. El protocolo Zab requiere que cada líder pase por tres etapas: descubrimiento, sincronización y transmisión.
Cuando se inicia el servicio o después de que el líder falla, Zab ingresa al modo de recuperación. Cuando el líder es elegido y la mayoría de los servidores han completado la sincronización con el estado del líder, el modo de recuperación finaliza. La sincronización de estado asegura que el líder y el servidor tengan el mismo estado del sistema.
Para garantizar la coherencia de la secuencia de la transacción, zookeeper utiliza un número de identificación de transacción creciente (zxid) para identificar la transacción. Todas las propuestas agregan zxid cuando se realizan. En la implementación, zxid es un número de 64 bits. La época usa sus 32 bits altos para identificar si la relación del líder ha cambiado. Cada vez que se selecciona un líder, tendrá una nueva época, que identifica el período actual del reinado del líder. Los 32 bits inferiores se utilizan para el conteo ascendente.
epoch：可以理解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。
Cada servidor tiene tres estados durante su trabajo:
- MIRANDO: El servidor actual no sabe quién es el líder y está buscando.
- LIDERAZGO: El servidor actual es el líder elegido.
- SIGUIENTE: El líder ha sido elegido y el servidor actual está sincronizado con él.
NO4: ¿Por qué Zookeeper está diseñado así?
El propósito del diseño de ZooKeeper es proporcionar servicios de coordinación distribuidos de alto rendimiento, alta disponibilidad y coherencia secuencial para garantizar la coherencia de los datos finales.
高性能（简单的数据模型）
- Organice los nodos de datos en una estructura de árbol;
- Todos los nodos de datos se almacenan en la memoria;
- El seguidor y el observador manejan directamente las solicitudes no transaccionales;
高可用（构建集群）
- Si más de la mitad de las máquinas sobreviven, el servicio puede funcionar normalmente.
- Elección automática de líder
顺序一致性（事务操作的顺序）
- Cada solicitud de transacción se enviará a Leader para su procesamiento.
- A cada transacción se le asignará una identificación incremental única a nivel mundial (zxid, 64 bits: época + identificación de autoincremento)
最终一致性
- Garantizar la confiabilidad del envío de transacciones mediante la votación de propuestas.
- El método de votación propuesto solo puede garantizar que más de la mitad de los nodos puedan ver los datos más recientes después de que el cliente reciba el envío de la transacción con éxito
NO5: ¿Sabes qué roles hay en Zookeeper?
Modelo de sistema:
领导者（leader）
El servidor Leader proporciona servicios de lectura y escritura para los clientes. Responsable del inicio y resolución de votaciones, y actualización del estado del sistema.
学习者（learner）
followerFollower ( ) El servidor Follower proporciona servicios de lectura para los clientes, participa en el proceso de elección de líder y participa en la operación de escritura, estrategia de "más de la mitad de escritura exitosa".- Observer (
observer) El servidor Observer proporciona servicios de lectura para los clientes, no participa en el proceso de elección de líder y no participa en la operación de escritura "más de la mitad del éxito de escritura". Se utiliza para mejorar el rendimiento de lectura del clúster sin afectar el rendimiento de escritura.
客户端（client）: El originador de la solicitud de servicio.
NO6: ¿Está familiarizado con el nodo ZNode de Zookeeper y los atributos relacionados?
¿Qué tipos de nodos existen?
Znode两种类型：
Persistente (persistente): después de que el cliente y el servidor se desconectan, el nodo creado no se elimina (predeterminado).
Efímero: después de que el cliente y el servidor se desconectan, el nodo creado se elimina por sí mismo.
Znode有四种形式：
- Nodo de directorio persistente (PERSISTENT): después de que el cliente se desconecta de Zookeeper, el nodo todavía tiene un nodo de directorio de número de secuencia persistente (PERSISTENT_SEQUENTIAL)
- Después de que el cliente se desconecta de Zookeeper, el nodo aún existe, pero Zookeeper da el nombre del nodo secuencialmente número: Nodo de directorio temporal (EPHEMERAL)
- Después de que el cliente se desconecta de Zookeeper, el nodo se elimina: nodo de directorio de numeración de secuencia temporal (EPHEMERAL_SEQUENTIAL)
- Después de que el cliente se desconecta de Zookeeper, el nodo se elimina, pero Zookeeper le da al nombre del nodo un número secuencial.
"Nota" : Establezca el identificador de secuencia al crear el ZNode. Se agregará un valor al nombre del ZNode. El número de secuencia es un contador que aumenta monótonamente mantenido por el nodo principal.
Cuáles son los atributos del nodo
Un nodo znode no solo puede almacenar datos, sino también algunos otros atributos especiales. A continuación, creamos un nodo / test para analizar el significado de sus diversos atributos.
[zk: localhost:2181(CONNECTED) 6] get /test
456
cZxid = 0x59ac //
ctime = Mon Mar 30 15:20:08 CST 2020
mZxid = 0x59ad
mtime = Mon Mar 30 15:22:25 CST 2020
pZxid = 0x59ac
cversion = 0
dataVersion = 2
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 3
numChildren = 0
属性说明
NO7: Describa brevemente el proceso de selección principal de Zookeeper
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。leader选举是保证分布式数据一致性的关键。
出现选举主要是两种场景：初始化、leader不可用。
当zk集群中的一台服务器出现以下两种情况之一时，就会开始leader选举。
（1）服务器初始化启动。
（2）服务器运行期间无法和leader保持连接。
而当一台机器进入leader选举流程时，当前集群也可能处于以下两种状态。
（1）集群中本来就已经存在一个leader。
（2）集群中确实不存在leader。
首先第一种情况，通常是集群中某一台机器启动比较晚，在它启动之前，集群已经正常工作，即已经存在一台leader服务器。当该机器试图去选举leader时，会被告知当前服务器的leader信息，它仅仅需要和leader机器建立连接，并进行状态同步即可。
重点是leader不可用了，此时的选主制度。
投票信息中包含两个最基本的信息。
sid：即server id，用来标识该机器在集群中的机器序号。
zxid：即zookeeper事务id号。
ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id,，该id称为zxid.，由于zxid的递增性质, 如果zxid1小于zxid2,，那么zxid1肯定先于zxid2发生。创建任意节点，或者更新任意节点的数据， 或者删除任意节点，都会导致Zookeeper状态发生改变，从而导致zxid的值增加。
以（sid，zxid）的形式来标识一次投票信息。
例如：如果当前服务器要推举sid为1，zxid为8的服务器成为leader，那么投票信息可以表示为（1，8）
集群中的每台机器发出自己的投票后，也会接受来自集群中其他机器的投票。每台机器都会根据一定的规则，来处理收到的其他机器的投票，以此来决定是否需要变更自己的投票。
规则如下：
（1）初始阶段，都会给自己投票。
（2）当接收到来自其他服务器的投票时，都需要将别人的投票和自己的投票进行pk，规则如下：
优先检查zxid。zxid比较大的服务器优先作为leader。如果zxid相同的话，就比较sid，sid比较大的服务器作为leader。
NO8：有了解过watch机制吗？
简单地说：client端会对某个znode 注册一个watcher事件，当该znode发生变化时，这些client会收到ZooKeeper的通知，然后client可以根据znode变化来做出业务上的改变等。
经典使用场景：zookeeper为dubbo提供服务的注册与发现，作为注册中心，但是大家有没有想过zookeeper为啥能够实现服务的注册与发现吗？
这就不得不说一下zookeeper的灵魂 Watcher（监听者）。
什么是watcher？
watcher 是zooKeeper中一个非常核心功能 ，客户端watcher 可以监控节点的数据变化以及它子节点的变化，一旦这些状态发生变化，zooKeeper服务端就会通知所有在这个节点上设置过watcher的客户端 ，从而每个客户端都很快感知，它所监听的节点状态发生变化，而做出对应的逻辑处理。
简单的介绍了一下watcher ，那么我们来分析一下，zookeeper是如何实现服务的注册与发现。zookeeper的服务注册与发现，主要应用的是zookeeper的znode节点数据模型和watcher机制，大致的流程如下：
- 服务注册：服务提供者（Provider）启动时，会向zookeeper服务端注册服务信息，也就是创建一个节点，例如：用户注册服务com.xxx.user.register，并在节点上存储服务的相关数据（如服务提供者的ip地址、端口等）。
- 服务发现：服务消费者（Consumer）启动时，根据自身配置的依赖服务信息，向zookeeper服务端获取注册的服务信息并设置watch监听，获取到注册的服务信息之后，将服务提供者的信息缓存在本地，并进行服务的调用。
- 服务通知：一旦服务提供者因某种原因宕机不再提供服务之后，客户端与zookeeper服务端断开连接，zookeeper服务端上服务提供者对应服务节点会被删除（例如：用户注册服务com.xxx.user.register），随后zookeeper服务端会异步向所有消费用户注册服务com.xxx.user.register，且设置了watch监听的服务消费者发出节点被删除的通知，消费者根据收到的通知拉取最新服务列表，更新本地缓存的服务列表。
上边的过程就是zookeeper可以实现服务注册与发现的大致原理。
watcher有哪些类型？
znode节点可以设置两类watch，一种是DataWatches，基于znode节点的数据变更从而触发 watch 事件，触发条件getData()、exists()、setData()、 create()。
另一种是Child Watches，基于znode的孩子节点发生变更触发的watch事件，触发条件 getChildren()、 create()。
而在调用 delete() 方法删除znode时，则会同时触发Data Watches和Child Watches，如果被删除的节点还有父节点，则父节点会触发一个Child Watches。
watcher有什么特性？
watch对节点的监听事件是一次性的！客户端在指定的节点设置了监听watch，一旦该节点数据发生变更通知一次客户端后，客户端对该节点的监听事件就失效了。
如果还要继续监听这个节点，就需要我们在客户端的监听回调中，再次对节点的监听watch事件设置为True。否则客户端只能接收到一次该节点的变更通知。
NO9：那你说说Zookeeper有哪些应用场景？
数据发布与订阅
发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZooKeeper节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。
配置信息一般有几个特点:
- 数据量小的KV
- 数据内容在运行时会发生动态变化
- 集群机器共享，配置一致
ZooKeeper 采用的是推拉结合的方式。
- 推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知
- 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据
命名服务
作为分布式命名服务，命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。
统一命名服务的命名结构图如下所示：
1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。
- 类似于域名与IP之间对应关系，IP不容易记住，而域名容易记住。
- 通过名称来获取资源或服务的地址，提供者等信息。
2、按照层次结构组织服务/应用名称。
- 可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。
配置管理
程序分布式的部署在不同的机器上，将程序的配置信息放在ZooKeeper的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用watch通知给各个客户端 从而更改配置。
ZooKeeper配置管理结构图如下所示：
1、分布式环境下，配置文件管理和同步是一个常见问题。
- 一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
- 对配置文件修改后，希望能够快速同步到各个节点上。
2、配置管理可交由ZooKeeper实现。
- 可将配置信息写入ZooKeeper上的一个Znode。
- 各个节点监听这个Znode。
- 一旦Znode中的数据被修改，ZooKeeper将通知各个节点。
集群管理
所谓集群管理就是：是否有机器退出和加入、选举master。
集群管理主要指集群监控和集群控制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行操作与控制。开发和运维中，面对集群，经常有如下需求:
- 希望知道集群中究竟有多少机器在工作
- 对集群中的每台机器的运行时状态进行数据收集
- 对集群中机器进行上下线的操作
集群管理结构图如下所示：
1、分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。
2、可交由ZooKeeper实现。
- 可将节点信息写入ZooKeeper上的一个Znode。
- 监听这个Znode可获取它的实时状态变化。
3、典型应用
- Hbase中Master状态监控与选举。
利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功
分布式通知与协调
1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。
a）NameNode需知道各个Datanode的状态。
b）JobTracker需知道各个TaskTracker的状态。
2、心跳检测机制可通过ZooKeeper来实现。
3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。
分布式锁
处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。
分布式锁具有以下特性：写锁、读锁、时序锁。
写锁：在zk上创建的一个临时的无编号的节点。由于是无序编号，在创建时不会自动编号，导致只能客户端有一个客户端得到锁，然后进行写入。
读锁：在zk上创建一个临时的有编号的节点，这样即使下次有客户端加入是同时创建相同的节点时，他也会自动编号，也可以获得锁对象，然后对其进行读取。
时序锁：在zk上创建的一个临时的有编号的节点根据编号的大小控制锁。
分布式队列
分布式队列分为两种：
1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
a）一个job由多个task组成，只有所有任务完成后，job才运行完成。
b）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。
2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。
NO10：知道监听器的原理吗？
- 创建一个Main()线程。
- 在Main()线程中创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。
- 通过connect线程将注册的监听事件发送给Zookeeper。
- 将注册的监听事件添加到Zookeeper的注册监听器列表中。
- Zookeeper监听到有数据或路径发生变化时，把这条消息发送给Listener线程。
- Listener线程内部调用process()方法。
NO11：为什么Zookeeper集群的数目，一般为奇数个？
首先需要明确zookeeper选举的规则：leader选举，要求可用节点数量 > 总节点数量/2。
比如：标记一个写是否成功是要在超过一半节点发送写请求成功时才认为有效。同样，Zookeeper选择领导者节点也是在超过一半节点同意时才有效。最后，Zookeeper是否正常是要根据是否超过一半的节点正常才算正常。这是基于CAP的一致性原理。
zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。
也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；
同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；
同理：
2-> 0; Dos cuidadores del zoológico, hasta 0 cuidadores pueden no estar disponibles.
3-> 1; Tres cuidadores del zoológico, hasta 1 cuidador del zoológico puede no estar disponible.
4-> 1; Cuatro cuidadores del zoológico, hasta 1 cuidador del zoológico puede no estar disponible.
5-> 2; Cinco cuidadores del zoológico, hasta 2 cuidadores pueden no estar disponibles.
6-> 2; Dos cuidadores del zoológico, hasta 0 cuidadores pueden no estar disponibles.
....
Encontrará una regla de que la tolerancia de 2n y 2n-1 es la misma, ambos son n-1, así que para ser más eficiente, ¿por qué agregar un cuidador del zoológico innecesario?
La estrategia de elección de Zookeeper también requiere que más de la mitad de los nodos acuerden ser elegidos como líderes, y si es un número par de nodos, puede dar lugar a la misma cantidad de votos.
para resumir
Para muchos entrevistadores, la rutina de la entrevista es básicamente esto, desde el trasfondo hasta el principio, el sistema de arquitectura, las características inherentes de Zookeeper, y finalmente se requiere que el entrevistador cuente los escenarios reales de aplicación de Zookeeper.
"Si aprende más de la misma habilidad, no dirá ni una palabra de pedir ayuda".
Empuje la lectura de lectura recomendada
Master Mybatis dynamic mapping, he trabajado duro en todo el 2020 original