hadoop应用11.第周关于zookeeper

1、关于ZooKeeper课程内容ZooKeeper简介ZooKeeper服务ZooKeeper应用ZooKeeper实战2/51什么是ZooKeeper3/51Hadoop生态系统4/51什么是ZooKeeperZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和HBase的重要组件。ZooKeeper为分布式应用提供一致性的服务，功能包括：配置维护、域名服务、分布式同步、组服务等。5/51ZooKeeper Service6/51Zookeeper特点简单：Zookeeper的核心是一个精简的文件系统，它支持一些简单的

2、操作和一些抽象操作丰富：实现一些协调数据结构和协议。例如，分布式队列、分布式锁和一组同级别节点中的“领导者选举”。高可靠：Zookeeper支持集群模式，可以很容易的解决单点故障问题。松耦合：某进程在Zookeeper中留下消息后，该进程结束后其它进程还可以读这条消息。资源库：Zookeeper实现了一个关于通用协调模式的开源共享存储库7/51课程内容ZooKeeper简介ZooKeeper服务ZooKeeper应用ZooKeeper实战8/51Zookeeper数据模型特性（1） ZooKeeper 维护树形层次结构ZooKeeper 可用将其理解为一个高可用性的文件系统。这个文件系统中没有

3、文件和目录。而是统一使用“节点”的概念，称为znode。znode 既可以作为保存数据的容器（文件），也可以作为保存其他 znode 的容器（目录）znode 可以用于存储数据，有一个与之相关联的 ACL，存储数据限制为小于1M9/51Zookeeper数据模型ZooKeeper的结构其实就是一个树形结构每个znode可以关联数据，数据小于1M10/51Zookeeper-Znode数据11/51cZxid创建节点时的事务IDctime创建节点时的时间mZxid最后修改节点时的事务IDmtime最后修改节点时的时间pZxid表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就

4、会影响子节点列表，但是修改子节点的数据内容则不影响该IDcversion子节点版本号，子节点每次修改版本号加1dataVersion数据版本号，数据每次修改该版本号加1aclVersion权限版本号，权限每次修改该版本号加1dataLength该节点的数据长度numChildren该节点拥有子节点的数量ZooKeeper角色Leader：在集群运行期间有且仅有一台,通过选举产生,统一处理集群的事务性请求以及集群内各服务器的调度。Follower：参与Leader选举投票、处理客户端非事务请求(读请求),并转发事务请求(写请求)给Leader服务器。Observer：像Follower一样能够处

5、理非事务也就是读请求,并转发事务请求给Leader服务器,但是其不参与任何形式的投票。ZooKeeper 默认没有 Observer 角色，为了使用 Observer 模式，在任何想变成Observer的节点的配置文件中加入:peerType=observer 并在所有 server 的配置文件中，配置成 observer 模式的 server 的那行配置追加 :observer12/51Zookeeper数据模型特性（2）ZooKeeper 的数据访问具有原子性客户端在读取一个 znode 的数据时，要么读到所有的数据，要么读操作失败，不会只读到部分数据一个写操作将替换 znode 存储的所

6、有数据。ZooKeeper 会保证写操作不成功就失败，不会出现部分写之类的情况13/51Zookeeper数据模型特性（2）悲观锁：假定所有不同事务的处理一定会出现干扰，数据库中最严格的并发控制策略，如果一个事务正在对数据处理，那么在整个事务过程中，其他事务都无法对这个数据进行更新操作，直到该事务释放了这个锁。乐观锁：假定所有不同事务的处理不一定会出现干扰，所以在大部分操作里不许加锁，但是既然是并发就有出现干扰的可能。在乐观锁中当提交更新请求之前，要先去检查读取这个数据之后该数据是否发生了变化，如果有变化，那么你此次的提交就要放弃，如果没有变化就可以提交。14/51Zookeeper数据模型特

7、性（2）Zookeeper中的版本号（cversion）就是乐观锁修改节点数据之前会读取这个数据并记录该数据版本号需要更新时会携带这个版本号去提交，如果此时携带的版本号和当前节点的版本号相同，则说明该数据没有被修改过，提交成功如果版本号不一致，说明该数据在读取之后和提交之前这段时间内被修改了，提交失败！15/51Zookeeper数据模型特性（2）16/51乐观锁测试Zookeeper数据模型特性（3）znode 通过路径被引用ZooKeeper 中的路径必须是绝对路径，也就是说每条路径必须从一个斜杠字符开始。字符串 “zookeeper ” 是一个保留词，不能将它作为路径表示中的一部分。17

