ZooKeeper - 常见问题
在一致性协议方面，注重CP。
首先，Zookeeper集群中有几个关键的概念，Leader、Follower和Observer，Zookeeper中通常只有Leader节点可以写入，Follower和Observer都只是负责读，但是Follower会参与节点的选举和过半写成功，Observer则不会，他只是单纯的提供读取数据的功能。
通常这样设置的话，是为了避免太多的从节点参与过半写的过程，导致影响性能，这样Zookeeper只要使用一个几台机器的小集群就可以实现高性能了，如果要横向扩展的话，只需要增加Observer节点即可。
ZooKeeper建议集群节点个数为奇数，只要超过一半的机器能够正常提供服务，那么整个集群都是可用的状态。
Zookeeper中数据存储于内存之中，这个数据节点就叫做Znode，他是一个树形结构，比如/a/b/c类似。
而Znode又分为持久节点、临时节点、顺序节点三大类。
持久节点是指只要被创建，除非主动移除，否则都应该一直保存在Zookeeper中。
临时节点不同的是，他的生命周期和客户端Session会话一样，会话失效，那么临时节点就会被移除。
还有就是临时顺序节点和持久顺序节点，除了基本的特性之外，子节点的名称还具有有序性。
会话自然就是指Zookeeper客户端和服务端之间的通信，他们使用TCP长连接的方式保持通信，通常，肯定会有心跳检测的机制，同时他可以接受来自服务器的Watch事件通知。
用户可以在指定的节点上注册Wather，这样在事件触发的时候，客户端就会收到来自服务端的通知。
Zookeeper使用ACL来进行权限的控制，包含以下5种：
CREATE，创建子节点权限
DELETE，删除子节点权限
READ，获取节点数据和子节点列表权限
WRITE，更新节点权限
ADMIN，设置节点ACL权限
所以，ZooKeeper通过集群的方式来做到高可用，通过内存数据节点Znode来达到高性能，但是存储的数据量不能太大，通常适用于读多写少的场景。
Zookeeper可以提供分布式数据的发布/订阅功能，依赖的就是Wather监听机制。
客户端可以向服务端注册Wather监听，服务端的指定事件触发之后，就会向客户端发送一个事件通知。
他有几个特性：
Zookeeper通过ZAB原子广播协议来实现数据的最终顺序一致性，他是一个类似2PC两阶段提交的过程。
由于Zookeeper只有Leader节点可以写入数据，如果是其他节点收到写入数据的请求，则会将之转发给Leader节点。
主要流程如下：
Leader收到请求之后，将它转换为一个proposal提议，并且为每个提议分配一个全局唯一递增的事务ID：zxid，然后把提议放入到一个FIFO的队列中，按照FIFO的策略发送给所有的Follower
Follower收到提议之后，以事务日志的形式写入到本地磁盘中，写入成功后返回ACK给Leader
Leader在收到超过半数的Follower的ACK之后，即可认为数据写入成功，就会发送commit命令给Follower告诉他们可以提交proposal了
ZAB包含两种基本模式，崩溃恢复和消息广播。
整个集群服务在启动、网络中断或者重启等异常情况的时候，首先会进入到崩溃恢复状态，此时会通过选举产生Leader节点，当集群过半的节点都和Leader状态同步之后，ZAB就会退出恢复模式。之后，就会进入消息广播的模式。
Leader的选举可以分为两个方面，同时选举主要包含事务zxid和myid，节点主要包含3个状态
首先，每个节点都会对自己进行投票，然后把投票信息广播给集群中的其他节点
节点接收到其他节点的投票信息，然后和自己的投票进行比较，首先zxid较大的优先，如果zxid相同那么则会去选择myid更大者，此时大家都是LOOKING的状态
投票完成之后，开始统计投票信息，如果集群中过半的机器都选择了某个节点机器作为leader，那么选举结束
最后，更新各个节点的状态，leader改为LEADING状态，follower改为FOLLOWING状态
如果开始选举出来的leader节点宕机了，那么运行期间就会重新进行leader的选举。
leader宕机之后，非observer节点都会把自己的状态修改为LOOKING状态，然后重新进入选举流程
生成投票信息(myid,zxid)，同样，第一轮的投票大家都会把票投给自己，然后把投票信息广播出去
接下来的流程和上面的选举是一样的，都会优先以zxid，然后选择myid，最后统计投票信息，修改节点状态，选举结束。
还是会存在的，可以分成3个场景来描述这个问题。
因为ZooKeeper是过半成功即代表成功，假设我们有5个节点，如果123节点写入成功，如果这时候请求访问到4或者5节点，那么有可能读取不到数据，因为可能数据还没有同步到4、5节点中，也可以认为这算是数据不一致的问题。
解决方案可以在读取前使用sync命令。
这也就是数据同步说过的问题。
leader刚生成一个proposal，还没有来得及发送出去，此时leader宕机，重新选举之后作为follower，但是新的leader没有这个proposal。
这种场景下的日志将会被丢弃。
如果发送proposal成功了，但是在将要发送commit命令前宕机了，如果重新进行选举，还是会选择zxid最大的节点作为leader，因此，这个日志并不会被丢弃，会在选举出leader之后重新同步到其他节点当中。
常见分布式集群选举机制总结
1，Zookeeper -- paxos 2，kafka -- zookeeper上创建节点 3，redis -- 哨兵模式 4，Eureka -- 相互复制 我们探讨这几个集群的选举机制，其实就是探讨它们的高可用性。如果集群中的某些节点挂了，如何保证可用性？这个问题是分布式系统面临的三大问题之一。Zookeeper的leader选举机制，是这四种集群中最...
Zookeeper 介绍及应用场景分析
通过在特定节点上注册监听器，系统可以实时接收机器增减的消息，简化了传统监控系统中的复杂操作和延迟问题。Leader选举Zookeeper 通过 EPHEMERAL_SEQUENTIAL 目录节点实现了动态选举 Leader 的机制。节点编号最小的节点被选为 Leader，当 Leader 失效时，系统自动选择新的 Leader，避免了传统单点故障的问题。分...
常见大数据公司面试问题有哪些?
2、告诉我们大数据和Hadoop之间的关系。答： 大数据和Hadoop几乎是同义词。随着大数据的兴起，专门用于大数据操作的Hadoop框架也开始流行。专业人士可以使用该框架来分析大数据并帮助企业做出决策。注意： 在大数据采访中通常会问这个问题。 可以进一步去回答这个问题，并试图解释的Hadoop的主要组成部分。3、大数据...
Kafka服务端--Zookeeper职责
本文综述了Kafka在Zookeeper中的元数据管理结构，涵盖了常见元数据节点与路径解析。需要注意的是，虽然KIP500提出了KRaft技术，旨在减少对Zookeeper的依赖，但当前版本（2.5.2）并未彻底移除Zookeeper，Kafka 3.0.0版本同样未在生产环境中大规模应用此技术。Zookeeper在Kafka系统中的关键作用仍需进一步关注与...
怎样进行大数据的入门级学习
Zookeeper：这是个万金油，安装Hadoop的HA的时候就会用到它，以后的Hbase也会用到它。它一般用来存放一些相互协作的信息，这些信息比较小一般不会超过1M，都是使用它的软件对它有依赖，对于我们个人来讲只需要把它安装正确，让它正常的run起来就可以了。Mysql：我们学习完大数据的处理了，接下来学习学习小...
docker安装zookeeper&zookeeper基本使用(非常详细)
格式:create [-s] [-e] [-c] [-t ttl] path [data] [acl] 解释:[-s] : 创建有序结点 [-e] : 创建临时结点 [-c] : 创建一个容器结点,容器结点主要用来容纳字结点,如果没有给其创建子结点,容器结点表现和持久化结点一样,如果给容器结点创建了子结点,后续又把子结点清空,容器结点也会被zookeeper...
Flink面试题
申请 7 个 taskManager，每个 8 核，每个 taskmanager 有 32768M 内存。集群默认有一个 Job Manager。为防止单点故障，配置了一个主 Job Manager 和两个备用 Job Manager，结合 ZooKeeper 使用，实现高可用。问题：怎么做压力测试和监控？解答：压力测试主要考虑数据流速度过快，下游算子消费不过时导致的...
Zookeeper深入原理(2) - Watcher 监听机制
curator-framework ：对zookeeper的底层api的一些封装 curator-recipes ：封装了一些高级特性，如：Cache事件监听、选举、分布式锁、分布式计数器等 Maven依赖(使用curator的版本：2.12.0，对应Zookeeper的版本为：3.4.x，如果跨版本会有兼容性问题，很有可能导致节点操作失败)： 1. ...
大数据Hadoop之ZooKeeper认识
这种做法可行，但是存在两个比较明显的问题：1）.集群中机器有变动的时候，牵连修改的东西比较多。2）.有一定的延时。利用ZooKeeper中两个特性，就可以实施另一种集群机器存活性监控系统：1）.客户端在示例节点A上注册一个监控者（Watcher），那么如果A的子节点变化了，会通知该客户端。2）.创建EPHEMERAL...
Zookeeper 理论基础
该方式解决了“活锁”问题。 ZAB ,Zookeeper Atomic Broadcast,zk 原子消息广播协议,是专为 ZooKeeper 设计的一种支持崩溃恢复的原子广播协议,在 Zookeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性。 Zookeeper 使用一个单一主进程来接收并处理客户端的所有事务请求,即写请求。当服务器数据的状态发生变更后,集群...