zookeeper

zookeeper

1、zk解决的问题：
　　1.分布式环境下的数据一致性。
　　2.分布式环境下的统一命名服务。
　　3.分布式环境下的配置管理。
　　4.分布式环境下的分布式锁。单台机器使用的锁：同步代码块、重入锁。但是在分布式环境这个锁就发挥不出来作用。分布锁分为共享锁和排他锁。
　　５.集群管理问题。
２、分布式编程容易出现的问题：
　　1.死锁
　　2.活锁
　　　活锁定义：在程序里，由于某些条件的发生碰撞，导致重新执行，再碰撞=》再执 行，如此循环往复，就形成了活锁。活锁的危害：多个线程争用一个资源，但是没有任何一个 线程能拿到这个资源。（死锁是有一个线程拿到资源，但相互等待互不释放造成死锁），活锁 是死锁的变种。补充:活锁更深层次的危害，很容易耗尽Cpu资源(在做无意义的调度)。
　　3.需要考虑集群的管理问题，需要有一套机制来检测到集群里节点的状态变化。（可以用心跳 机制来做，但zk不是用心跳机制来做的）。
　　4.如果用一台机器做集群管理，存在单点故障问题，所以针对集群管理，也需要形成一个集群。
　　5.管理集群里Leader的选举问题（要根据一定的算法和规则来选举），包括要考虑Leader挂掉 之后，如何从剩余的follower里选出Leader。
　　6.分布式锁的实现，用之前学的重入锁，同步代码块是做不了的。
三、zk节点分四种类型：
　　1.普通持久节点。
　　2.普通临时节点:创建此临时节点的客户端失去和zk连接后，此节点消失，zk是通过临时节点监控哪个服务器挂掉的。
　　3.顺序持久节点:会根据用户指定的节点路径，自动分配一个递增的顺序号。(顺序节点实现分布式锁的效果，服务器1抢到zk05分配zk050001,服务器2抢到zk05分配zk050002)。
　　4.顺序临时节点。
四、Zookeeper事务概念
　　1.每一个写操作都是一个事务，每一个事务都用一个事务id来代表，叫：zxid 。
　　2.zxid 是全局唯一，并且全局递增的。作用就是可以根据最大事务id，找到最新的事务。
五、Zookeeper选举机制
　　选举的pk原则：1.首先比较最大事务id，Zxid，谁大谁当领导。3.如果Zxid比较不出来，比较myid(选举id),谁大谁当领导。3.选举的前提满足过半同意。
五、选举分两个阶段
　　1.数据恢复节点：当zk服务器启动时，会先从本地磁盘找到本机的最大事务id。
　　2.选举阶段：zk服务器会提交选举协议 1.Zxid（最大事务id） 2.本机的选举id（myid文件里的数字） 3.逻辑时钟值 记录当前的选举轮数，确保每个zk在同一轮选举中 4.当前zk服务器状态，分4种： Looking=>选举阶段 Following=>当小弟阶段 Leading=>当领导阶段 Observering=>观察者阶段。
六、Leader选举出来之后
　　 Leader身上肯定是有最新数据的（有最大事务id的），所以首先做的就是原子广播（通过原子 广播端口）。 原子广播的目的就是为了确保数据一致性（即客户端无论通过哪个zk服务器查看数据，数据都是一样的）目的二就是为了防止leader挂掉之后，数据的丢失问题对于事务更新，Leader会通过原子广播征询其他follower，只要满足过半同意机制，事务才能被更新。
七、zxid
　　znode节点的状态信息中包含czxid和mzxid, 那么什么是zxid呢?
ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生. 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加。
八、节点类型
　　 persistent节点不和特定的session绑定, 不会随着创建该节点的session的结束而消失, 而是一直存在, 除非该节点被显式删除ephemeral.。ephemeral节点是临时性的, 如果创建该节点的session结束了, 该节点就会被自动删除. ephemeral节点不能拥有子节点. 虽然ephemeral节点与创建它的session绑定, 但只要该该节点没有被删除, 其他session就可以读写该节点中关联的数据. 使用-e参数指定创建ephemeral节点。
九、观察者模式
　　为了提高Zk性能，处理思想就是减少投票人数。（前提是满足过半机制），由此，zk引出了观 察者模式 观察者特点：1.不参与投票（选举的投票以及事务更新的投票）。2.观察者会跟随最后的投票结果。
十、实现消息订阅和发布思路：
　　1、创建一个znode节点 /data。
　　2.其他订阅节点监听/data 节点的数据变化事件。
　　3.如果有事件发生，就获取/data节点的数据。
十一、实现集群整体的配置信息管理
　　比如某一个机器的配置信息发生变化，其他机器的配置信息也实现同步更改。实现思路按照消息订阅和发布来的。
十二、集群管理
　　能够快速检测出集群里节点的状态。实现思路：临时节点+监听机制
十三、实现分布式锁
　　实现思路：利用顺序节点来实现，比如4个客户端争相抢注 /source顺序临时节点。最先抢注的顺序号最小， 就分配给这个节点资源，该节点对应的服务器执行完后，session回话断开，对应的source001临时节点就销毁了。接下source002对应的服务器执行操作。
十四、实现命名服务
　　利用znode路径的唯一性，来做命名服务。
十五、zk不适用于做的事情
　　不能用zk存储大量数据。znode树是维系在内存里的，如果数据大，会吃掉大量内存。
十六、Zookeeper的特性
　　 1、数据一致性（单一视图）
　　　client不论连接到哪个Zookeeper，展示给它都是同一个视图，即查询的数据都是一样的。这是zookeeper最重要的性能。
　　　2、原子性
　　　 　对于事务决议的更新，只能是成功或者失败两种可能，没有中间状态。要么都更新成功，要么 都不更新。即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会 出现集群中部分机器应用了改事务，另外一部分没有应用的情况。
　　　 ３、可靠性
　　　 　一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态 变更将会一直保留下来，除非有另一个事务又对其进行了改变。
　　　 ４、实时性
　　　 　Zookeeper保证客户端将在非常短的时间间隔范围内获得服务器的更新信息，或者服务器失效 的信息，或者指定监听事件的变化信息。（前提条件是：网络状况良好）。
　　　 ５、顺序性(根据命令版本号来实现的)
　　　 　包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有 Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
　　　 6、过半性 zookeeper
　　　 　集群必须有半数以上的机器存活才能正常工作。因为只有满足过半数，才能满足选举机制选出Leader。因为只有过半，在做事务决议时，事务才能更新。 所以一般来说，zookeeper集群的数量最好是奇数个。