zookeeper原理

一、背景介绍 本人目前是一名大数据工程师，项目数据50T，日均数据增长20G左右，个人是从Java后端开发，经过3个月的业余自学成功转型大数据工程师。 二、大数据介绍 大数据本质也是数据，但是又有了新的特征，包括数据来源广、数据格式多样化（结构化数据、非结构化数据、Excel文件、文本文件等）、数据量大（最少也是TB级别的、甚至可能是PB级别）、数据增长速度快等。 针对以上主要的4个特征我们需要考虑以下问题： 数据来源广，该如何采集汇总？，对应出现了Sqoop，Cammel，Datax等工具。 数据采集之后，该如何存储？，对应出现了GFS，HDFS，TFS等分布式文件存储系统。 由于数据增长速度快，数据存储就必须可以水平扩展。 数据存储之后，该如何通过运算快速转化成一致的格式，该如何快速运算出自己想要的结果？ 对应的MapReduce这样的分布式运算框架解决了这个问题；但是写MapReduce需要Java代码量很大，所以出现了Hive，Pig等将SQL转化成MapReduce的解析引擎； 普通的MapReduce处理数据只能一批一批地处理，时间延迟太长，为了实现每输入一条数据就能得到结果，于是出现了Storm/JStorm这样的低时延的流式计算框架； 但是如果同时需要批处理和流处理，按照如上就得搭两个集群，Hadoop集群（包括HDFS+MapReduce+Yarn

Dubbo缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。 dubbo是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。 Spring Eureka从开源转变为闭源，Consul正在崛起，而Dubbo又开始重新更新。目前市场上仍有不少公司使用dubbo我们也需要继续学习。 1）默认使用的是什么通信框架，还有别的选择吗? 默认也推荐使用netty框架，还有mina 2）服务调用是阻塞的吗？ 默认是阻塞的，可以异步调用，没有返回值的可以这么做 3）一般使用什么注册中心？还有别的选择吗？ 推荐使用zookeeper注册中心，还有redis等不推荐 4）默认使用什么序列化框架，你知道的还有哪些？ 默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列化 5）服务提供者能实现失效踢出是什么原理？

