zookeeper原理

kafka集群并测试其高可用性 介绍 Kafka 是由 Apache软件基金会 开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka是一种高吞吐量的 分布式 发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像 Hadoop 一样的 日志 数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过 Hadoop 的并行加载机制来统一线上和离线的消息处理，也是为了通过 集群 来提供实时的消息。 一、KAFKA 体系结构图： Producer： 生产者，也就是发送消息的一方。生产者负责创建消息，通过zookeeper找到broker，然后将其投递到 Kafka 中。 Consumer： 消费者，也就是接收消息的一方。通过zookeeper找对应的broker 进行消费，进而进行相应的业务逻辑处理。 Broker： 服务代理节点。对于 Kafka 而言，Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器，前提是这台服务器上只部署了一个 Kafka 实例。一个或多个

一、基本概念 介绍 Kafka是一个分布式的、可分区的、可复制的消息系统。它提供了普通消息系统的功能，但具有自己独特的设计。 这个独特的设计是什么样的呢？ 首先让我们看几个基本的消息系统术语： Kafka将消息以topic为单位进行归纳。 将向Kafka topic发布消息的程序成为producers. 将预订topics并消费消息的程序成为consumer. Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个broker. producers通过网络将消息发送到Kafka集群，集群向消费者提供消息，如下图所示： 客户端和服务端通过TCP协议通信。Kafka提供了Java客户端，并且对多种语言都提供了支持。 Topics 和Logs 先来看一下Kafka提供的一个抽象概念:topic. 一个topic是对一组消息的归纳。对每个topic，Kafka 对它的日志进行了分区，如下图所示： 每个分区都由一系列有序的、不可变的消息组成，这些消息被连续的追加到分区中。分区中的每个消息都有一个连续的序列号叫做offset,用来在分区中唯一的标识这个消息。 在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。比如，如果消息的保存策略被设置为2天，那么在一个消息被发布的两天时间内，它都是可以被消费的。之后它将被丢弃以释放空间

CAP 定制： Eureka的优势 1、在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。 2、正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务，它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的

本文章用于面试展示，具体细节以及排版正在编辑，暂时先写下来实现原理 实现原理：利用zookeeper的持久性节点和Watcher机制 具体步骤： 　　1、创建持久性节点 zkLock 　　2、在此父节点下创建子节点列表，name按顺序定义 　　3、Java程序获取该节点下的所有顺序子节点，并且按照从小到大的顺序排列 　　4、取出最小的节点，如果该节点在所有顺序子节点列表中index等于0，代表成功获取到锁资源 　　　　否则将给比当前节点还小的节点注册监听事件，利用Watcher机制动态观察节点的删除事件 　　5、删除子节点即释放锁资源 文章来源: 基于zookeeper实现高性能分布式锁

Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。这一切的基础，都是Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。既然是一个文件系统，就不得不提Zookeeper是如何保证数据的一致性的。 Zookeeper集群是一个基于主从复制的高可用集群，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器通过异步复制的方式获取 Master 服务器最新的数据，并提供读服务，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色，每个角色承担如下： Leader Follower Observer 为了保证写操作的一致性与可用性，Zookeeper专门设计了一种名为原子广播（ZAB）的支持崩溃恢复的一致性协议。基于该协议，Zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。 写数据时保证一致性：Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求且当前节点不是leader，那么节点就会向

　　上半节已经下载好了Zookeeper，以及新建了两个应用provider和consumer，这一节我们就结合dubbo来测试一下分布式可不可以用。 　　现在就来简单用一下，注意：这里只是涉及最简单的部分，新手入门用的，详细的内容要学习的可以自己查一查资料;然后再说说用Zookeeper当作注册中心的一个特点。 　　话说注册中心是一个类似第三方软件的东西，那么我们能不能用Dubbo+其他注册中心呢？其实也是可以的，比如redis，有兴趣的可以查查资料自己试试，原理都差不多。 1.导入依赖 两个模块都要导入这两个依赖 （这两个依赖千万要正确，我就是因为自己导入依赖导错了，愣是找了好几个小时最后才发现是依赖的问题，我导入的组id是com.alibaba.spring.boot，太像了....细节细节！！！） 　　这里有一些版本问题，我去官方文档截了一下图，版本问题我也碰到了，还是官方文档靠谱！还有具体的版本对应我也截图了，可以看看。 2.provider模块新建一个服务 说是创建一个服务，其实就是新建一个service层的接口，写个实现 　　目录结构以及接口+实现 　　配置文件稍微配置一下，其实就是配置自己服务在哪里，还有Zookeeper的位置及端口（Zookeeper可以是在其他电脑或者虚拟机里），其实还能配置很多东西，这里列举最简单最实用的几个； 　　可以尝试启动一下

