zookeeper
Zookeeper 简介
Zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户
Zookeeper 设计目标
-
简单的数据结构，Zookeeper 就是以简单的树形结构来进行协调的（也叫做树形名字空间）。
-
可以构建集群，一般 Zookeeper 集群通常甶一组机器构成，一般3~5台机器就可以组成一个 Zookeeper 集群了，只要集群中超过一半以上的机器能够正常工作，那么整个集群就能正常对外服务。
-
顺序访问。对于来自每一个客户端的每一个请求，Zookeeper 都会分配一个全局唯一的递增编号，这个编号反映了所有事物操作的先后顺序，应用程序可以使用 Zookeeper 的这个特性来实现更高层次的同步。
-
高性能，甶于 Zookeeper 将全量数据存储在内存中，并直接服务于所有的非事务请求，因此尤其 是在读操作为主的场景下，性能非常突出。在 JMeter 压力测试下（100%读请求），其结果大约在 12-13W 的 QPS。
QPS： 每秒查询率 QPS 是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
分布式协调技术
什么是分布式协调技术？分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成”脏数据”的后果。
分布式锁应用场景
在分布式锁服务中，有一种最典型应用场景，就是通过对集群进行 Master 选举，来解决分布式系统中的单点故障。什么是分布式系统中的单点故障：通常分布式系统采用主从模式，就是一个主控机连接多个处理节点。主节点负责分发任务，从节点负责处理任务，当我们的主节点发生故障时，那么整个系统就都瘫痪了，那么我们把这种故障叫作单点故障。
- 传统解决方案
传统方式是采用一个备用节点，这个备用节点定期给当前主节点发送 ping 包，主节点收到 ping 包以后向备用节点发送回复Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。 当主节点挂了，这时备用节点收不到回复了，备用节点就接替他成为主节点
::: tip 提示 方式就是有一个隐患，就是网络问题。主节点并没有挂，只是在回复的时候网络发生故障，这样我们的备用节点同样收不到回复，就会认为主节点挂了，然后备用节点将他的Master实例启动起来，这样我们的分布式系统当中就有了两个主节点也就是—双Master， 出现Master以后我们的从节点就会将它所做的事一部分汇报给了主节点，一部分汇报给了从节点，这样服务就全乱了。为了防止出现这种情况，我们引入了 Zookeeper，它虽然不能避免网络故障，但它能够保证每时每刻只有一个 Master。 :::
- Zookeeper 解决方案
在引入了 Zookeeper 以后我们启动了两个主节点，”主节点-A”和”主节点-B”他们启动以后，都向 Zookeeper 去注册一个节点。我们 假设”主节点-A”锁注册的节点是”master-00001”，”主节点-B”注册的节点是”master-00002”，注册完以后进行选举，编号最小的节点将在选举中获胜获得锁成为主节点，也就是我们的”主节点-A”将会获得锁成为主节点，然后”主节点-B”将被阻塞成为一个备用节点。那么，通过这种方式就完成了对两个 Master 进程的调度。
如果”主节点-A”挂了，这时候他所注册的节点将被自动删除，Zookeeper 会自动感知节点的变化，然后再次发出选举，这时候”主节点-B”将在选举中获胜，替代”主节点-A”成为主节点。
如果主节点恢复了，他会再次向 Zookeeper 注册一个节点，这时候他注册的节点将会是”master-00003”，Zookeeper 会感知节点的变化再次发动选举，这时候”主节点-B”在选举中会再次获胜继续担任”主节点”，”主节点-A”会担任备用节点。
- 数据发布/订阅
- 负载均衡
- 命名服务
- 分布式协调/通知
- 集群管理
- 选举
- 分布式锁
- 分布式队列
四种类型的数据节点 Znode
- PERSISTENT-持久节点
- EPHEMERAL-临时节点
- PERSISTENT_SEQUENTIAL-持久顺序节点
- EPHEMERAL_SEQUENTIAL-临时顺序节点
zookeeper 常用的命令
常用命令：ls get set create delete 等。