zookeeper集群

这段时间来，也在和公司里的一些同学交流使用zk的心得，整理了一些常见的zookeeper问题。这个页面的目标是解答一些zk常见的使用问题，同时也让大家明确zk不能干什么。页面会一直更新。 1. 客户端对ServerList的轮询机制是什么 随机，客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中，将所有Server保存在一个List中，然后随机打散，形成一个环。之后从0号位开始一个一个使用。 两个注意点：1. Server地址能够重复配置，这样能够弥补客户端无法设置Server权重的缺陷，但是也会加大风险。（比如: 192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181). 2. 如果客户端在进行Server切换过程中耗时过长，那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。更多关于客户端地址列表相关的，请查看文章《 ZooKeeper客户端地址列表的随机原理 》 2 .客户端如何正确处理CONNECTIONLOSS(连接断开) 和 SESSIONEXPIRED(Session 过期)两类连接异常 在ZooKeeper中，服务器和客户端之间维持的是一个长连接，在 SESSION

一、概述 1.1、简介 Zookeeper是一个开源的，分布式的，为分布式应用提供协调服务的Apache项目 1.2、工作机制 Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化Zookeeper就将负责通知已经在Zookeeper.上注册的那些观察者做出相应的反应。 1.3、特点 1） Zookeeper： 一个领导者（Leader） ，多个跟随者（Follower） 组成的集群。 2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。 3）全局数据一致：每个Server保存一份相同的数据副本，Client无论 连接到哪个Server，数据都是一致的。 4）更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。 5）数据更新原子性，一次数据更新要么成功，要么失败。 6）实时性，在一定时间范围内，Client能读到最新数据。 1.4、数据结构 ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。 znode一共有4种类型：持久的（persistent）、临时的 （ephemeral）、持久有序的

一、什么是zookeeper 　　ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。 　　简单来说，zookeeper = 文件系统 + 监听通知机制 二、文件系统 　　zookeeper有着与linux类似的文件系统，区别是，linux的目录就是目录，文件就是文件。而zookeeper中只有一个znode概念，本身可以做为“文件”存储一定的数据，又可以做为“目录”存在。 /* +---+ |/ | +-+-+ | | +------+ +--|config| | +--+---+ | | +-----+ | +-----|ip | | | +-----+ | | +-----+ | +-----|port | | +-----+ | | +------+ +--|apps | +--+---+ | +-----+ +-----|app1 | | +-----+ | +-----+ +-----|app2 | +-----+ */ 　　znode共分为四种： 　　1、PERSISTENT-持久化目录节点 　　　　此节点在客户端与zookeeper断开连接之后，依然存在，需要主动删除。

hadoop的机制，是在hadoop的2.x中才有的功能，该功能的实现，非常依赖于一个分布式组件：zookeeper。 zookeeper简要介绍 zookeeper主要做分布式协调服务。主要实现的功能：1.提供对少量数据的存储和管理。2.提供对数据节点的监听功能。 zookeeper的角色：leader（负责数据的写操作）和follower。leader和follower实在启动的时候动态选举出来的。 zookeeper的作用：主控机器选举，分布式协调操作。 zookeeper管理数据采用了类似于文件树结构。每个节点成为一个datanode。节点能够保存一定的数据（小于1M）也可以拥有子节点。 zookeeper的应用场景。 统一命名服务：Dubbo 远程调用：webservice和rpc。统一命名：将多个机器上的服务给予 一个统一的命名。 统一配置管理 将所有分布式应用的数据存入到zookeeper集群中。 集群管理 利用zookeeper实现动态主控节点的选举 NN高可用方案实现机制 问题：相应客户的读写请求的是角色是NN，所以一旦NN宕机了，那么整个集群的服务就停止了。NN+SN机制，只能实现元数据的可靠性，但无法做到服务的高可用性。 解决方案：再加入一个NN。思考点： 能否两个NN收正常客户请求？ 否，两个NN只能有一个相应客户请求（状态为active）

Z ooK eeper 保证数据一致性用的是 ZAB协议 。 通过这个协议来进行 Z ooK eeper 集群间的数据同步，保证数据的一致性。 两阶段提交+过半写机制： Z ooK eeper 写数据的机制是客户端把写请求发送到leader节点上（如果发送的是follower节点，follower节点会把写请求转发到leader节点），leader节点会把数据通过proposal请求发送到所有节点（包括自己），所有到节点接受到数据以后都会写到自己到本地磁盘上面，写好了以后会发送一个ack请求给leader，leader只要接受到过半的节点发送ack响应回来，就会发送commit消息给各个节点，各个节点就会把消息放入到内存中（放内存是为了保证高性能），该消息就会用户可见了。 那么这个时候，如果 Z ooK eeper 要想保证数据一致性，就需要考虑如下两个情况，情况一： leader执行commit了，还没来得及给follower发送commit的时候，leader宕机了，这个时候如何保证消息一致性？ 情况二： 客户端把消息写到leader了，但是leader还没发送proposal消息给其他节点，这个时候leader宕机了，leader宕机后恢复的时候此消息又该如何处理？ ZAB的崩溃恢复机制 针对情况一，当leader宕机以后， Z ooK eeper 会选举出来新的leader