SOA思想 SOA介绍 面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 RPC协议 RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。 HTTP协议与RPC的关系 层级关系与对应的协议. 区别 : 1.RPC是传输层协议(4层).而HTTP协议是应用层协议(7层). 2.RPC协议可以直接调用中立接口,HTTP协议不可以. 3.RPC通信协议是长链接,HTTP协议一般采用短连接需要3次握手(可以配置长链接添加请求头Keep-Alive: timeout=20). (长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。) 4.RPC协议传递数据是加密压缩传输.HTTP协议需要传递大量的请求头信息. 5.RPC协议一般都有注册中心.有丰富的监控机制. dubbo Dubbo(读音[ˈdʌbəʊ]

Zookeeper系列之高级篇 1. NIO、ZAB协议、2PC提交相关概念 2. Leader选举 3. 手写分布式锁，配置中心 ==================================== 一. NIO、ZAB协议、2PC提交相关概念 1 NIO NIO中的几个概念 Channel 可以将NIO中的Channel同传统IO中的Stream来类比，但是要注意，传统IO中，Stream是单向的，比如InputStream只能进行读取操作，OutStream只能写操作。而Channel是双向的，即可用来进行读操作，又可用来进行写操作 Buffer 在NIO中所有数据的读和写都离不开Buffer，读取的数据只能放在Buffer中，写入的数据也是先写入到Buffer中 Seletor 将Channel和Seletor配合使用，必须将channel注册到Seletor上，通过SelectableChannel.register()方法来实现 2 2PC （Two Phase Commitment Protocol）当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID 特性，就需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为AP。TM负责调度AP的行为，并最终决定这些AP是否要把事务真正进行提交

Zookeeper系列之基础篇 1. Zookeeper概述 2. Zookeeper必知必会 3. 集群介绍 ==================================== 一. Zookeeper概述 是一个开源的分布式应用的服务，提供了更高级别的服务，包括：同步、配置维护、分组和命名。 主要目标：通过与标准文件系统一致的组织结果的命名空间，允许分布式进程之间可以进行同步。 功能：提供了优质的高性能、高可用性、和严格有序的访问 二. Zookeeper必知必会 节点类型 持久节点：所谓持久节点，是指持久节点，是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点。 临时节点：和持久节点不同的是,临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。 持久顺序节点：这类节点的基本特性和持久节点是一致的。额外的特性是，在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属性，那么在创建节点过程中，ZK会自动为给定节点名加上一个数字后缀，作为新的节点名。这个数字后缀的范围是整型的最大值。 临时顺序节点：类似临时节点和顺序节点

三个核心选举原则： （1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作； （2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader； （3）选出Leader之后，之前的服务器状态由Looking改变为Following，以后的服务器都是Follower。 下面以一个简单的例子来说明整个选举的过程： 假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。 假设这些服务器从id1-5，依序启动： 因为一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。 （1）服务器1启动，发起一次选举。 服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成； 服务器1状态保持为LOOKING； （2）服务器2启动，再发起一次选举。 服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2； 此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举无法完成； 服务器1，2状态保持LOOKING； （3）服务器3启动，发起一次选举。 与上面过程一样，服务器1和2先投自己一票，然后因为服务器3id最大，两者更改选票投给为服务器3； 此次投票结果：服务器1为0票

第1章 Zookeeper入门 1.1 概述 Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。 1.2 特点 1.3 数据结构 1.4 应用场景 提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。 1.5 下载地址 1 ．官网首页： https://zookeeper.apache.org/ 2．下载截图，如图5-5，5-6，5-7所示 图5-5 Zookeeper下载（一） 图5-6 Zookeeper下载（二） 图5-7 Zookeeper下载（三） 第2章 Zookeeper安装 2.1 本地模式安装部署 1．安装前准备 （1）安装Jdk （2）拷贝Zookeeper安装包到Linux系统下 （3）解压到指定目录 tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/ 2．配置修改 （1）将/opt/module/zookeeper-3.4.10/conf这个路径下的zoo_sample.cfg修改为zoo.cfg； mv zoo_sample.cfg zoo.cfg （2）打开zoo.cfg文件，修改dataDir路径： vim zoo.cfg 修改如下内容： dataDir=/opt/module/zookeeper-3.4.10/zkData （3

1 场景描述 参考 http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html ，实现自己的集中配置管理系统。 术语：配置管理（ Configuration Management ） 一个带配置的服务程序，部署在若干台机器上，如果配置发生了变化，接下去要进行的操作是停止所有机器上的该程序，修改每一台机器上该程序对应的配置文件。 这个情景会有两个问题：第一，机器多了，逐个修改配置是一件不合理的运维；第二，配置一般是程序启动时读入的，所以配置修改后，程序应该重启。 配置管理在某些场合称“数据发布与订阅”，顾名思义就是将数据发布到 zk 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。 实际应用环境： 1. 索引信息和集群中机器节点状态存放在 zk 的一些指定节点，供各个客户端订阅使用。 2. 系统日志（经过处理后的）存储，这些日志通常 2-3 天后被清除。 3. 应用中用到的一些配置信息集中管理，在应用启动的时候主动来获取一次，并且在节点上注册一个 Watcher ，以后每次配置有更新，实时通知到应用，获取最新配置信息。 4. 业务逻辑中需要用到的一些全局变量，比如一些消息中间件的消息队列通常有个 offset ，这个 offset

一、ZooKeeper入门 　　1.1 ZooKeeper 概述 　　 Zookeeper是一个 基于观察者模式分布式开源框架 ，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务 ——分布式同步（ Distributed Synchronization）、命名服务（ Naming Service）、集群维护（ Group Maintenance）等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。 ZooKeeper本身可以以单机模式安装运行，不过它的长处在于 通过分布式 ZooKeeper集群（一个 Leader，多个 Follower），基于一定的策略来保证 ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。 　　1.2 集群机制 　　 Zookeeper集群的角色： Leader 和 follower 　　只要集群中有半数以上节点存活，集群就能提供服务 　　1.3 ZooKeeper 特性 　　　 1. 一个leader，多个follower组成的集群 　　　2、 全局数据一致： 每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的 　　　3、分布式读写，更新请求转发，由leader实施 　　　4、更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行 　　　5、 数据更新原子性

概述 Zookeeper字面上理解就是动物管理员，是大数据框架Hadoop生态圈中的一个服务中间件，Hadoop生态圈中很多开源项目使用动物命名，那么需要一个管理员来管理这些“动物”。他负责分布式应用程序协调的工作。 Hadoop框架 Zookeeper主要提供以下四点功能： 统一命名服务、配置管理、集群管理、共享锁和队列管理 ，用于高效的管理集群的运行。 Zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。 Zookeeper 部署有三种方式，单机模式、集群模式、伪集群模式，以下采用Docker 的方式部署 注意： 集群为大于等于3个奇数，如 3、5、7,不宜太多，集群机器多了选举和数据同步耗时长，不稳定。 zk安装 docker-compose-yml version: '3.1' services: zoo1: image: zookeeper restart: always hostname: zoo1 ports: - 2181:2181 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.1=zoo1:2888:3888 配置说明 2181：客户端连接 Zookeeper 集群使用的监听端口号 3888：选举 leader 使用 2888：集群内机器通讯使用（Leader 和