zookeeper集群

文章目录 前言 下载地址: 安装之前需要的准备工作 : 上传 tar.gz 压缩包到linux 解压到指定目录 进入到解压后的zookeeper目录 配置环境变量 修改zookeeper的配置文件 创建zkdata文件夹 把zookeeper 分发到其它节点 考虑到zookeeper 启动和关闭比较麻烦,附带zookeeper启动和关闭脚本 前言 为了文章的通用性 全篇使用的都是环境变量 下载地址: 点击下载 CDH 版本 apache版本 安装之前需要的准备工作 : 1.jdk 是否安装好 2.集群时间是否同步 3.检测防火墙是否关闭 4.检测主机 ip 映射关系是否配置好 上传 tar.gz 压缩包到linux 博主在此已经准备好了就不再上传了, 本博主使用的版本是 zookeeper-3.4.5-cdh5.14.0 解压目录为 /export/install/zookeeper-3.4.5-cdh5.14.0 解压到指定目录 tar -zxvf 上传的路径 -C 解压的路径 进入到解压后的zookeeper目录 使用pwd查看目录 例如: /export/install/zookeeper-3.4.5-cdh5.14.0 配置环境变量 进入 /etc/profile.d/ 目录 cd /etc/profile.d/ 创建一个 zookeeper.sh 的脚本 touch

初始需求 元数据的存储（小数据） 分布式、高可用 读多写少、高性能读 有序访问 设计 单机层面 节点数据结构的选取 树结构，每个节点是一个ZNode 数据保存在内存中 优点：高效读写 为什么ZK不擅长存储大的数据？ 单机高效写磁盘 高效写磁盘的两种方式： 顺序写磁盘 预分配磁盘空间 ZK每次写磁盘，先申请固定大小的磁盘空间，之后再写磁盘，大大提升写入性能。 顺序写数据 每次写入操作，ZooKeeper会附加一个数字标签，表明ZooKeeper中的事务顺序 高可用、宕机可恢复 快照+事务日志 什么时候记录事务日志？ 如何快照？新起线程，不影响主流程 分布式层面 顺序写数据 一主多从结构，只有一台master服务器对外提供写服务，每次写记录ZXID事务Id。原子写，保证mei yo 如何保证数据强一致 写的策略，半数以上机器写成功后返回。 写数据流程，非Leader节点会把请求转发给leader，写成功后leader再通知该节点。 ZAB协议：初始阶段/宕机恢复（原子广播） 如何提高读的性能 follower节点，observer节点都可以对外提供读数据能力 怎么保证读取的强一致？ 客户端在调用前，可以先申请连接的主机同步leader数据，调用sync()方法 。 水平扩容 ZK做的不好的地方。 ZooKeeper 在水平扩容扩容方面做得并不十分完美，需要进行整个集群的重启

前面虽然配置了集群模式的Zookeeper，但是为了方面学建议在伪分布式模式的Zookeeper学习Zookeeper的shell命令。 一、Zookeeper的四字命令 Zookeeper支持某些特定的四字命令字母与其的交互。他们大多数是查询命令，用来获取Zookeeper服务的当前状态及相关信息。用户在客户端可以通过telnet或nc向Zookeeper提交相应的命令。Zookeeper常用的四字命令见图1.1所示。 图 1.1 图1.2是Zookeeper四字命令的一个简单用例。 [root@hadoop ~]# echo ruok|nc localhost 2181 [root@hadoop ~]# zkServer.sh start zoo1.cfg JMX enabled by default Using config: /usr/local/zk/bin/../conf/zoo1.cfg Starting zookeeper ... STARTED [root@hadoop ~]# zkServer.sh start zoo2.cfg JMX enabled by default Using config: /usr/local/zk/bin/../conf/zoo2.cfg Starting zookeeper ... STARTED [root@hadoop ~]

ZooKeeper 概述 Zookeeper 是一个分布式协调服务的开源框架。 主要用来解决分布式集群中 应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。 ZooKeeper 本质上是一个分布式的小文件存储系统。 提供基于类似于文件系 统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维 护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达 到基于数据的集群管理。 诸如： 统一命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。 2.1、zookeeper的架构图 Leader: Zookeeper 集群工作的核心 事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。 Follower: 处理客户端非事务（读操作） 请求， 转发事务请求给 Leader； 参与集群 Leader 选举投票 2n-1台可以做集群投票。 此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。 Observer: 观察者角色，观察