8、/51Znode的性质（1）-类型znode 有两种类型：短暂的和持久的。znode 的类型在创建时被确定并且之后不能再修改。在创建短暂 znode 的客户端会话结束时，Zookeeper 会将短暂的 znode 删除。短暂 znode 不可以有子节点持久 znode 不依赖与客户端会话，只有当客户端明确要删除该持久 znode 时才会被删除。18/51Znode的性质（2）-顺序号顺序 (sequential) znode 是指名称中包含 Zookeeper 指定顺序号的 znode 。如果在创建 znode 时设置了顺序标识，那么该 znode 名称之后便会附加一个值，这个值是由一个单调递

9、增的计数器（由父节点维护）所添加的。在分布式系统中，顺序号被用于为所有的时间进行全局排序，这样客户端就可以通过顺序号来推断事件的顺序。19/51Znode的性质（3）-观察znode 以某种方式发生改变时，“观察”（Watch）机制可以让客户端得到通知，可以针对 Zookeeper 服务的操作来设置Watcher，该服务的其他操作可以触发观察。例如客户端可以对一个 znode 调用 exists 操作，同时设定一个观察。如果这个 znode 不存在，则客户端所调用的 exists 操作将返回 false。如果一段时间之后，另外一个客户端创建这个 znode，则这个观察就会被触发，通知前一个客户

10、端这个 znode 被创建。观察只能被触发一次。为了能够多次收到通知，客户端需要重新注册所需要的观察。20/51Zookeeper操作21/51实现运行模式Zookeeper 服务有两种不同的运行模式。“独立模式 ”(standalone mode)：即只有一个 Zookeeper 服务器。适合用于测试环境，不能保证高可用性和可恢复性。“复制模式” (replicated mode)：在生产环境中的 Zookeeper 通常是以 “复制模式”运行于一个计算机集群上，这个计算机集群被称为一个“集合体” (ensemble)。Zookeeper 通过复制来实现高可用性，只要集合体中半数以上的机器处

11、于可用的状态，它就能提供服务。Zookeeper 确保对 znode 树的每一个修改都会被复制到集合体中超过半数的机器上。22/51实现-Zab协议（1）阶段1：领导者选举 集合体中的所有的机器通过一个选择过程来选择出一台被称为 “领导者” (leader) 的机器其他的机器被称为“跟随者”(follower)一旦半数以上（或者指定数量）的跟随者已经将其状态与领导者同步，则表明这个阶段已经完成。23/51实现-Zab协议（2）阶段2：原子广播所有的写操作都会被转发给领导者，再由领导者将更新广播给 跟随者。当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新

12、成功的响应。这个用来达成共识的协议被设计成具有原子性，修改那么成功要么失败。24/51实现-Zab协议（3）如果领导者出现故障，其余的机器会选举出另外一个领导者，并和新的领导者一起继续提供服务。随后，如果之前的领导者恢复正常，会成为一个跟随者。领导者选举的过程是非常快的，只需要大约 200 毫秒，因此在领导者选举的过程中不会出现系统性能的明显降低。在更新内存中的 znode 树之前，集合体中的所有机器都会先将更新写入磁盘。任何一台机器都可以为读请求提供服务，并且由于读请求只涉及内存检索，因此非常快。25/51数据一致性26/51数据一致性说明(1)顺序一致性 ：来自任意客户端的更新都会按其发送

13、顺序被提交。原子性 ：更改要么成功，要么失败，不会存在部分成功或失败的结果。如果失败了，则不会有客户端看到这个更新的结果。单一系统映像： 客户端会看到 Zookeeper 服务的相同的视图，而无论它们连到具体哪一个服务器上。当一台服务器出故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有状态滞后于故障服务器的服务器都不会接受该连接请求，除非这些服务器将状态更新至故障服务器的水平。27/51数据一致性说明(2)持久性（可靠性）： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。这表明更新不会受到服务器故障的影响。及时性： 任何客户端所看到的滞后系统视图都是有限

