zookeeper live（一）zk简单介绍
-
在单个机器开发的时候，直接把配置文件放到本机上就行，但在分布式开发过程中，最原始的过程中，每个节点维护有一份配置信息，每个应用去访问不同的节点，这有个弊端，比如改了配置一的配置信息，配置二三需要一致性维护，这比较麻烦
-
将配置文件放到一个节点上，如果这个节点宕机，则全挂了。
-
所以，将配置文件放到集群当中，在集群中放几个节点，每个节点放同样的配置文件，即使里边有一个节点宕机了，则还有别的节点提供。
-
利用监听机制，只要修改一个配置文件，则会同步到其他配置文件。在zk只要有一半以上同步成功，则认为是已经同步成功。
-
zk更适用于以查询为主的场景。
-
因为zookeeper是一个集群，支持横向可拓展性，zk里只有一个leader，处理事务请求，其他的follower只能提供非事务请求。如果事务操作比较频繁的情况下，横向拓展则没什么意义；如果事务操作不频繁，则可以横向拓展。
-
客户端在选择哪一个集群节点去访问呢？它会选择随机访问或者轮询访问，如果是发送的非事务请求，则follower会直接返回它的请求，如果是事务的请求，会先请求leader再返回给它。
-
zookeeper每个节点只能存储很少量的数据。
-
zookeeper是以树形结构管理节点的，每个节点叫做znode，可以在每个znode下面创建子节点
-
znode的类型，临时节点（一宕机就消失，后边不能创建子节点；与客户端对话结束，zookeeper会将临时节点删除），持久节点（只有客户端手动删除才会消失），顺序节点
-
zookeeper角色：
-
leader：选举选出来的
-
learner
-
follower：选leader，参与事务请求和非事务请求。
-
observer：单纯为客户端提供非事务请求，不参与leader选举，提高zk集群读性能
-
-
-
zookeeper读写机制
-
zookeeper是多个server组成的集群
-
由一个leader和多个follower组成
-
每个server保存一份数据副本
-
全局数据一致
-
更新请求转发，即使事务请求转发到了follower，它也会转发给leader执行。
-
-
zookeeper：保证
-
首先每个节点server里会维护队列，存放着server收到的请求，先进先出的顺序去执行请求。
-
数据的原子性，一次数据更新，要么成功，要么失败
-
实时性，一定事件范围内，client能读到最新数据
-
-
zookeeper：watcher监听机制
-
watcher是zookeeper的一个核心功能，可以监听目录节点和子节点的数据变化，一旦节点发生变化
-