zookeeper

zookeeper

1、zk解决的问题:
  1.分布式环境下的数据一致性。
  2.分布式环境下的统一命名服务。
  3.分布式环境下的配置管理。
  4.分布式环境下的分布式锁。单台机器使用的锁:同步代码块、重入锁。但是在分布式环境这个锁就发挥不出来作用。分布锁分为共享锁和排他锁。
  5.集群管理问题。
2、分布式编程容易出现的问题:
  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、原子性
     对于事务决议的更新,只能是成功或者失败两种可能,没有中间状态。要么都更新成功,要么 都不更新。即,要么整个集群中所有机器都成功应用了某一事务,要么都没有应用,一定不会 出现集群中部分机器应用了改事务,另外一部分没有应用的情况。
    3、可靠性
     一旦服务端成功的应用了一个事务,并完成对客户端的响应,那么该事务所引起的服务端状态 变更将会一直保留下来,除非有另一个事务又对其进行了改变。
    4、实时性
     Zookeeper保证客户端将在非常短的时间间隔范围内获得服务器的更新信息,或者服务器失效 的信息,或者指定监听事件的变化信息。(前提条件是:网络状况良好)。
    5、顺序性(根据命令版本号来实现的)
     包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有 Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。
    6、过半性 zookeeper
     集群必须有半数以上的机器存活才能正常工作。因为只有满足过半数,才能满足选举机制选出Leader。因为只有过半,在做事务决议时,事务才能更新。 所以一般来说,zookeeper集群的数量最好是奇数个。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值