Zookeeper使用场景

数据发布/订阅 数据发布/订阅（Publish/Subscribe）系统，即所谓的配置中?，顾名思义就是发布者将数据发布到 ZooKeeper的?个或?系列节点上，供订阅者进?数据订阅，进?达到动态获取数据的?的，实现配置信息的集中式管理和数据的动态更新。发布/订阅系统?般有两种设计模式，分别是推（Push）模式和拉（Pull）模式。例如：配置存储在Zookeeper上选取?个数据节点?于配置信息的存储，例如：/app1/database_confifig

#数据库配置信息
#DBCP
dbcp.driverClassName=com.mysql.jdbc.Driver
dbcp.dbJDBCUrl=jdbc:mysql://127.0.0.1:3306/lagou-test
dbcp.username=zm
dbcp.password=1234
dbcp.maxActive=30
dbcp.maxIdle=10

配置获取 集群中每台机器在启动初始化阶段，?先会从上?提到的ZooKeeper配置节点上读取数据库信息，同时，客户端还需要在该配置节点上注册?个数据变更的 Watcher监听，?旦发?节点数据变更，所有订阅的客户端都能够获取到数据变更通知。 配置变更 在系统运?过程中，可能会出现需要进?数据库切换的情况，这个时候就需要进?配置变更。借助 ZooKeeper，我们只需要对ZooKeeper上配置节点的内容进?更新，ZooKeeper就能够帮我们将数据变更的通知发送到各个客户端，每个客户端在接收到这个变更通知后，就可以重新进?最新数据的获取。 命名服务 全局唯?ID?成的ZooKeeper节点示意图说明，对于?个任务列表的主键，使?ZooKeeper?成唯?ID的基本步骤： 1. 所有客户端都会根据??的任务类型，在指定类型的任务下?通过调?create（）接?来创建?个顺序节点，例如创建“job-”节点。 2. 节点创建完毕后，create（）接?会返回?个完整的节点名，例如“job-0000000003”。 3. 客户端拿到这个返回值后，拼接上 type 类型，例如“type2-job-0000000003”，这就可以作为?个全局唯?的ID了。在ZooKeeper中，每?个数据节点都能够维护?份?节点的顺序顺列，当客户端对其创建?个顺序?节点的时候 ZooKeeper 会?动以后缀的形式在其?节点上添加?个序号，在这个场景中就是利?了 ZooKeeper的这个特性 分布式锁 都是使用zk的创建节点实现：排他锁通过创建临时解点。共享锁：临时顺序节点。 分布式队列 分布式队列可以简单分为两?类：?种是常规的FIFO先?先出队列模型，还有?种是等待队列元素聚集后统?安排处理执?的Barrier模型。 ① FIFO先?先出 FIFO（First Input First Output，先?先出）， FIFO 队列是?种?常典型且应??泛的按序执?的队列模型：先进?队列的请求操作先完成后，才会开始处理后?的请求。使?ZooKeeper实现FIFO队列，和之前提到的共享锁的实现?常类似。FIFO队列就类似于?个全写的共享锁模型，?体的设计思路其实?常简单：所有客户端都会到/queue_fififo 这个节点下?创建?个临时顺序节点，例如如/queue_fififo/host1-00000001。 ② Barrier：分布式屏障 Barrier原意是指障碍物、屏障，?在分布式系统中，特指系统之间的?个协调条件，规定了?个队列的元素必须都集聚后才能统?进?安排，否则?直等待。这往往出现在那些?规模分布式并?计算的应? 场景上：最终的合并计算需要基于很多并?计算的?结果来进?。这些队列其实是在 FIFO 队列的基础上进?了增强，?致的设计思想如下：开始时，/queue_barrier 节点是?个已经存在的默认节点，并且将其节点的数据内容赋值为?个数字n来代表Barrier值，例如n=10表示只有当/queue_barrier节点下的 ?节点个数达到10后，才会打开Barrier。之后，所有的客户端都会到/queue_barrie节点下创建?个临时节点。 ZAB协议介绍 ZAB协议包括两种基本的模式：崩溃恢复和消息?播进?崩溃恢复模式：当整个服务框架启动过程中，或者是Leader服务器出现?络中断、崩溃退出或重启等异常情况时，ZAB 协议就会进?崩溃恢复模式，同时选举产?新的Leader服务器。当选举产?了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，其中，所谓的状态同步就是指数据同步，?来保证集群中过半的机器能够和Leader服务器的数据状态保持?致进?消息?播模式：当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进 ?消息?播模式，当?台同样遵守ZAB协议的服务器启动后加?到集群中，如果此时集群中已经存在? 个Leader服务器在负责进?消息?播，那么加?的服务器就会?觉地进?数据恢复模式：找到Leader 所在的服务器，并与其进?数据同步，然后?起参与到消息?播流程中去。Zookeeper只允许唯?的? 即：所有事务请求必须由?个全局唯?的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将?个客户端事务请求转化成?个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有 Follower服务器的反馈，?旦超过半数的Follower服务器进?了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前?个Proposal进?提交个Leader服务器来进?事务请求的处理，Leader服务器在接收到客户端的事务请求后，会?成对应的事务提议并发起?轮?播协议，?如果集群中的其他机器收到客户端的事务请求后，那么这些?Leader 服务器会?先将这个事务请求转发给Leader服务器。 ① 消息?播 ZAB协议的消息?播过程使?原??播协议，类似于?个?阶段提交过程，2pc，针对客户端的事务请求， Leader服务器会为其?成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各?的选票，最后进?事务提交。 ② 崩溃恢复 ZAB协议的这个基于原??播协议的消息?播过程，在正常情况下运??常良好，但是?旦在Leader服 务器出现崩溃，或者由于?络原因导致Leader服务器失去了与过半Follower的联系，那么就会进?崩溃恢复模式。在ZAB协议中，为了保证程序的正确运?，整个恢复过程结束后需要选举出?个新的Leader 服务器，因此，ZAB协议需要?个?效且可靠的Leader选举算法，从?保证能够快速地选举出新的 Leader，同时，Leader选举算法不仅仅需要让Leader?身知道已经被选举为Leader，同时还需要让集群中的所有其他机器也能够快速地感知到选举产?出来的新Leader服务器。

zookeeper深入学习

Zookeeper使用场景

相关

标签