某大佬在微信群分享zookeeper原理

null:

第一题  1、对于 zk 的节点类型，谈一下你的认识?

null:

每个 znode 根据节点类型的不同，具有不同的生命周期与特性。

null:

持久节点：节点被创建后会一直保存在 zk 中，直到将其删除。

null:

持久顺序节点：一个父节点可以为它的第一级子节点维护一份顺序，用于记录每个子节点创建的先后顺序。其在创建子节点时，会在子节点名称后添加数字后辍，作为该子节点的完整节点名。序号由 10 位数字组成，由这些子节点的父节点维护，从 0 开始计数。

null:

临时节点：临时节点的生命周期与客户端的会话绑定在一起，会话消失则该节点就会被自动清理。

null:

临时顺序节点：添加了创建序号的临时节点。

null:

第二题  2、对于 zk 来说 watcher 机制非常重要，watcher 机制的工作原理是怎样的？谈一下你的认识？

null:

当客户端想要监听 zk 中某节点的状态变化时，需要向该节点注册 watcher 监听。

null:

其首先会在客户端创建一个 watcher 对象，并为其添加相应的回调。当 zk 中对应的节点发生了相应的 watcher 事件后，zk 会向客户端发送事件通知，触发该 watcher 回调的执行。

null:

执行完毕，该 watcher 对象销毁。若要再次监听，则需再次注册。

null:

第三题  3、对于 zk 官方给出了四种最典型的应用场景，配置维护就是之一。什么是配置维护？请谈一下你的看法？

null:

分布式系统中，很多服务都是部署在集群中的，即多台服务器中部署着完全相同的应用，起着完全相同的作用。当然，集群中的这些服务器的配置文件是完全相同的。

null:

若集群中服务器的配置文件需要进行修改，那么我们就需要逐台修改这些服务器中的配置文件。如果我们集群服务器比较少，那么这些修改还不是太麻烦，但如果集群服务器特别多，比如某些大型互联网公司的 Hadoop 集群有数千台服务器，那么纯手工的更改这些配置文件几乎就是一件不可能完成的任务。即使使用大量人力进行修改可行，但过多的人员参与，出错的概率大大提升，对于集群所形成的危险是很大的。

null:

zk 可以通过一种发布订阅模式对集群中的配置文件进行统一管理，这就是配置维护。

其作用与 Spring Cloud Config 的作用相同。

null:

第四题  4、使用 zk 可以实现 Master 选举，实现原理是什么？请谈一下你的看法？

null:

使用 zk 实现 Master 选举的原理是，集群中所有主机都向 zk 中创建相同路径下的某持久节点注册子节点列表变更 watcher 监听，并在该节点下持久相同名称的临时节点，谁创建成功谁就是 Master。

null:

当 Master 宕机，该临时节点消失，此时会触发其他主机 watcher 回调的执行。watcher回调会重新抢注该节点下的临时节点，谁注册成功谁就是 Master。即可以实现 Master 宕机后的自动重新选举。

null:

第五题  5、zk 可以实现分布式锁，Redis 也可以实现。由它们实现的分布式锁有什么区别？请谈一下你的认识？

null:

使用 zk 实现的分布式锁是 CP 的分布式锁。因为 zk 是 CP 的。在某客户端向 zk 集群中的某节点写入数据后，会等待超过半数的其它节点完成同步后，才会响应该客户端。

null:

使用 Redis 实现的分布式锁是 AP 的分布式锁。因为 Redis 是 AP 的。在某客户端向 Redis集群中的某节点写入数据后，会立即响应该客户端，之后在 Redis 集群中会以异步的方式来同步数据。

null:

对于 AP 的分布式锁，需要注意可能会出现的问题：一个客户端 a 在 Redis 集群的某节点 A 写入数据后，另一个节点 B 在还未同步时，另一个客户端 b 从 B 节点读取数据，没有发现 a 写入的数据。此时可能会出现问题。

null:

所以，如果某共享资源要求必须严格按照锁机制进行访问，那么就使用 zk 实现的 CP 锁。