ZK

Zk是一个分布式服务框架，提供了协调分布式应用的基本服务，zk集群主要是保证服务的可靠性和稳定性，介绍一下集群的安装与配置，在安装之前需要安装好jdk，jdk的安装请网上查找相应的方法 Dubbo 注册中心集群Zookeeper-3.4.6 Dubbo建议使用Zookeeper作为服务的注册中心。 Zookeeper集群中只要有过半的节点是正常的情况下，那么整个集群对外就是可用的。正是基于这个特性，要将ZK集群的节点数量要为奇数（2n+1：如3、5、7个节点）较为合适。 ZooKeeper 与Dubbo服务集群架构图 服务器1：192.168.1.81 端口：2181、2881、3881 服务器2：192.168.1.82 端口：2182、2882、3882 服务器3：192.168.1.83 端口：2183、2883、3883 1、 修改操作系统的/etc/hosts文件，添加IP与主机名映射： # zookeeper clusterservers 192.168.1.81 edu-zk-01 192.168.1.82 edu-zk-02 192.168.1.83 edu-zk-03 2、 下载或上传zookeeper-3.4.6.tar.gz到/home/wusc/zookeeper目录： $ cd /home/wusc/zookeeper $ wget http:/

上一章介绍了一些hadoop的实战分析案例，本章将介绍hadoop的高可用以及初步认识hive。 一、Hadoop的HA机制 前言：正式引入HA机制是从hadoop2.0开始，之前的版本中没有HA机制；HA的运作机制： （1）hadoop-HA集群运作机制介绍：所谓HA，即高可用（7*24小时不中断服务），实现高可用最关键的是消除单点故障，hadoop-ha严格来说应该分成各个组件的HA机制——HDFS的HA、YARN的HA （2）HDFS的HA机制详解：通过双namenode消除单点故障，双namenode协调工作的要点： A、元数据管理方式需要改变：内存中各自保存一份元数据，Edits日志只能有一份，只有Active状态的namenode节点可以做写操作，两个namenode都可以读取edits，共享的edits放在一个共享存储中管理（qjournal和NFS两个主流实现） B、需要一个状态管理功能模块：实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在namenode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split（脑裂--在很多高可用系统中都或多或少存在这一的风险，如：基于keeperalived的mysql高可用主备架构）现象的发生。 二

1.Zookeeper的优点与局限性 在学习了Zookeeper（后文都简称zk）的介绍和功能后，您已经很好地理解了zk。 现在，在这个zk教程中，我们将讨论zk的优点和局限性。 zk有几个功能对用户非常有益,但同时也存在一些局限性，所以在我们使用zk前，必须先了解一下。让我们分别学习一下zk的优点与局限性 2.zk的优点 下面列出了使用zk的各种优点 01.分布式协调过程简单 zk节点之间的协调过程非常简单 02.同步 zk高度同步，这意味着服务器进程之间既存在互斥又存在合作，同步有助于Apache HBase进行配置管理。 03.有序消息 zk跟踪一个数字，表示每个更新的顺序，保证消息有序 04.序列化 根据具体规则，zk对数据进行编码。 另外，它还可确保我们的应用程序始终如一地运行。 但是，在MapReduce中，我们使用此方法（序列化）来协调队列以执行正在运行的线程 05.速度 在读请求多的情况下，能以很快的速度运行 06.可扩展性 此外，可以通过部署更多机器来加强zk的性能 07.有序性有何优势？ 众所周知，zk中的消息是有序的。 所以，为了实现更高级别的抽象，需要有序性。 这就是有序性对我们有利的方式 08.快 在读多的情况下，zk会非常快 09.可靠性 zk非常可靠，因为一旦zk更新了，更新后的数据会一直保持，直到被覆盖更新 10.原子性 zk只有两种情况