ZooKeeper简介 ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 ZooKeeper设计目的 1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。 2.可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。 3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 5.原子性：更新只能成功或者失败，没有中间状态。 6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。 ZooKeeper数据模型 Zookeeper会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图所示：

Dubbo作为一个RPC框架，其最核心的功能就是要实现跨网络的远程调用。这次创建两个应用，一个作为服务的提供方，一个作为服务的消费方。通过Dubbo来实现服务消费方远程调用服务提供方的方法。 服务提供方 1 创建maven工程（打包方式为war）dubbodemo_provider，在pom.xml文件中导入如下坐标 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <spring.version>5.0.5.RELEASE</spring.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org

Zookeeper请求处理原理分析 数据库的原理 我们知道，数据库是用来存储数据的，只是数据可以存储在内存中或磁盘中。而Zookeeper实际是结合了这两种的，Zookeeper中的数据即会存储在磁盘中以达到持久化的目的，也会同步到内存中以到达快速访问的目的。 事实上，用过Zookeeper的同学应该知道，Zookeeper中有两种类型的节点： 持久化节点 和 临时节点 。 持久化节点：会持久化在磁盘中，除非主动删除，将一直存在。 临时节点：不会持久化在磁盘中，只会存储在内存中，创建这个临时节点的Session一旦过期，此临时节点也将自动被删除。 数据库处理数据的原理 作为一个数据库，肯定是要接收客户端创建、修改、删除、查询节点等请求的。 在Zookeeper中对于请求分为两类： 事务性请求 非事务性请求 事务性请求 Zookeeper通常都是以集群模式运行的，也就是Zookeeper集群中各个节点的数据需要保持一致的。但是和Mysql集群不一样的是： Mysql集群中，从服务器是异步从主服务器同步数据的，这中间的间隔时间可以比较长。 Zookeeper集群中，当某一个集群节点接收到一个写请求操作时，该节点需要将这个写请求操作发送给其他节点，以使其他节点同步执行这个写请求操作，从而达到各个节点上的数据保持一致，也就是数据一致性

1. Zookeeper 概念简介： Zookeeper 是一个分布式 协调服务；就是为用户的分布式应用程序提供协调服务 A、zookeeper 是为别的分布式程序服务的 B、Zookeeper本身就是一个分布式程序 （只要有半数以上节点存活， zk 就能正常服务） C、Zookeeper 所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务…… D、 虽然说可以提供各种服务，但是 zookeeper 在底层其实只提供了两个功能： 管理 ( 存储，读取 ) 用户程序提交的数据； 并为用户程序提供数据节点监听服务； Zookeeper 集群的角色： Leader 和 follower （ Observer ） 只要集群中有半数以上节点存活，集群就能提供服务 zookeeper 集群机制 半数机制：集群中半数以上机器存活，集群可用。 zookeeper 适合装在 奇数台机器上！！！ 安装 1.虚拟机准备 安装到 3 台虚拟机上 安装好JDK 2. 解压 su – hadoop （切换到 hadoop 用户） tar -zxvf zookeeper-3.4.5.tar.gz（解压） 3. 修改环境变量 1 、 su – root( 切换用户到 root) 2 、 vi /etc/profile( 修改文件 ) 3 、添加内容： export

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

分布式RPC框架Apache Dubbo 1. 软件架构的演进过程 软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程，下面我们分别了解一下这几个架构。 1.1 单体架构 架构说明： ​ 全部功能集中在一个项目内（All in one）。 架构优点： ​ 架构简单，前期开发成本低、开发周期短，适合小型项目。 架构缺点： ​ 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。 ​ 技术栈受限，只能使用一种语言开发。 ​ 系统性能扩展只能通过扩展集群节点，成本高。 1.2 垂直架构 架构说明： ​ 按照业务进行切割，形成小的单体项目。 架构优点： ​ 技术栈可扩展（不同的系统可以用不同的编程语言编写）。 架构缺点： ​ 功能集中在一个项目中，不利于开发、扩展、维护。 ​ 系统扩张只能通过集群的方式。 ​ 项目之间功能冗余、数据冗余、耦合性强。 1.3 SOA架构 SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。 站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 架构说明： ​