学习笔记之ZooKeeper概述

最新推荐文章于 2022-09-01 19:58:43 发布

clincat

最新推荐文章于 2022-09-01 19:58:43 发布

阅读量294

点赞数

分类专栏：架构师养成计划文章标签： ZooKeeper 概念 API

本文链接：https://blog.csdn.net/qq_41320704/article/details/85559731

版权

ZooKeeper是一个开源的分布式协调服务，由雅虎创建并基于Google Chubby。它提供统一的数据模型、原子性操作和实时性保证。常用于分布式锁、配置管理、命名服务等场景。本文介绍了ZooKeeper的CAP理论、使用场景、安装过程、配置文件分析、相关概念如数据模型、watcher、ACL，以及Java API的使用，包括原生API、zkClient和Curator。

摘要由CSDN通过智能技术生成

zookeeper概述

（个人学习笔记，如有错误欢迎指正！！！）

经典的CAP/BASE理论

CAP

一致性 Consistency：对于任何从客户端发送到分布式系统的读数据请求，要么返回正确的数据，要么返回错误。这一特性保证的是数据的正确性。
可用性 Availability：对于任何从客户端发送到分布式系统的读请求，客户端都一定会收到数据，但不保证数据的一定是罪行的数据。这一特性保证系统不会返回错误。
分区容错 Partition-tolerance：分布式系统再各个节点进行数据同步的时候可能存在延迟，但是系统必须保持运行状态。这一特性要求系统一致处于工作状态。

CAP 理论是不能同时实现这三个特性的。在实际应用过程中，一定会出网络延迟导致数据丢失等问题，所以分区容错的特性是一定要实现的。

BASE

基本可用 basically available：分布式系统出现故障，允许失去部分的可用性，但是系统还是可以运行的。例如：将数据存放到不同的实例上，即使部分数据损坏，还能保证其他部分的数据时可用的。
软状态 soft-state：允许保持中间状态。在基于 C/S模式系统中，server端是否有状态，决定了系统是否具有良好的水平扩展、负载均衡、故障恢复等特点。Server端承诺会维护client端状态数据，这个状态仅仅位置一小段时间，这段时间以后，server端会对丢弃这个状态，恢复正常状态。
最终一致性 eventually consistent：数据最终一致性

ZooKeeper介绍

雅虎创建，基于 Google chubby

是一个开源的分布式协调框架

并不是用来存储数据的，通过监控数据状态的变化，达到基于数据的集群管理

zookeeper序列化使用的是Jute

使用场景

订阅发布：watcher机制，统一配置管理（disconf）

分布式锁：redis，zookeeper，数据库

负载均衡，ID生成器，分布式队列，统一命名服务，master选举

原则

单一视图

无论客户端连接到哪一个服务器，所看到的模型都是一样的

原子性

所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的。（所有机器上的分布式事务要么同时成功，要么同时失败）

可靠性

一旦服务器成功应用了某一个事务的数据，并且对客户端做了成功的响应，那么这个数据在整个集群中一定是同步并且保留下来

实时性

一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据；（zookeeper仅仅保证在一定时间内实时，近实时）

安装（linux系统）

单机环境安装

下载zookeeper安装包：http://apache.fayea.com/zookeeper/stable/
解压安装包：tar -zxvf zookeeper-3.4.12.tar.gz
cd 到 zookeeper/conf，（复制一份zoo.cfg）:cp zoo_sample.cfg zoo.cfg，zookeeper加载的配置文件为 zoo.cfg
sh zkServer.sh xxx:start|start-foreground|stop|restart|status|upgrade|print-cmd执行服务器命令
sh zkCli.sh -server ip:port：与zookeeper服务器建立连接，如果添加 -server ip:port内容，默认连接到本机的zookeeper节点

集群环境

zookeeper集群，包括三种角色：leader/follower/observer

observer 是一种特殊的zookeeper节点，可以帮助解决zookeeper的扩展性（如果大量客户端访问zookeeper集群，需要增加集群机器数量，从而增加zookeeper服务器性能，导致zookeeper写性能下降，因为，zookeeper的数据变更需要半数以上服务器投票通过，造成网络消耗增加投票成本）

observer不参与投票，只接受投票结果。
不属于zookeeper的关键部位。

配置observer：在zoo.cfg 里面增加

peerType=observer

server.id=host:port:port:observer

安装：

修改配置文件 zoo.cfg（配置所有机器）

server.id=host:port:port

id的范围为1~255，用id表示该机器在集群中的机器序号

第一个port是follow而与leader交换信息的端口号，第二个port是leader节点挂掉了，需要通过这个端口号进行leader选举。