Kubernetes 脱胎于 Google 的 Borg 系统，是一个功能强大的容器编排系统。Kubernetes 及其整个生态系统（工具、模块、插件等）均使用 Go 语言编写，从而构成一套面向 API、可高速运行的程序集合，这些程序文档精良、易于参与贡献或在其上构建应用程序。 每个开发、运维或感兴趣的读者都应熟悉它的一些核心概念，以便理解这个系统及其不同的功能，以及为什么几乎所有人都在使用它。 在继续之前，我想提一下 Kubernetes 的几个顶级朋友（或竞争对手）：ECS、Nomad 和 Mesos。ECS 是 AWS 自己的编排解决方案，最近它又推出了托管在 AWS 上的 Kubernetes 系统——EKS。两者都支持 FARGATE，让用户无须关心所运行的物理资源。 Kubernetes 毫无疑问是最大赢家，作为一个开源系统，三大主流云服务商都以托管的方式提供了这项功能。但是，它比其他几个产品都要来得复杂和混乱。Kubernetes 可以处理几乎任何类型的容器负载，也有很多技巧，但这并不意味着每个人都应该使用它。其他解决方案或许也能满足某些公司的要求，例如，完全部署在 AWS 上的互联网产品公司，使用 ECS 会比 Kubernetes 具有更佳的生产环境体验，是的，也好于 EKS。 话虽如此，Kubernetes 的魔力在于：它可以部署在任何地方、它拥有一个活跃的社区

Zookeeper是分布式一致性问题的工业解决方案，是Apache Hadoop下解决分布式一致性的一个组件，后被分离出来成为Apache的顶级项目。 工程来源：是雅虎公司内部项目，据说雅虎内部很多项目都是以动物命名，这个动物管理员的名字起的很是形象。 被开源出来后得到开源社区的快速推进，服务端Java语言实现，棒，git有3000+的star： https://github.com/apache/zookeeper zookeeper集群结构 集群的角色，比较典型的是Master/Slave(主备模式)，zk中的概念跟这个不一样，包含Leader、Follower、Observer三个角色，leader提供读和写的能力，follower只对外提供读的能力。 会话（session） 客户端跟服务端交互，是先与服务端建立一个TCP长连接，会话开始，通过心跳检测与服务端保持会话有效，向服务端发送请求和接收响应。 zk将所有的数据都加载在内存一份，同时有事务日志文件（持久化文件），服务端会定时dump快照数据，重启机器的时候会根据快照和事务日志恢复内存数据库的数据，这跟redis的AOF和RDB概念类似。 zookeeper上的数据结构 zk上的数据的结构跟linux文件系统很像，是个树状结构 节点（node）上的信息字段 节点类型包括： 持久型节点 顺序持久型节点 临时节点

ZooKeeper入门指导 入门：在分布式协同系统中使用ZooKeeper 这篇文档包含的内容可以让你快速开始使用ZooKeeper。它主要针对希望尝试它的开发者，文档包含着在单台ZooKeeper服务器上的安装指导，也有一些验证ZooKeeper在运行的简单的命令，还有一些简单的编码案例。最后，为了方便，还有一部分内容是关于更复杂的安装，例如，运行复制部署，并优化事务日志。不过，关于完整的商业环境部署，请参考 ZooKeeper管理员指导 。 先决条件 请查看管理员指导中的 系统要求 。 下载 为了得到一个分布式ZooKeeper，请从 Apache下载镜像 之一下载最新稳定版。 独立操作 以独立模式设置一个ZooKeeper服务器是非常简单的。服务器包含在一个单独的jar文件里，所以需要创建一个配置文件来开始安装。 当你下载完成一个稳定版ZooKeeper后，解压并进入到它的根目录。 运行ZooKeeper需要一个配置文件，这里有一个案例，文件要包含在conf目录下，命名为zoo.cfg。 tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 这个文件可以被称为为任何名字，但是为了不必要的讨论我们叫它conf/zoo.cfg。改变dataDir字段的值来指定一个存在的(空的)文件夹。这里是每一个字段的含义。

https://www.cnblogs.com/bangerlee/p/4427331.html zookeeper在分布式系统中作为协调员的角色，可应用于Leader选举、分布式锁、配置管理等服务的实现。以下我们从zookeeper提供的API、应用场景和监控三方面学习和了解zookeeper（以下简称ZK）。 ZK API ZK以Unix文件系统树结构的形式管理存储的数据，图示如下： 其中每个树节点被称为znode，每个znode类似一个文件，包含文件元信息(meta data)和数据。 以下我们用server表示ZK服务的提供方，client表示ZK服务的使用方，当client连接ZK时，相应创建session会话信息。 有两种类型的znode： Regular: 该类型znode只能由client端显式创建或删除 Ephemeral: client端可创建或删除该类型znode；当session终止时，ZK亦会删除该类型znode znode创建时还可以被打上sequential标志，被打上该标志的znode，将自行加上自增的数字后缀 ZK提供了以下API，供client操作znode和znode中存储的数据： create(path, data, flags)：创建路径为path的znode，在其中存储data[]数据，flags可设置为Regular或Ephemeral