在 Z ooK eeper 的选举中，如果过半的节点都选一个节点为leader的话，那么这个节点就会是leader节点， 也就是因为这个原因， Z ooK eeper 集群，只要有过半的节点是存活的，那么这个 Z ooK eeper 就可以正常的提供服务。 比如有5个 Z ooK eeper 节点，其中有2个节点宕机了，这个时候还有3个节点存活，存活个数超过半数，此时集群还是正常提供服务，所以 Z ooK eeper 集群本身是没有高可用问题的。 又因为存活的判断依据是超过半数，所以我们 一般搭建 Z ooK eeper 集群的 时候，都使用奇数台 ，这样会比较节约机器，比如我们安装一个6台的 Z ooK eeper 集群，如果宕机了3台就会导致集群不可用，因为这个时候存活的节点数没有超过半数了，所以6台和5台的效果是一样的，我们用5台比较合适。 对应一个 Z ooK eeper 集群，我们可能有多个客户端，客户端能任意连接其中一台 Z ooK eeper 节点，但是 所有的客户端都只能往leader节点上面去写数据，所有的客户端能从所有的节点上面读取数据 。 如果有客户端连接的是follower节点，然后往follower上发送了写数据的请求，这个时候follower就会把这个写请求转发给leader节点处理。 leader接受到写请求就会往其他节点（包括自己）同步数据

Zookeeper常用的应用场景 分布式协调： 简单来说就是有人对Zookeeper中的数据做了监听，如果修改了Zookeeper中被监听的数据，Zookeeper反过来就会告诉发起监听的人数据变更。比如在kafka的设计中，kafka的一个节点在Zookeeper中创建了一个数据，kafka的策略是谁创建了这个数据谁就是kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这Zookeeper对应的数据就会发送变更，即而监听这个数据的其余节点就会感知到主节点宕机，然后重新进行选举。 元数据管理： 很多分布式的程序需要集中式管理自己的元数据，这个时候Zookeeper就是一个很好的选择。比如kafka、Storm等分布式的工具就会把集群里核心的元数据存放在Zookeeper中。 高可用： 很多分布式项目都是主从架构（一个主节点+多个从节点）。如果只有一个主节点的话，程序就会有单点故障问题，那么这个时候就需要部署多个从节点实现高可用。如HDFS就是靠Zookeeper实现高可用的 分布式锁： 注意的是Zookeeper不支持高并发，在高并发的情况建议使用Redis实现分布式锁，并发不太高的情况下使用Zookeeper实现分布式锁比较方便。 Zookeeper架构 在Zookeeper集群中，集群的服务角色分为leader和learner

唠唠叨叨 本文主要分享一下 zookeeper 的一些基本概念，在正式进入正题前，和大家聊一聊刚入行时我的面试经验，可以说是耿直的有些可爱。 面试官 ：用过 zookeeper 吗？ 我 ：用过啊，给 dubbo 提供服务的注册与发现嘛 面试官 ：知道 zookeeper 是什么吗？ 我 ：知道啊，注册中心嘛 面试官 ：那你们项目中都是怎么用 zookeeper 的？ 我 ：就在 springboot 的 application.properties 配置文件里添加一个 zookeeper 服务地址就行了。。。 . 上边的对话好像也没什么毛病，但似乎又感觉哪里有点不太对，结果就是每次我如此回答面试都被pass。 为什么会被问zookeeper？因为我的简历项目上写着熟练使用zookeeper，可面试官理解的 “熟练” 使用可不是会配置，工程启动不报错那么简单。所以还是有必要全面了解一下zookeeper的相关知识。 一、zookeeper初识？ Zookeeper 它作为 Hadoop 项目中的一个开源子项目，是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。 1、zookeeper数据模型 zookeeper 维护了一个类似文件系统的数据结构，每个子目录（/微信、/微信/公众号）都被称作为 znode

备注： 有些博客尚未完成，如果点进去发现看不了，那就是正在完善中。 预计2020年5月之前，对于下面这些主题我会学习完毕，并且输出成日志。 Zookeeper源码编译（Zookeeper 3.4.11)并IDEA启动 ZooKeeper客户端： ZooKeeper源码阅读-客户端 先学习zk客户端源码的目的其实很简单，就是以为client相关代码比较少，比较简单。 客户端主要是连接zk服务端、创建session、提交请求、获取响应。 其实主要代码就是NIO和jute序列化相关的代码。 先理解好zk的网络I/O相关，可以减轻zk 服务端代码阅读的困难。 所以强烈建议先阅读客户端代码。 ZooKeeper单节点服务端： ZooKeeper源码解读——ZooKeeper 服务端启动流程 ZooKeeper源码解读-NIOServerCnxnFactory#thread ZooKeeper源码阅读-请求处理器RequestProcessor ZooKeeper源码阅读——session管理器SessionTracker ZooKeeper源码阅读——数据库ZKDatabase ZooKeeper集群相关： ZooKeeper源码阅读——Leader 的选举机制 来源： oschina 链接： https://my.oschina.net/anxiaole/blog/3220758

ZooKeeper是一个分布式的、开源的分布式应用程序协调服务，可以在分布 式环境中实现应用配置管理、统一命名服务、状态同步服务等功能。 ZooKeeper是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务：分布式锁 服务。由于ZooKeeper开源的特性，在其分布式锁实现的基础上，又被摸索出了其它的功用，譬如：配置维 护、组服务、分布式消息队列等等。 ZooKeeper维护了一个类似文件系统的数据结构，其内部每个子目录都被 称作znode（目录节点），与文件系统一样，我们可以自由的增删改查znode。ZooKeeper集群适合搭建在奇数 台机器上。只要集群中半数以上主机处于存活，那么服务就是可用的。 ZooKeeper在配置文件中并没有指定 master和slave，但是，ZooKeeper在工作时，只有一个节点为leader，其余节点为follower，leader是通过内部 的选举机制临时产生的。 ZooKeeper特点 1、顺序一致性：以zxid来保证事务的顺序性。 2、原子性：以zab保证原子操作，要么成功，要么失败。 3、单一视图：客户获取到的数据始终是一致的。 4、可靠：以版本实现"写入校验"，保证了数据写入的正确性。 ZooKeeper有三种安装方式：单机模式 & 伪集群模式 & 集群模式 单机模式： ZooKeeper以单实例的形式运