2181是zookeeper与客户端交换信息的端口号，所以前面两个端口号不能使用2181
创建myid（dataDir定义在 zoo.cfg文件中）

在每一个服务器的dataDir目录下创建一个myid文件，数据内容是每台服务器对应的Server.id中id的值，该值配置在 zoo.cfg文件中
启动zookeeper，通过调用命令 sh zkServer.sh start启动服务器（zookeeper集群只有当两台及以上服务器启动后才会工作，这时候使用命令 sh zkServer.sh status可以查看当前服务器在zookeeper集群中的角色）

zoo.cfg配置文件分析

tickTime=2000：zookeeper中最小的事件单位，默认是2000毫秒。
initLimit=10：follower启动之后，与leader服务器完成数据同步的时间。
syncLimit=5：leader节点与follower节点进行心跳检测的最大延迟时间。
dataDir=/tmp/zookeeper：表示zookeeper服务器存储快照文件的目录。
dataLogDir：表示配置zookeeper事务日志的存储路径，默认指定在dataDir路径下。
clientPort=2181：表示客户端与服务器端建立连接的端口号：2181。

相关概念

数据模型

zookeeper的数据模型和文件系统类似，每一个节点称为 znode，是zookeeper中最小的数据单元。每个znode上都可以保存数据和挂载子节点

持久化节点（CreateMode.PERSISTENT）：节点创建后会一直存在zookeeper服务器上，直到主动删除

持久化有序节点（CreateMode.PERSISTENT_SEQUENTIAL）：节点会为有序子节点维护一个顺序

临时节点（CreateMode.EPHEMERAL）：临时节点的生命周期和客户端的会话保持一致，当客户端的会话失效，该节点自动清理（临时节点不能拥有子节点）

临时有序节点（CreateMode.EPHEMERAL_SEQUENTIAL）：在临时节点上多一个顺序性特性（临时节点不能拥有子节点）

数据存储

zookeeper有三种日志：

zookeeper.out 运行日志

快照，存储某一时刻的全量数据

事务日志，事务操作的日志记录

watcher

zookeeper提供了分布式数据发布/订阅，zookeeper允许客户端向服务器端注册一个watcher监听。当服务器端的节点触发指定事件的时候会触发watcher。服务端会向客户端发送一个事件通知

watcher的通知是一次性的，一旦触发一次通知后，该watcher就失效

注意在注册watcher之后，如果还需要继续监听，应该重新注册watcher，因为watcher是一次性有效，zookeeper中可以用来注册的方法有 getData(),exists(),setData(),getChildren() 方法，

操作与产生的事件类型的对应关系

	"/parent"的事件	"/parent/child"的事件
create("/parent")	NodeCreated
delete("/parent")	NodeDeleted
setData("/parent")	NodeDataChanged
create("/parent/child")	NodeChildrenChanged	NodeCreated
delete("/parent/child")	NodeChildrenChanged	NodeDeleted
setData("/parent/child")	——	NodeDataChanged

事件类型与设置watcher的方法的对应关系

（watcher并不是监视所有类型的事件，其中default watcher是指创建ZooKeeper时注册的watcher）!

	Default Watcher	exists("/path")	getData("/path")	getChildren("/path")
None	Y	Y	Y	Y
NodeCreated		Y	Y
NodeDeleted		Y	Y
NodeDataChanged		Y	Y
NodeChildrenChanged				Y

ACL

zookeeper提供了控制节点访问权限的功能，用于有效的保证zookeeper中的数据安全性，避免误操作而导致系统出现重大事故

CREATE/READ/WRITE/DELETE/ADMIN

create：表示创建权限
read：表示读权限
write：表示写权限
delete：表示删除权限
admin：表示管理员权限

权限控制模式

schema：授权对象

ip：192.168.1.1

Digest：username：password

world：开放式的权限控制模式，数据节点的访问权限对所有用户开放。world：anyone

super：超级用户，可以对zookeeper上的数据节点进行操作

Server命令操作

create [-s] [-e] path data acl：-s 表示节点是否有序，-e表示是否为临时节点，acl表示权限
get path [watch]：获得指定path数据（信息）
set path data [version]：修改节点对应的data

数据库中有一个version字段去控制数据行的版本号，在执行该指令时，如果使用该字段，则version必须与当前节点的dataversion相同，如果不同，则设置数据失败。-1表示默认不使用version字段
delete path [version]：删除指定path的节点，注意必须按照创建顺序的相反顺序删除，即先删除子节点，再删除父节点，其中version字段与 set指令的作用相同