一、总体流程： 1.服务提供者启动时，会向注册中心写入自己的元数据信息，同时会订阅配置元数据信息； 2.消费者启动时，也会向注册中心写入自己的元数据信息，并订阅服务提供者、路由和配置元数据信息； 3.服务治理中心启动时，会同时订阅所有消费者、服务提供者、路由和配置元数据信息； 4.当有服务提供者离开或有新的服务提供者加入时，注册中心服务提供者目录会发生变化，变化信息回动态通知给消费者、服务治理中心 5.当消费放发起服务调用时，会异步将调用、统计信息等上报给监控中心。 二、dubbo-admin 在dubbo框架进行服务调用时，用户可以通过服务治理平台(dubbo-admin)下方路由配置。如果要在运行时改变服务参数，则用户可以通过服务治理平台(dubbo-admin)下方动态配置，服务器端会通过订阅机制收到属性变更，并重新更新已经暴露的服务 来源： https://www.cnblogs.com/lccsblog/p/11520924.html

Zookeeper的几个概念：（接下来将从这几个概念书写Zookeeper的内部工作流程） 数据模型 节点特性 版本 Watcher ACL 　 <1> 数据模型 ： 　　Zookeeper的视图很热Unix文件系统很像。但没有引入文件和文件目录相关概念；而是使用“数据节点”概念，称为ZNode； 　　ZNode是ZK中最小的数据单元，每个ZNode上可以保存数据，也可以挂载子节点；即形成了一种层次化空间树； 　 事务ID : ZK中，事务是指能够改变zk服务器状态的操作，一般包括数据节点创建与删除，数据节点内容更新和客户端会话创建与失效等操作；对于每一个事务请求，zk都会为其分配一个全局唯一的事务ID,用ZXID表示，是一个64位的数字；每一个ZXID对应一个事务操作； <2> 节点特性： 　　 ZK中每个数据节点都是有生命周期；具体取决于数据节点的类型； 　　节点类型可以分为：持久节点，临时节点，顺序节点； 　　在节点的创建过程中，可以组合使用，于是有以下四种组合： 　　　　（1）持久节点：该节点一旦被创建，就会一直存在于ZK服务器上，直到有删除操作来主动清除这个节点； 　　　　（2）持久顺序节点：ZK中，每个父节点会为其第一级子节点维护一份顺序，用于记录下每个节点的先后顺序。 　　　　（3）临时节点：临时节点生命周期和客户端会话绑定在一起，客户端会话失效，这个节点被自动清理掉

1.Zookeeper上的数据操作 上一篇中我们介绍了zk是什么，以及zk的工作流程。既然zk是协调服务的，那必然会存储一些节点的信息，比附说Hadoop高可用集群HA的活跃NameNode信息，活跃ResourceManager信息（后面会介绍配置HA），Kafka的消息对了等等一些分布式节点信息，那这些基本信息是存储在zk哪里的，以及格式是什么样子？ 启动zk的客户端与服务器 $>bin/zkServer.sh start $>zkCli.sh -server s10:2181 //进入zk命令行 我们在客户端使用help来查看一下帮助，看看zk有哪些命令 $zk]help //查看帮助 我们看到有一个create命令，这个就是用来创建数据的，根据提供的格式，我们可以看到格式是create path data，说明了zk在创建数据的时候是创建了一个 目录，目录上有数据啊，这点特别重要，这就是zk上的数据格式。zk上存放的数据格式是：目录 数据。也就是创建的每一个目录都有值，我们试着创建一下： 我们看到最后一个创建的 目录 是 /a/a1，但在创建之前目录/a必须存在，只能先创建父节点，再创建子节点，并且每次在创建的时候必须给予值，否则不会创建成功。创建完成之后我们ls /查看一下 不给值，创建不成功 看到都是一层层的 目录 使用 get 目录 来获得这个 目录的值 注意