承接上一篇：继续接受最后一个特性： ACL- 保障数据的安全； 　　Zookeeper提供了一套完善的ACL(Access Control List)权限控制机制来保证数据的安全； 　　　　标识一个有效的ACL的三个维度：权限模式(Scheme)，授权对象(ID)，权限(Permission),通常使用 scheme:id:premission来标识一个有效的ACL； 　　<1> 权限模式：Scheme 　　　　1）IP模式，类似 ip:192.168.0.110 形式 　　　　2）Digest：类似于username:password 形式的； 　　　　3）World：最开放的权限控制模式，从其名字中可以看出，数据节点的访问权限对所有用户抗法。也可以将其看做是一种特殊的Digest模式，他只有一个标识，“”world:anyone”; 　　　　4）Super: 超级用户对任意zk节点进行任何操作； 　　<2> 授权对象：ID 　　　　授权对象是指权限赋予的用户或者一个指定实体，不同的权限模式下，授权对象是不同的。他们的对应关系： 　　　　　　IP -----> IP段：“192.168.0.1” 　　　　　　Digest -------> username:BASE64(SHA-1(username:password))

Zookeeper客户端java代码操作 上篇博客记录了shell命令操作zookeeper集群的方式，这次尝试采用java代码来操作。通过查阅API，发现并不困难。 1. 首先获得客户端与服务器的连接 //zookeeper客户端 private ZooKeeper zkCli; //连接地址 private static final String CONNECT_STRING = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; //session过期时间 private static final int SESSION_TIMEOUT = 2000; /** * 创建客户端实例对象 * * @throws IOException */ @Before public void before() throws IOException { zkCli = new ZooKeeper(CONNECT_STRING, SESSION_TIMEOUT, (event) -> { System.out.println("默认的回调函数"); }); } 2. 列出根节点下的子节点(非递归) @Test public void ls() throws KeeperException, InterruptedException { List

前面花了一段时间去学习SpringCloud的相关知识，主要是理解微服务的概念并使用SpringCloud的一系列组件实现微服务落地。学习这些组件本身是简单的，跟着操作一遍基本就会了，这也得益于Springboot给我们带来了很多便利。实际的应用中也许还会碰到一些坑，但只要我们掌握基本的原理就能够解决。 前面也讲了微服务的解决方案有两个，一个是SpringCloud,另外一个就是 Dubbo +Zookeeper，下面我们来学习Dubbo+Zookeeper实现微服务。 在学习微服务的第一篇中，理解了微服务的概念，比较了微服务与单体应用之前的优势和劣势，讲了要实现微服务主要的技术点，最重要的两块在于服务之间的通信和服务治理。 Dubbo+ Zookeeper 要实现微服务，就必须解决这两个技术点，Dubbo是一个RPC通信框架，它可以实现服务之间的通信。ZooKeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。 一、 分布式协调技术 上面说Zookeeper是一个分布式协调技术，那么我们就得先来学习什么是分布式协调技术。 分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。 首先，要明白我们为什么需要分布式锁，一个简单的例子，一般系统上都有一些定时任务

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的 CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中， Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。 针对分布式锁的实现，目前比较常用的有以下几种方案： 基于数据库实现分布式锁 基于缓存（ redis，memcached，tair）实现分布式锁 基于Zookeeper实现分布式锁 在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理） 可以保证在分布式部署的应用集群中