14、的，不会超过几十秒，即客户端看到的系统视图在一定的时间范围内总是最新的。28/51会话-创建在启动时，客户端会尝试连接集合体（服务器）列表中的一台服务器。如果连接失败，它会尝试连接另一台服务器，直到成功建立连接。一旦客户端与一台 Zookeeper 服务器建立连接，这台服务器就会为该客户端创建一个新的会话。每个会话都会有一个超时的时间设置，如果服务器在超过时间段内没有收到任何请求，则相应的会话会过期。一旦一个会话已经过期，就无法重新被打开，并且任何与该会话相关联的短暂 znode 都会丢失。只要一个会话空闲超过一定时间，都可以通过客户端发送 ping 请求（也称为心跳）来保持会话不过期。这个时

15、间长度的设置应当足够低，以便能够检测出服务器故障，并且能够在会话超时的时间段内重新连接到另外一台服务器。29/51会话-故障处理Zookeeper 客户端可以自动地进行故障切换，切换至另一台 Zookeeper 服务器，在另一台服务器接替故障服务器之后，所有的会话（和相关的短暂 znode）仍然是有效的。在故障切换过程中，应用程序将收到断开连接和连接至服务的通知。当客户端断开连接时，观察通知将无法发送；但是当客户端成功恢复连接后，这些延迟的通知还会被发送。30/51时间“滴答 (tick time)” 参数定义了 ZooKeeper 中的基本时间周期，并被集合体中的服务器用来定义相互交互的时间

16、表。其他设置都是根据 “滴答 (tick time)” 参数来定义的，或至少受它的限制。例如，会话超时 (session timeout) 参数的值不可以小于 2 个 “滴答 (tick time)” 并且不可以大于 20 个 “滴答 (tick time)”。通常将 “滴答 (tick time)” 参数设置为 2 秒 (2000毫秒)，对应于允许的会话超时范围是 4 到 40 秒。31/51时间32/51时间设置较短的会话超时设置会较快的检测到机器故障避免将会话超时时间设得太低，因为繁忙的网络会导致数据包传输延迟，从而可能会无意中导致会话过期。对于创建较复杂的暂时状态的应用程序来说，由于重

17、建的代价较大，因此比较合适设置较长的会话超时。一般的规则是，Zookeeper 集合体中的服务器越多，会话超时的设置应越大。如果频繁遇到连接丢失的情况，应考虑增大超时的设置。33/51状态34/51状态新建的Zookeeper实例正在与Zookeeper服务器建立连接时，处于CONNECTING状态。一旦连接建立好以后，状态就变成了Connected状态。使用Zookeeper的客户端可以通过注册Watcher的方法来获取状态转变的消息。一旦进入了CONNNECTED状态，Watcher将获得一个KeepState值为SyncConnected的WatchedEvent。Zookeeper实例

18、可能失去或重新连接Zookeeper服务，在CONNECTED和CONNECTING状态中切换。如果连接断开，Watcher得到一个Disconnected事件。close()方法被调用，或是会话由Expired类型的KeepState提示过期时，ZooKeeper转变成第三种状态CLOSED。一旦处于CLOSED状态，Zookeeper对象将不再是活动的。客户端必须建立一个新的Zookeeper实例才能重新连接到Zookeeper服务。35/51ACL操作权限：CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，这5种权限简写为crwda注：这5种

19、权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的操作权限身份的认证：world：默认方式，相当于全世界都能访问auth：代表已经认证通过的用户digest：即用户名:密码这种方式认证ip：使用IP地址认证36/51ACL-示例增加一个认证用户addauth digest 用户名:密码明文addauth digest user1:password1设置权限setAcl /path auth:用户名:密码明文:权限setAcl /test auth:user1:password1:cdrwa查看Acl设置getAcl /path37/51课程内容ZooKeeper简介ZooKeeper服务ZooKeeper应用ZooKeeper实战38/51应用场景（1）统一命名服务 分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。通过名称来获取资源或服务的地址，提供者等信息。按照层次结构组织服务/应用名称可将服务名称以及地址信息写到Zookeeper上，客户端通过Zookeeper获取可用服务列表类。配置管理 分布式环境下，配置文件管理和同步是一个常见问题。一个集群中，所有节点的配置信息是一致的，配置文件修改后，希望能够快速同步到各个节点配置管理可由Zookeeper实现。可将配置信息写入Zookeeper的一个znode上。各个节点监听这个znode。一